Обсуждение: как правильно почистить pg_xlog?
одну нагруженную БД поставили в режим pg_start_backup (реплику к ней приделывали), ну и она в этом режиме простояла несколько дней (rsync с ограничением скорости шел, ну и столько заняло). теперь в каталоге pg_xlog там накоплено 100500 файлов, есть ли какая-то команда которая не выводя сервер в оффлайн принудительно заставит pg почистить этот каталог "прямо сейчас"? -- . ''`. 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
Вложения
Был хост на Хецнере RAM 128G.
раскидал в свое время так:
maintenance_work_mem = 1GB
shared_buffers = 27GB
effective_cache_size = 80GB
max_connections = 200
Далее Хецнер стал предлагать хосты 256G RAM на 30% дешевле чем хосты 128G
RAM ну мы и переехали на такой хост.
CPU точно такой же. контроллер HDD такой же (с батарейкой), HDD такие
же (+-)
Запустил с точно такими же конфигами как и на предыдущем хосте и вижу:
нагрузка существенно упала (load average вдвое и даже disk io
процентов на 30 упал).
Делаю вывод, что свободные 128G RAM тут сыграли свою роль, хотя вроде
читал что Pg старается избегать системного кеширования, заменяя его
своим.
htop показывает что вся свободная память используется как кеш. впрочем
это всегда так
соответственно вопросы:
есть ли рекомендации по тому стоит ли и сколько оставлять памяти
системе?
имеет ли смысл играться с включением huge pages на таком количестве
памяти (даст ли профиты, какие?)
PS: Pg 9.5
--
. ''`. 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
Вложения
>> Далее Хецнер стал предлагать хосты 256G RAM на 30% дешевле чем хосты 128G >> RAM ну мы и переехали на такой хост. >> CPU точно такой же. контроллер HDD такой же (с батарейкой), HDD такие >> же (+-) >> >> Запустил с точно такими же конфигами как и на предыдущем хосте и вижу: >> нагрузка существенно упала (load average вдвое и даже disk io >> процентов на 30 упал). >> Делаю вывод, что свободные 128G RAM тут сыграли свою роль, хотя вроде >> читал что Pg старается избегать системного кеширования, заменяя его >> своим. > Я думаю сыграло dump/restore, база на новом месте пока более > "консистентная". не, dump/restore разумеется не делался: реплику переключили в режим мастера, то есть "консистентность" файлов там 1:1 как на боевой БД было -- . ''`. 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