Тюнинг БД
От | Dmitry E. Oboukhov |
---|---|
Тема | Тюнинг БД |
Дата | |
Msg-id | 20150613090528.GY19139@vdsl.uvw.ru обсуждение исходный текст |
Список | pgsql-ru-general |
Есть у нас БД у которой памяти 20Гиг и на диске она где-то 100 гиг. настраивалась она просто: инсталл+pgtune. не тюнили, но по возрастанию нагрузки анализировали что грузит и приводили все запросы к тому чтоб в частых запросах всегда выборка шла из индекса, а в редких - пофиг, на то они и редкие. в итоге доросли до того что примерно 10К рабочих мест эта БД обслуживает в реальном времени и вот щас дошли до где-то 70% средней загрузки CPU. далее или сплитить по шардам или (пока) переехать на более мощный хост + потюнить. взяли новый сервак 128Гиг + контроллер с батарейкой fsync практически мгновенный, если за размер кеша не вылазит. ща просто наладили реплику и планируем переключиться на нее. однако хочется еще попутно понастроить. pgtune при 120 Гиг RAM предлагает: +effective_cache_size = 88GB +work_mem = 768MB +shared_buffers = 30GB то есть он на буфера предлагает 1/4 и 3/4 на кеш. я думаю pgtune писали по идее умные люди, но может при большом объеме RAM лучше поюзать другое соотношение? PS: max_connections = 200 у нас стоит. мы используем в среднем где-то 40 соединений. на рестартах их получается 80 и на миграциях кратковременно 160. ну и запас. запросы в основном key-value + немного запросов за списками, но они оптимизированы под использование индексов. на что еще обратить внимание? автовакуум тоже дефолтный autovacuum_max_workers = 1 autovacuum_vacuum_cost_delay = 50ms проект lowcost. до DBA не доросли пока :) и еще wal_keep_segments = 4096 поставил - потому что экспериментируя с репликами иногда не успеваешь и чтобы реплику перезапустить надо rsync'ать. получается сегменты займут 64Гигабайта. в принципе фигня, вопрос clean-процесс на таком объеме не будет втупливать? можно сюда большое число такое вписать? раньше стояло 64. игры с репликами (типа собрать статистику) часто приводили к rsync. -- . ''`. Dmitry E. Oboukhov : :’ : email: unera@debian.org jabber://UNera@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Вложения
В списке pgsql-ru-general по дате отправления: