2009/5/7 David Brain <dbrain@xxxxxxxxxxxxx>: > Hi, Hi, > > Some answers in-line: > >> >> Has there been a performance *change*, or are you just concerned about a >> query which doesn't seem to use "enough" disc bandwidth? > > Performance has degraded noticeably over the past few days. > >> Certainly random access like this index scan can be extremely slow. 2-4 MB/s >> is quite reasonable if you're fetching one 8kB block per disc seek - no more >> than 200 per second. > > We have read ahead set pretty aggressively high as the SAN seems to > 'like' this, given some testing we did: > > /sbin/blockdev --getra /dev/sdb > 16384 > > >> One concern I might have with a big setup like that is how big the database >> directory has got, and whether directory lookups are taking time. Check to >> see if you have the directory_index option enabled on your ext3 filesystem. >> > > That's a thought, I doubt the option is set (I didn't set it and I > don't _think_ rhel does by default), however the 'base' directory only > contains ~5500 items total, so it's not getting too out of hand. default rhel ext3 options are (in 4.x and 5.x) : Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file See tune2fs -l /dev/sdXY Laurent. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
