Тюнинг БД

From: "Dmitry E(dot) Oboukhov" <unera(at)debian(dot)org>
To: pgsql-ru-general(at)postgresql(dot)org
Subject: Тюнинг БД
Date: 2015-06-13 09:05:28
Message-ID: 20150613090528.GY19139@vdsl.uvw.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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(at)debian(dot)org jabber://UNera(at)uvw(dot)ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537

Responses

Browse pgsql-ru-general by date

  From Date Subject
Next Message Dmitry E. Oboukhov 2015-06-19 10:51:17 Бакап реплики
Previous Message Dmitry E. Oboukhov 2015-06-08 19:23:23 Re: Re: [pgsql-ru-general] Номер правки записи