From: | David Brain <dbrain(at)bandwidth(dot)com> |
---|---|
To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Slow select performance despite seemingly reasonable query plan |
Date: | 2009-05-07 15:11:45 |
Message-ID: | 849c74160905070811o1c512c1esd452870a153eea52@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Nikolas Everett | 2009-05-07 15:18:03 | Re: Slow select performance despite seemingly reasonable query plan |
Previous Message | Matthew Wakeling | 2009-05-07 14:53:00 | Re: Slow select performance despite seemingly reasonable query plan |