как правильно почистить pg_xlog?

одну нагруженную БД поставили в режим pg_start_backup (реплику к ней
приделывали), ну и она в этом режиме простояла несколько дней (rsync с
ограничением скорости шел, ну и столько заняло).
теперь в каталоге pg_xlog там накоплено 100500 файлов,
есть ли какая-то команда которая не выводя сервер в оффлайн
принудительно заставит pg почистить этот каталог "прямо сейчас"?
--

. ''`. 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

Покури pg_resetxlog

2016-08-26 13:15 GMT+03:00 Dmitry E. Oboukhov <unera(at)debian(dot)org>:
> одну нагруженную БД поставили в режим pg_start_backup (реплику к ней
> приделывали), ну и она в этом режиме простояла несколько дней (rsync с
> ограничением скорости шел, ну и столько заняло).
> теперь в каталоге pg_xlog там накоплено 100500 файлов,
> есть ли какая-то команда которая не выводя сервер в оффлайн
> принудительно заставит pg почистить этот каталог "прямо сейчас"?
> --
>
> . ''`. 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEAREDAAYFAlfAFssACgkQq4wAz/jiZTdMTACggn8NeRLkjchcFo04L6/qLvGy
> 3/cAn0ypLGyTAji+c3V7ZCUeCFBMelhL
> =O6SD
> -----END PGP SIGNATURE-----
>

Привет.

> 26 авг. 2016 г., в 14:03, Oleg Bartunov <obartunov(at)gmail(dot)com> написал(а):
>
> Покури pg_resetxlog

Не, так делать точно не стоит.

>
> 2016-08-26 13:15 GMT+03:00 Dmitry E. Oboukhov <unera(at)debian(dot)org>:
>> одну нагруженную БД поставили в режим pg_start_backup (реплику к ней
>> приделывали), ну и она в этом режиме простояла несколько дней (rsync с
>> ограничением скорости шел, ну и столько заняло).
>> теперь в каталоге pg_xlog там накоплено 100500 файлов,
>> есть ли какая-то команда которая не выводя сервер в оффлайн
>> принудительно заставит pg почистить этот каталог "прямо сейчас»?

Надо сделать pg_stop_backup() и сказать CHECKPOINT. Потому что xlog’и докидываются новые и удаляются старые именно checkpointer’ом. И кстати, о какой версии postgres’а речь?

>> --
>>
>> . ''`. 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
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>>
>> iEYEAREDAAYFAlfAFssACgkQq4wAz/jiZTdMTACggn8NeRLkjchcFo04L6/qLvGy
>> 3/cAn0ypLGyTAji+c3V7ZCUeCFBMelhL
>> =O6SD
>> -----END PGP SIGNATURE-----
>>
>
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general

--
Да пребудет с вами сила…
https://simply.name/ru

>> Покури pg_resetxlog

> Не, так делать точно не стоит.

да эта утилита не подходит.

её конечно сразу поглядел, но она только оффлайн работает.

>> одну нагруженную БД поставили в режим pg_start_backup (реплику к ней
>> приделывали), ну и она в этом режиме простояла несколько дней (rsync с
>> ограничением скорости шел, ну и столько заняло).
>> теперь в каталоге pg_xlog там накоплено 100500 файлов,
>> есть ли какая-то команда которая не выводя сервер в оффлайн
>> принудительно заставит pg почистить этот каталог "прямо сейчас»?

> Надо сделать pg_stop_backup() и сказать CHECKPOINT. Потому что xlog’и
> докидываются новые и удаляются старые именно checkpointer’ом. И кстати, о какой
> версии postgres’а речь?

и pg_stop_backup и CHECKPOINT я конечно же сделал. проблема в том что
файлов это не уменьшило.
они понемногу стираются самим Pg (видимо когда он делает
CHECKPOINT'ы), но восстановится их количество указанное в конфиге
видимо еще не скоро, ну и я хотел в период когда мало нагрузки ручками
как-то подпихнуть его в этом направлении
--

. ''`. 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

Был хост на Хецнере 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(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

>> Далее Хецнер стал предлагать хосты 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(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