Dave Cramer <[EMAIL PROTECTED]> writes: > diff -c -r1.16 s_lock.c > *** backend/storage/lmgr/s_lock.c 8 Aug 2003 21:42:00 -0000 1.16 > --- backend/storage/lmgr/s_lock.c 21 Apr 2004 20:27:34 -0000 > *************** > *** 76,82 **** > * The select() delays are measured in centiseconds (0.01 sec) because 10 > * msec is a common resolution limit at the OS level. > */ > ! #define SPINS_PER_DELAY 100 > #define NUM_DELAYS 1000 > #define MIN_DELAY_CSEC 1 > #define MAX_DELAY_CSEC 100 > --- 76,82 ---- > * The select() delays are measured in centiseconds (0.01 sec) because 10 > * msec is a common resolution limit at the OS level. > */ > ! #define SPINS_PER_DELAY 10 > #define NUM_DELAYS 1000 > #define MIN_DELAY_CSEC 1 > #define MAX_DELAY_CSEC 100
As far as I can tell, this does reduce the rate of semop's significantly, but it does so by bringing the overall processing rate to a crawl :-(. I see 97% CPU idle time when using this patch. I believe what is happening is that the select() delay in s_lock.c is being hit frequently because the spin loop isn't allowed to run long enough to let the other processor get out of the spinlock. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])