|
Насколько критичны завышенные настройки выделения памяти?
|
|||
---|---|---|---|
#18+
Всем доброго дня. Ситуация такая: На продуктивном сервере, с 36Гб оперативки, запущен один кластер postgres с парой сомнительных настроек. Поменять то их надо будет конечно, но вот хочу узнать во что такие настройки могут вылиться и насколько критично эту ситуацию надо исправлять (так как нет возможности просто так ребутнуть базу). shared_buffers = 8Gb - тут все ок max_connections = 1000 - запредельно много, не требуется вроде там столько соединений, но не смертельно. work_mem = 10GB - вот это по моему мнению самый трэш и возможные грабли. Это же максималка на одно соединение, да еще и больше shared_buffers Сервер вроде работает уже давно, о падениях не сообщали, но вот хочется знать как поведет себя postgres если все-таки одно или пару соединений захотят отхавать по 10Gb. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2020, 14:11 |
|
Насколько критичны завышенные настройки выделения памяти?
|
|||
---|---|---|---|
#18+
D0KX Это же максималка на одно соединение work_mem это максимум на один узел в плане. Один запрос может взять несколько work_mem. D0KX как поведет себя postgres если все-таки одно или пару соединений захотят отхавать по 10Gb. Попытается съесть сколько понадобится. Если повезёт - ядро скажет на malloc "прости братец, нету" и backend отменит запрос. Если не повезёт - придёт OOM и сложит базу в recovery. D0KX так как нет возможности просто так ребутнуть базу Для изменения work_mem ребут не нужен. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2020, 14:32 |
|
|
start [/forum/topic.php?fid=53&fpage=30&tid=1994760]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
63ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 160ms |
0 / 0 |