Re: Slow select performance despite seemingly reasonable query plan

Поиск
Список
Период
Сортировка
От Laurent Wandrebeck
Тема Re: Slow select performance despite seemingly reasonable query plan
Дата
Msg-id fc593b510905090243u6ff7412bw4a8a8b89c7df461d@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Slow select performance despite seemingly reasonable query plan  (David Brain <dbrain@bandwidth.com>)
Список pgsql-performance
2009/5/7 David Brain <dbrain@bandwidth.com>:
> 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.

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Bad Plan for Questionnaire-Type Query
Следующее
От: David Blewett
Дата:
Сообщение: Re: Bad Plan for Questionnaire-Type Query