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
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
