172 похожих чатов

Коллеги, привет! пришла нужда потюнить настройки пг - у нас buffers_backend

на порядок выше buffers_clean (bgwriter не успевает чистить shared_buffers)

я по pg_stat_writer вижу, что он всегда упирается в bgwriter_lru_maxpages

но вот не могу понять про bgwriter_delay - мне бы чтобы понять, адекватный ли он у нас (200 мс на мощном сервере с нвме), хотелось бы понимать, а сколько занимает один прогон bgwriter-а
чтобы сопоставить время работы и время сна

не подскажете откуда бы его достать?

(я понимаю, что такая проблема может быть вызвана и низким shared_buffers, и это мы тоже потюним, но потом вопрос тюнинга bgwriter_delay всё равно будет актуален)

11 ответов

21 просмотр

Из pg_stat_bgwriter же (мониторингом в динамике)? А вообще, tuning bgwriter — дело нетривиальное (и неблагодарное, обычно — "bgwriter is useless to damaging" © Andres Freund).

Dmitry- Автор вопроса
Yaroslav Schekin
Из pg_stat_bgwriter же (мониторингом в динамике)? ...

Там нет, сколько bgwriter тратит времени :-/

Yaroslav Schekin
Из pg_stat_bgwriter же (мониторингом в динамике)? ...

а мы просто максимальное кол-во страниц и минимальное время ставим, заставляя его работать по максимуму

Dmitry
Там нет, сколько bgwriter тратит времени :-/

Если поснимать каждые N секунд, и произвести некоторые арифметические действия — как бы есть. ;) > наверное таки надо его потюнить И может стать только хуже. Т.е. это палка о двух концах.

Yaroslav Schekin
Если поснимать каждые N секунд, и произвести некот...

> И может стать только хуже. он делает работу, которую иначе должны обычные сессии делать. чем больше он делает, тем легче сессиям. я не могу представить ситуацию, когда будет хуже

Виктор Егоров
> И может стать только хуже. он делает работу, кот...

However, the background writer does cause a net overall increase in I/O load, because while a repeatedly-dirtied page might otherwise be written only once per checkpoint interval, the background writer might write it several times as it is dirtied in the same interval.

Виктор Егоров
> И может стать только хуже. он делает работу, кот...

Даже документация может (вот, уже процитировали). ;)

Sergey Gr
However, the background writer does cause a net ov...

и да, и нет. bgwriter привязан к кол-ву блоков котрые запрашивают сессии, чем оно больше, тем более активен bgwriter. если у вас всё влазит в шаренные и всем хватает — он не работает. если не хватает и идёт вытеснение обычными сессиями — он включается и берёт на себя их работу. да, может быть двойная запись. но он снимает нагрузку с сессий, это важнее для общего времени ответа системы.

Sergey Gr
Жаль что bgwriter не параллелится

угу. там много чего интересного, Andres Freund год назад доклад делал. вот тут можно глянуть больше: https://postgr.es/m/20190611032249.kfi7pgqu2ipmlqca@alap3.anarazel.de

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта