Гость
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM / 16 сообщений из 16, страница 1 из 1
11.12.2018, 08:50
    #39745737
MakPol
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
Добрейшего времени суток.

Нужен совет (да любовь)...
Совершил прыжок на PG 11 с 9.5, по сути дела отцепил реплику и сделал pg_update, ну а настройки не в тупую перекинул, а поредактировал уже файлик от 11. Железо на реплике 1 в 1 с тем, что было на 9.5, но... при всем при этом выполняя один и тот же перенос данных на 9.5 все как и раньше без проблем, а на 11.1 при тех же настройках - кончается оператива и приходит OOM-Killer который делает "server process (PID 19159) was terminated by signal 9: Killed"

Сервер с 8 процами и 16 гигами оперативки, под базу и wal выделены отдельные лунки в хранилке
Больше всего не понимаю, что не так стало после обновления, когда вроде бы как даже быстрее все должно стать, а нет....неужели бага 11.1, на которую нарвался именно я...

Чтобы не быть голословным вот настройки
max_connections = 300
superuser_reserved_connections = 3
unix_socket_directories = '/var/run/postgresql'
ssl = on
ssl_cert_file = '/etc/ssl/certs/ssl-cert-snakeoil.pem'
ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'
shared_buffers = 7680MB
temp_buffers = 8MB
work_mem = 128MB
maintenance_work_mem = 1536MB
dynamic_shared_memory_type = posix
max_files_per_process = 1000
vacuum_cost_delay = 0
vacuum_cost_page_dirty = 20
vacuum_cost_limit = 200
bgwriter_delay = 200ms
max_worker_processes = 8
wal_level = replica
wal_compression = off
wal_log_hints = on
wal_buffers = 16MB
checkpoint_timeout = 1h
max_wal_size = 38GB
min_wal_size = 80MB
checkpoint_completion_target = 0.95 # checkpoint target duration, 0.0 - 1.0
checkpoint_warning = 30s
max_wal_senders = 5
wal_keep_segments = 3500
wal_sender_timeout = 60s
hot_standby = on
max_standby_streaming_delay = 30s
effective_cache_size = 9GB
default_statistics_target = 100
log_rotation_age = 1d
client_min_messages = warning
log_min_messages = warning
log_min_error_statement = warning
log_min_duration_statement = 5s
log_line_prefix = '%m [%p] %q%u@%d '
log_timezone = 'UTC'
cluster_name = '11/main'
stats_temp_directory = '/var/run/postgresql/11-main.pg_stat_tmp'
autovacuum_max_workers = 20
autovacuum_vacuum_threshold = 50
autovacuum_analyze_threshold = 50
autovacuum_analyze_scale_factor = 0.1
autovacuum_freeze_max_age = 1000000000
autovacuum_multixact_freeze_max_age = 400000000
vacuum_freeze_min_age = 50000000
vacuum_freeze_table_age = 600000000
vacuum_multixact_freeze_min_age = 5000000
vacuum_multixact_freeze_table_age = 150000000
datestyle = 'iso, mdy'
timezone = 'UTC'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'
shared_preload_libraries = 'pg_stat_statements,pg_pathman'
pg_stat_statements.max = 1000
pg_stat_statements.track = top
deadlock_timeout = 1s
max_locks_per_transaction = 250
max_pred_locks_per_transaction = 64
...
Рейтинг: 0 / 0
11.12.2018, 09:08
    #39745745
Alex URS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
MakPolСервер с 8 процами и 16 гигами оперативки, под базу и wal выделены отдельные лунки в хранилке
]
обычно на серверах нужно настраивать как минимум отдельные параметры ядра (sysctl)
особенно посмотреть стоит в сторону NUMA
ну и на худой конец проверить Huge Pages
...
Рейтинг: 0 / 0
11.12.2018, 09:09
    #39745746
