On Fri, Mar 23, 2012 at 3:52 AM, Sebastian Melchior <webmas...@mailz.de> wrote: > unfortunately we cannot directly control the TRIM (i am not sure it even > occurs) because the SSDs are behind an LSI MegaSAS 9260 Controller which does > not allow access via smart. Even if some kind of TRIM command is the problem, > shouldn't the iowait go up in this case?
Based on my recent benchmarking experiences, maybe not. Suppose backend A takes a lock and then blocks on an I/O. Then, all the other backends block waiting on the lock. So maybe one backend is stuck in I/O-wait, but on a multi-processor system the percentages are averaged across all CPUs, so it doesn't really look like there's much I/O-wait. If you have 'perf' available, I've found the following quite helpful: perf record -e cs -g -a sleep 30 perf report -g Then you can look at the report and find out what's causing PostgreSQL to context-switch out - i.e. block - and therefore find out what lock and call path is contended. LWLocks don't show up in pg_locks, so you can't troubleshoot this sort of contention that way. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
