update on my problem: despite pgbouncer, the problem still occures on my
end.
Also, interesting observation - I ran several tests with pgbench, using
queries that I think are prone to trigger high-sys-cpu-stall. What I
noticed is when pgbench is started with prepared mode, the system
behaves
OK, so far I settled on excluding connection caching on app side
(Apache::DBI and prepare_cached) from equation and adding pgbouncer as a
counter-measure. This seems to stabilize the situation - at least I'm
not able to push server into high-sys-cpu stall the way how I used to do.
I'm still
Tom,
I just checked the version I'm running (9.1.6), and the code is quite
similar (src/backend/storage/lmgr/s_lock.c)
pg_usleep(cur_delay * 1000L);
#if defined(S_LOCK_TEST)
fprintf(stdout, *);
fflush(stdout);
#endif
/* increase delay by a
Tom:
Yes, they are ints. To (somewhat) check your guess on the role of the hash
aggregation speed, I just ran oltp test from sysbench
(http://sysbench.sourceforge.net/docs/#database_mode) on a table with 1mln
of records. That test uses pretty simple queries (that do not use
aggregation) and