gav21
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
MakPol,
многовато work_mem, не находите?
128*300 = 38400.
Сколько одновременно сессий подключено?
...
Рейтинг: 0 / 0
11.12.2018, 09:17
    #39745749
MakPol
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
gav21, сессий может и до 200 дойти

Что "забавно", пробовал с той же базой но настройки взять околодефаултные и та же история, также кушает, кушает и шлеп...
А по умолчанию там #work_mem = 4MB

Наблюдал за free -h там примерно так
total used free shared buffers cached
Mem: 15G 15G 93M 7.7G 25M 14G
-/+ buffers/cache: 854M 14G
Swap: 0B 0B 0B



max_connections = 100 # (change requires restart)
unix_socket_directories = '/var/run/postgresql' # comma-separated list of directories
ssl = on
ssl_cert_file = '/etc/ssl/certs/ssl-cert-snakeoil.pem'
ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'
shared_buffers = 128MB # min 128kB
dynamic_shared_memory_type = posix # the default is the first option
max_wal_size = 1GB
min_wal_size = 80MB
log_line_prefix = '%m [%p] %q%u@%d ' # special values:
log_timezone = 'UTC'
cluster_name = '11/main' # added to process titles if nonempty
stats_temp_directory = '/var/run/postgresql/11-main.pg_stat_tmp'
datestyle = 'iso, mdy'
timezone = 'UTC'
lc_messages = 'en_US.UTF-8' # locale for system error message
lc_monetary = 'en_US.UTF-8' # locale for monetary formatting
lc_numeric = 'en_US.UTF-8' # locale for number formatting
lc_time = 'en_US.UTF-8' # locale for time formatting
default_text_search_config = 'pg_catalog.english'
shared_preload_libraries = 'pg_stat_statements,pg_pathman'
...
Рейтинг: 0 / 0
11.12.2018, 09:18
    #39745750
MakPol
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
Alex URS, если не сложно - ткните носом, не совсем понял чт онадо проверить, гуглить начал, но за указание куда копать поточнее буду очень признателен
...
Рейтинг: 0 / 0
11.12.2018, 11:34
    #39745857
Alex URS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
MakPolAlex URS, если не сложно - ткните носом, не совсем понял чт онадо проверить, гуглить начал, но за указание куда копать поточнее буду очень признателен

что касается free -h при ядрах больше чем 4 - ни о чём, как минимум смотрим numactl
для указанного случая предлагаю начать отсюда STFM
после читаем как это настраивать

PS
приступать к настройкам БД можно только после правильной настройки ОС
best practices и настройки ОС по дефолту - вещи несовместимые
если использовать 8 ядер и не знать что такое NUMA - это беда
...
Рейтинг: 0 / 0
11.12.2018, 13:39
    #39745984
MakPol
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
Alex URS, огромное спасибо!
Где-то ядер еще больше, просто есть DBA и есть SYSADMIN и каждый свое делает. Порой на стыке приходится разбираться как одним так и другим.

Еще раз спасибо!

А проблемы такой до обновления не было, вот и задумался, вдруг кто с подобным сталкивался и/или столкнется
...
Рейтинг: 0 / 0
12.12.2018, 07:38
    #39746408
Alexius
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
MakPol,

посмотрите в логах базы, какие процессы oom killer прибивает. если он прибивает backend постгресовый, то там будет видно на каком запросе:
Код: sql
1.
2.
2018-10-01 04:27:19.620 UTC 29638 @ from  [vxid: txid:0] [] LOG:  server process (PID 27601) was terminated by signal 9: Killed
2018-10-01 04:27:19.620 UTC 29638 @ from  [vxid: txid:0] [] DETAIL:  Failed process was running: SELECT...



если запрос есть - попробуйте воспроизвести с ним проблему.

на старом мастере своп был? имхо стоит поставить какой-то небольшой и прописать vm.swappiness = 1 в sysctl.

