Гость
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / OOM Killer убивает Postgres при ANALYZE / 16 сообщений из 16, страница 1 из 1
23.07.2018, 12:25
    #39677625
alega19
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
Система: 1Cpu, 1Gb RAM, 30GB HDD, Ubuntu 16.04 64bit, Postgresql 10.4
Настройки по памяти уже занизил до смешных. Вот основные незакомментированные параметры из postgresql.conf:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
#MEM:
shared_buffers = 128MB
temp_buffers = 8MB
work_mem = 2MB
maintenance_work_mem = 32MB
max_stack_depth = 2MB

#WAL:
fsync = on
synchronous_commit = on
wal_buffers = -1
checkpoint_timeout = 5min
max_wal_size = 1GB

#QUERY TUNING:
default_statistics_target = 1000

#AUTOVACUUM:
autovacuum_max_workers = 1

Postgres перезапускал после изменения настроек.

Далее в psql ввожу: analyze my_table; # в таблице около 8млн записей
Запрос некоторое время работает. Процесс постгреса начинает отжирать 26% памяти:
Код: plaintext
1.
  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
28610 postgres  20   0  549660 271380  40936 R 72.7 26.7   0:15.71 postgres

И OOM Killer убиват постгрес:
Код: plaintext
1.
SSL SYSCALL error: EOF detected
The connection to the server was lost. Attempting reset: Failed.

Не понимаю почему OOM Killer просыпается - памяти вроде хватает?
И, главное, почему запрос ANALYZE отъедает так много памяти при низких настройках?
...
Рейтинг: 0 / 0
23.07.2018, 12:34
    #39677643
alega19
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
Снизил настройки по памяти еще:
Код: plaintext
1.
2.
3.
4.
shared_buffers = 64MB
temp_buffers = 4MB
work_mem = 1MB
maintenance_work_mem = 4MB
max_stack_depth = 2MB
Analyze отработал, но процесс на глазах дорос по памяти до 36%. Почему так много?
...
Рейтинг: 0 / 0
23.07.2018, 13:10
    #39677684
Синий Слон
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
maintance_work_mem=-1 ?
...
Рейтинг: 0 / 0
23.07.2018, 13:11
    #39677685
Синий Слон
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
А, вижу.


maintenance_work_mem = 4MB



Вроде только это влияет.

work_mem тут не при чем.
...
Рейтинг: 0 / 0
23.07.2018, 14:33
    #39677730
Павел Лузанов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
Синий Слон,

default_statistics_target = 1000

Сознательно увеличили (по умолчанию 100) ?
...
Рейтинг: 0 / 0
23.07.2018, 16:09
    #39677776
alega19
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
Павел Лузановdefault_statistics_target = 1000

Сознательно увеличили (по умолчанию 100) ?
Да. Сотни мало оказалось для таблицы 5млн (сейчас уже 8млн) строк. Планировщик неоптимально работал. Мне с этим вопросом Maxim Boguk помог: http://www.sql.ru/forum/1296850/kak-uskorit-select-s-vysokoy-variativnostu-vysokoselektivnyh-where-i-sortirovkoy .


Синий Слон, методом проб обнаружил, что при моих изначальных параметрах shared_buffers дразнил OOM Killer во время analyze.
Поставил shared_buffers=80MB и норм. А вот при 100MB - уже валится.

Почему так мало на машине с 1GB - наверное из-за других сервисов в системе (Nginx, UWSGI+Django, демон на питоне).
Но все-таки я не понимаю почему процесс запроса "ANALYZE my_table;" пожирает до 36% памяти ~ 360MB, в то время как в настройках все значения скромнее. При текущих shared_buffers + maintenance_work_mem + temp_buffers + work_mem = 80 + 64 + 8 + 4 = 156 MB, но никак не 360. 200 MB - большая разница, чтобы считать накладными расходами на C runtime, стек и т.п. Почему постгрес это позволяет?
...
Рейтинг: 0 / 0
23.07.2018, 16:41
    #39677795
Melkij
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
alega19,

сильно сомневаюсь, что analyze в принципе обращает внимание на work_mem или maintenance_work_mem, не нашёл упоминаний в исходнике. И, тем более, вряд ли умеет скатываться во временные файлы как-то иначе кроме как через системный swap, которого у вас похоже вовсе нет.
...
Рейтинг: 0 / 0
23.07.2018, 17:41
    #39677843
alega19
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
Melkij,

Ну как выяснилось для analyze важен shared_buffers. Который сейчас = 80MB, а процесс аналайза занимает 360MB, что для меня загадка.
А своп и правда отсутствует.
...
Рейтинг: 0 / 0
23.07.2018, 17:44
    #39677845
Melkij
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
alega19,

не выяснилось. shared_buffers - это персистентно занятый при старте базы кусок памяти. И в нём временные данные analyze не размещает. работает в памяти backend'а. Чем больше доступной памяти занято - тем, естественно, меньше свободной и тем раньше придёт OOM.
...
Рейтинг: 0 / 0
23.07.2018, 18:29
    #39677879
alega19
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
Melkij,

понятно. Т.е. shared_buffers дал побочный эффект. Но тогда не ясно как ограничить память для analyze. Не буду же я вручную каждую ночь уменьшать shared_buffers, чтобы влез analyze, вызывать его и возвращать память обратно в shared_buffers?
...
Рейтинг: 0 / 0
23.07.2018, 18:58
    #39677892
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
alega19Melkij,

понятно. Т.е. shared_buffers дал побочный эффект. Но тогда не ясно как ограничить память для analyze. Не буду же я вручную каждую ночь уменьшать shared_buffers, чтобы влез analyze, вызывать его и возвращать память обратно в shared_buffers?

Ммм не запускать серьезную базу на кофемолке. Сейчас на смартфонах памяти больше чем у вас.
Смешно. Сервер с меньше чем 16GB - по нынешним временам смысла не имеет.

PS: добавьте в систему 4GB swap чтобы OOM killer не вылезал когда не просят и успокойтесь.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
23.07.2018, 19:35
    #39677911
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
alega19,

1CPU? Для базы у которой пяток фоновых процессов работает?..
...
Рейтинг: 0 / 0
23.07.2018, 21:23
    #39677955
alega19
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
Ну ясно, что кофемолка. Я же только разобраться хотел как и что можно тюнить и пока этого хватало. Думал, что и analyze усмирить можно. Спасибо, что про своп напомнили.
...
Рейтинг: 0 / 0
23.07.2018, 22:57
    #39677976
Scott Tiger
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
vyegorovalega19,

1CPU? Для базы у которой пяток фоновых процессов работает?..

Вы не поверите, но и для пяти сотен фоновых процессов хватит одного процессора (ядра). Вопрос только в том, сколько времени им нужно работать.
...
Рейтинг: 0 / 0
23.07.2018, 23:18
    #39677982
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
Scott Tiger,

Это понятно. Но потому и пишу, что работать этим процессам надо, если база нагружается.
...
Рейтинг: 0 / 0
24.07.2018, 07:24
    #39678026
jan2ary
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
OOM Killer убивает Postgres при ANALYZE
alega19Ну ясно, что кофемолка. Я же только разобраться хотел как и что можно тюнить и пока этого хватало. Думал, что и analyze усмирить можно. Спасибо, что про своп напомнили.С другой стороньі 18.4.4. Linux Memory Overcommit
Соответствующий юнит systemd на CentOS7 для 11beta2 уже содержит все нужньіе настройки.
...
Рейтинг: 0 / 0
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / OOM Killer убивает Postgres при ANALYZE / 16 сообщений из 16, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]