AL
а процессы постгреса которые занимают 15GB это размер shared buffers, но общий между всеми процессами постгреса
Size: a a a
2021 February 11
DS
а процессы постгреса которые занимают 15GB это размер shared buffers, но общий между всеми процессами постгреса
хорошо. А что можете сказать про то, что использовано памяти больше половины? (4 строка на моем скрине)
DS
уж простите, я не могу сказать, что хорошо разбираюсь в линукс процессах, но очень интересно разобраться, что происходит
AL
хорошо. А что можете сказать про то, что использовано памяти больше половины? (4 строка на моем скрине)
вы имеете ввиду used 90158720 ?
used это сумма cached, buffers и там еще чего-то
used это сумма cached, buffers и там еще чего-то
KK
да, у вас проблемы не с памятью. "Подтормаживает" скорее всего диск. Возможно случается "write storm", когда грязные страницы из кэша ФС пишутся на диск. С этим можно бороться ... по разному. Но проще всего купить диски по лучше и побольше. SSD очень не любят, когда они забиты под завязку.
AL
посмотрите на команду
iostat -x -m 1 (из пакета sysstat), она умеет показывать утилизацию диска. запустите ее в момент вашиз тормозов, если увидите там util > 60% и await больше 20 (ms) это будет свидетельствовать о том что дисковая подсистема не справляется ( и надо искать уже проблемы на уровне запросов в БД)KK
хорошо. А что можете сказать про то, что использовано памяти больше половины? (4 строка на моем скрине)
Линукс всю свободную память старается пустить под кэш. Так что ваша картинка совершенно нормальная. Про то, что 16Gb шаред памяти в каждом постгресовом процессе не надо суммировать, Алексей вам объяснил.
AL
ну и вообще просто так позапускайте ее на разных серверах, посмотрите на выводы, почитайте справку по ней
DS
AL
уж простите, я не могу сказать, что хорошо разбираюсь в линукс процессах, но очень интересно разобраться, что происходит
если вам действительно интересен топик внутреннего устройства постгреса и есть свободное время, рекомендую почитать на досуге это
http://www.interdb.jp/pg/index.html
http://www.interdb.jp/pg/index.html
YS
Я просто к тому, что work_mem надо умножать на число бэкендов
1000 взято просто как пример
1000 взято просто как пример
Ммм... а почему надо work_mem надо умножать на число бэкендов? ;)
СХ
а как мне обновиться на 12 версию?
он предлагает удалить 9.6
А базы оставит?
бэкапы разумеется есть, но темнеменее.. как правильно делать
он предлагает удалить 9.6
А базы оставит?
бэкапы разумеется есть, но темнеменее.. как правильно делать
KK
ну work-mem - это сколько памяти может заюзать одна нода плана.
Если у вас есть N параллельно выполняющихся запросов, и в них по K операторов, которым может потребоваться память (sort, hash join,...), то вообще говоря они могут отъесть N*K*work_mem памяти. Это если статистика правильная и оптимизатор не ошибся с селективностью. А так могут и больше сожрать...
Если у вас есть N параллельно выполняющихся запросов, и в них по K операторов, которым может потребоваться память (sort, hash join,...), то вообще говоря они могут отъесть N*K*work_mem памяти. Это если статистика правильная и оптимизатор не ошибся с селективностью. А так могут и больше сожрать...
YS
ну work-mem - это сколько памяти может заюзать одна нода плана.
Если у вас есть N параллельно выполняющихся запросов, и в них по K операторов, которым может потребоваться память (sort, hash join,...), то вообще говоря они могут отъесть N*K*work_mem памяти. Это если статистика правильная и оптимизатор не ошибся с селективностью. А так могут и больше сожрать...
Если у вас есть N параллельно выполняющихся запросов, и в них по K операторов, которым может потребоваться память (sort, hash join,...), то вообще говоря они могут отъесть N*K*work_mem памяти. Это если статистика правильная и оптимизатор не ошибся с селективностью. А так могут и больше сожрать...
А могут "сожрать" вообще ноль work_mem, если использующих её plan nodes нигде нет (что нередко в "чистой" OLTP-нагрузке).
Т.е. почему именно так нужно считать-то (это на основании опыта / статистики, или просто "на глазок")?
Т.е. почему именно так нужно считать-то (это на основании опыта / статистики, или просто "на глазок")?
KK
это пессимистическая оценка сверху. Обычно конечно гораздо меньше памяти из-за work_mem-а расходуется.
YS
это пессимистическая оценка сверху. Обычно конечно гораздо меньше памяти из-за work_mem-а расходуется.
Понятно, спасибо!
YS
VY
9.5 EOL
ХБ
Привет! Видимо вечер сказывается, никак не соображу из документации, как пользоваться тегом nosync в patroni. Подскажите пример плиз.
ХБ
Мне нужно одному из серверов сказать, чтобы он никогда не становился мастером. Это же через nosync реализуется?