выбор shared_buffers, work_mem и max_connections возможно не самый удачный для такой железки.
...
Рейтинг: 0 / 0
12.12.2018, 08:12
    #39746420
MakPol
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
Alexius, огромное спасибо!

Да, запрос есть и с ним воспроизводится проблема. Что забавно, я сразу не написал, так это то, что на стандартных настройках (вообще тех что идут из коробки)
data_directory = '/var/lib/postgresql/11/main' # use data in another directory
hba_file = '/etc/postgresql/11/main/pg_hba.conf' # host-based authentication file
ident_file = '/etc/postgresql/11/main/pg_ident.conf' # ident configuration file
external_pid_file = '/var/run/postgresql/11-main.pid' # write an extra PID file
port = 5432 # (change requires restart)
max_connections = 100 # (change requires restart)
unix_socket_directories = '/var/run/postgresql' # comma-separated list of directories
ssl = on
ssl_cert_file = '/etc/ssl/certs/ssl-cert-snakeoil.pem'
ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'
shared_buffers = 128MB # min 128kB
dynamic_shared_memory_type = posix # the default is the first option
max_wal_size = 1GB
min_wal_size = 80MB
log_line_prefix = '%m [%p] %q%u@%d ' # special values:
log_timezone = 'UTC'
cluster_name = '11/main' # added to process titles if nonempty
stats_temp_directory = '/var/run/postgresql/11-main.pg_stat_tmp'
datestyle = 'iso, mdy'
timezone = 'UTC'
lc_messages = 'en_US.UTF-8' # locale for system error message
lc_monetary = 'en_US.UTF-8' # locale for monetary formatting
lc_numeric = 'en_US.UTF-8' # locale for number formatting
lc_time = 'en_US.UTF-8' # locale for time formatting
default_text_search_config = 'pg_catalog.english'
include_dir = 'conf.d' # include files ending in '.conf' from

абсолютно такое же падение и точно такая же ситуация с памятью.
Отсюда и думаю, что что-то в постгресе. Методом исключений так сказать...

А запрос - да известен
автор...UTC [1361] LOG: server process (PID 28427) was terminated by signal 9: Killed
...UTC [1361] DETAIL: Failed process was running: create table tab1 as select za.* from tab2 b left join trends a on b.id = a.id and b.ts = a.ts and a.ts >= 123456789 where a.id is null;

Ну а сервера ну вот 1 в 1, да в разных стойках но вот они братья близнецы, разлиты скажем так одним взмахом.

P.S. Вот думаю, может с нововведением в 11 это как-то связано
авторВозможно параллельное выполнение CREATE TABLE .. AS, CREATE MATERIALIZED VIEW и некоторых запросов с UNION

Ведь с этими ужасными shared_buffers, work_mem и max_connections почти два года жил и вот не было проблем, тоже немного из теории выбиваются они и pg_tune тоже несколько иначе рекомендует, однако они оказались оптимальными, как ни странно.
...
Рейтинг: 0 / 0
12.12.2018, 09:10
    #39746429
Alex URS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
мышки плакали, кололись, но продолжали есть кактус (с)

Alexiusна старом мастере своп был?....
это не поможет в случае отсутствия настройки NUMA при указанной конфигурации автора

MakPol...
Отсюда и думаю, что что-то в постгресе. Методом исключений так сказать...
...
тебе чёрным по белому написали в чём проблема, но ты всёравно лезешь в postgresql...
...
Рейтинг: 0 / 0
12.12.2018, 09:45
    #39746446
Alexius
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
MakPol,

покажите explain этого запроса с обоих серверов (если можно, то explain analyze со старого сервера, если там это быстро выполняется).
...
Рейтинг: 0 / 0
12.12.2018, 12:15
    #39746574
MakPol
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
Alex URS, если 2 абсолютно одинаковых сервера и вот именно на 11 версии при прочих равных проблема, то что надо менять настройки линукса? Не понимаю....
...
Рейтинг: 0 / 0
12.12.2018, 15:44
    #39746759
