[Sysadmins] PostgreSQL оптимизация

[Ivan Fedorov]

Alexandr Ogurtsov <iscander.alt на gmail.com> writes:

>>> оперативке и как можно меньше обращалось к внешнему накопителю. Порылся
>> Ну при вашем количестве оперативы это нереально!
> При нынешнем количесве ОЗУ на стенде, да. Больше же интересуют
> настройки для production - там ОЗУ ожидается 4-8GB. Но не всё для
Я боюсь, что тюнить что-либо не на том же оборудовании несколько
бессмысленно.

> postgre часть отдастся под сервер приложений на RubyOnRails.
> Одновременных конектов будет немного 6-10 mongrel серверов, то есть 20
> конектов это с хорошим запасом.
Ну вообще есть "золотое правило" - количество процессов Pg должно быть
равно количеству процессоров(ядер) * 2. То есть если у вас например 2
проца Intel Xeon 5430 с 4мя ядрами, то вам надо использовать до 16-ти
процессов Pg. 

Советую обратить внимание на PgBouncer.

> 1. Рекомендации по настройке буферов памяти при наличии достаточного
> объёма RAM для того чтобы вся БД помещалась в памяти. Объём базы
> около 600Мб реально откусить на сервере можно 2-4Gb только для того
> чтоб Postgre не трогал винт при выборках.
Ну сделайте на системе 1-2 гига shared memory (shm) и отдайте их
Pg. Тогда он почти гарантированно загрузить базу в память, а так
дисковый кэш в Linux работает вполне оптимально.

> 2. Имеет ли смысл тонкий тюнинг настроек планировщика запросов QUERY
> TUNING?
> 3. Что имеет смысл крутить и в какую сторону для
> Background writer. Cost-Based Vacuum Delay. WAL?
Это невозможно определить по 1 запросу. Если у системы выполняется 1
медленный и 10000 быстрых запросов, то тюнить стоит быстрые запросы!
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 196 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/sysadmins/attachments/20081010/b2e13e71/attachment-0002.bin>