I tried to test how this is related to cache coherency, by forcing
affinity of the two test_run.sql processes to the two cores (pipelines?
threads) of a single hyperthreaded xeon processor in an smp xeon box.
When the processes are allowed to run on distinct chips in the smp box,
the CS storm happens. When they are "bound" to the two cores of a
single hyperthreaded Xeon in the smp box, the CS storm *does* happen.
I used the taskset command:
taskset 01 -p <pid for backend of test_run.sql 1>
taskset 01 -p <pid for backend of test_run.sql 1>
I guess that 0 and 1 are the two cores (pipelines? hyper-threads?) on
the first Xeon processor in the box.
I did this on RedHat Fedora core1 on an intel motherboard (I'll get the
part no if it matters)
during storms : 300k CS/sec, 75% idle (on a dual xeon (four core))
machine (suggesting serializing/sleeping processes)
no storm: 50k CS/sec, 50% idle (suggesting 2 cpu bound processes)
Maybe there's a "hot block" that is bouncing back and forth between
caches? or maybe the page holding semaphores?
On Apr 19, 2004, at 5:53 PM, Tom Lane wrote:
> I wrote:
>> Here is a test case.
>
> Hmmm ... I've been able to reproduce the CS storm on a dual Athlon,
> which seems to pretty much let the Xeon per se off the hook. Anybody
> got a multiple Opteron to try? Totally non-Intel CPUs?
>
> It would be interesting to see results with non-Linux kernels, too.
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>