История изменений

Сразу видно опыт богатого общения с вендорами 1C :))))

Зато у меня есть богатый опыт общения с PostgreSQL-цыганями

И дикость это думать и верить что вендоры из 1С что то понимают в пг а тем более под линукс ;)

Смотрите, вот рекомендации по настройке БД от 1С: https://its.1c.ru/db/metod8dev#content:5866:hdoc, в целом они вменяемы за исключеним следующих пунктов:

• max_connections и max_locks_per_transaction какие-то черезчур здоровые, видимо связано с общей архитектурой приложения, PostgreSQL точно не вытянет 2000 активных соединений, да и даже в 500 верится слабо, про PgBouncer упоминаний нет и понятно почему (подсказка: он не работоспособен, от yandex есть OpenSource разрабоки правда: https://github.com/yandex/odyssey)
• work_mem = RAM/32..64 или 32MB..128MB - вот видно, что такой сайзинг в 2000 соединений не влезает никак, видимо опять же расчет на то, что активных соединений не так уж и много (у меня есть предчувствие, что чтобы это правильно сайзить, нужно temp на ramdisk выносить, но руки не дошли проверить гипотезу)
• shared_buffers = RAM/4 - это стандартная рекомендация от PostgreSQL, но это тоже «вендор», видимо написали так, чтобы ссаными тряпками не закидали (есть подозрение что в реальности нужно 1/2 или даже 3/4 ставить, но нужно проверять)
• synchronous_commit = off - за отказ от durability нужно сразу бить в лицо

А вот видосик от цыган: https://pgconf.ru/rmedia/2020/%D0%90%D0%BD%D1%82%D0%BE%D0%BD%20%D0%94%D0%BE%D1%80%D0%BE%D1%88%D0%BA%D0%B5%D0%B2%D0%B8%D1%87%20RU.mp4 (https://pgconf.ru/en/talk/1588650) - 3 часа откровенного бреда чуть ли не по каждому пункту.

Со стороны уних админа ручек, которы можно крутить крайне мало (ну вот такая вот БД, которая работает плохо везде), вот за чем нужно проследить:

• файловая система не должна быть «экзотической» - старое доброе семейство ext здесь наше все
• проследить, чтобы huge pages были настроены в операционной системе (если память считается сотнями гигабайт, то точно нужно) - transparent huge pages работают так себе, в конфиге постргреса выставить huge_pages=on - идея в том, чтобы БД не запускалась вообще если не удалось захватить страницы
• проследить, чтобы допустимый размер очередей на дисках соответствовал реальности - гипервизорам свойственно значительно завышать реальные цифры, в итоге БД уходит в кому раньше положенного
• открутить read ahead в сторону, отличную от рекомендаций из интернета (ну вот не должно быть такого, что чтобы прочесть блок размером 8K с диска нужно было был читать 4M)

Сразу видно опыт богатого общения с вендорами 1C :))))

Зато у меня есть богатый опыт общения с PostgreSQL-цыганями

И дикость это думать и верить что вендоры из 1С что то понимают в пг а тем более под линукс ;)

Смотрите, вот рекомендации по настройке БД от 1С: https://its.1c.ru/db/metod8dev#content:5866:hdoc, в целом они вменяемы за исключеним следующих пунктов:

• max_connections и max_locks_per_transaction какие-то черезчур здоровые, видимо связано с общей архитектурой приложения, PostgreSQL точно не вытянет 2000 активных соединений, да и даже в 500 верится слабо
• work_mem = RAM/32..64 или 32MB..128MB - вот видно, что такой сайзинг в 2000 соединений не влезает никак, видимо опять же расчет на то, что активных соединений не так уж и много
• shared_buffers = RAM/4 - это стандартная рекомендация от PostgreSQL, но это тоже «вендор», видимо написали так, чтобы ссаными тряпками не закидали
• synchronous_commit = off - за отказ от durability нужно сразу бить в лицо

А вот видосик от цыган: https://pgconf.ru/rmedia/2020/%D0%90%D0%BD%D1%82%D0%BE%D0%BD%20%D0%94%D0%BE%D1%80%D0%BE%D1%88%D0%BA%D0%B5%D0%B2%D0%B8%D1%87%20RU.mp4 (https://pgconf.ru/en/talk/1588650) - 3 часа откровенного бреда чуть ли не по каждому пункту.

Со стороны уних админа ручек, которы можно крутить крайне мало (ну вот такая вот БД, которая работает плохо везде), вот за чем нужно проследить:

• файловая система не должна быть «экзотической» - старое доброе семейство ext здесь наше все
• проследить, чтобы huge pages были настроены в операционной системе (если память считается сотнями гигабайт, то точно нужно) - transparent huge pages работают так себе, в конфиге постргреса выставить huge_pages=on - идея в том, чтобы БД не запускалась вообще если не удалось захватить страницы
• проследить, чтобы допустимый размер очередей на дисках соответствовал реальности - гипервизорам свойственно значительно завышать реальные цифры, в итоге БД уходит в кому раньше положенного
• открутить read ahead в сторону, отличную от рекомендаций из интернета (ну вот не должно быть такого, что чтобы прочесть блок размером 8K с диска нужно было был читать 4M)