Alexandr Ogurtsov <[EMAIL PROTECTED]> 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 быстрых запросов, то тюнить стоит быстрые запросы!
pgpIIQb0bedVW.pgp
Description: PGP signature
_______________________________________________ Sysadmins mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/sysadmins