Alex URS
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
MakPolAlex URS, если 2 абсолютно одинаковых сервера и вот именно на 11 версии при прочих равных проблема, то что надо менять настройки линукса? Не понимаю....

представь себе...
11 Postgresql имеет модернизированную архитектуру по взаимодействию с процессами в сравнении с 9, чему ж тут удивляться?
а то, что изменять нужно именно Linux, так RTFM по linux

а что касается NUMA - даже для i7, у которого все ядра, контроллер памяти и кэш находятся на одном кристалле с модернизированной архитектурой Nehalem, имеем:
Enable NUMA (Non Uniform Memory Access) support.
For 64-bit this is recommended if the system is Intel Core i7 (or later), AMD Opteron, or EM64T NUMA.

и после этой рекомендации инет начинает пестрить сообщениями -
"WTF?", "на кой мне это, у меня ж 1 proc?"
и ему вторит другой - "чувак, не парься, я не включал и у меня всё работает. чтото напутали эти разрабы"

и считают себя умнее создателей процессоров и писавших такие рекомендации...

а у тебя процессоров аж 8, а про NUMA не в зуб ногой... 8 процессоров и 16Gb ЦПУ без NUMA - это по 2Gb на ядро (ноду) без учёта нужд ОС ...2Gb, Карл...
Память выделяется на каждой ноде отдельно. Поэтому можно потребить всю свободную память на одной ноде, а другую — недогрузить. (это свойственно базам данных)

предвижу несколько сценариев

сценарий первый: Пос Грес видит еду на витрине, он пытается поесть, но через стекло не получается, в итоге он умирает с голодухи прямо около витрины, издав умирающее OOM...
сценарий второй: Пос Грес получает требуемую еду в нужном объеме (это когда всёже поковырялись в конфиге БД, забыв про ОС), но она пластиковая, хоть пахнет и выглядит как настоящяя, он не может её переварить и умирает с голодухи, издав умирающее OOM...
концовка: Здравый Смысл приводит Нуму, она делает своё дело - все сыты. Все поют финальную песню к которой подключается Хуга Пагес...


для ОС нет разницы, а вот БД очень чутко на такое реагирует, так что не стоит заниматся "самолечением" БД через плацебо
на форумах linux такого не посоветуют, оно и понятно, но тут же форум по БД - это чуть другая настройка ОС, и нужно иметь это ввиду

после настройки NUMA смотреть в сторону sysctl , иначе опять костыли через "ж"
...
Рейтинг: 0 / 0
12.12.2018, 15:48
    #39746764
iriswind
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
проверьте еще параметр max_parallel_workers_per_gather, его фактическое значение
select * from pg_settings where name='max_parallel_workers_per_gather'
на oltp параллелизм вполне себе может навредить, надо смотреть планы запросов, там такое поведение также будет заметным
...
Рейтинг: 0 / 0
12.12.2018, 19:39
    #39746920
MakPol
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
Alex URS, низкий поклон (без сарказма) за пояснения. Да, действительно, я думал по лайту все. Мол параметр типа work присвоить true и будет норм работать ))))

8 процов то 8 но на OpenStack, но куда копать примерно понятно. Ну и оперативы я до 32 догнал, т.к. все же база 6 с лишним терабайт.

Буду планы гнать и курить, только уже на другом серваке, тестовом.

Там пока полет нормальный, киллера больше не было, но и запрос несколько изменил. Однако с этим все равно буду разбираться.

Огромнейшее спасибо!!!
...
Рейтинг: 0 / 0
12.12.2018, 19:41
    #39746922
MakPol
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
iriswind, песочницу отолью и буду там пробовать воспроизвести ситуацию.
Реплику уже тоже обновил, на ней можно эксперементить, чтобы общее дело не страдало.
...
Рейтинг: 0 / 0
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM / 16 сообщений из 16, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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