|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
Добрейшего времени суток. Нужен совет (да любовь)... Совершил прыжок на 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 ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 08:50 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
MakPolСервер с 8 процами и 16 гигами оперативки, под базу и wal выделены отдельные лунки в хранилке ] обычно на серверах нужно настраивать как минимум отдельные параметры ядра (sysctl) особенно посмотреть стоит в сторону NUMA ну и на худой конец проверить Huge Pages ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 09:08 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
MakPol, многовато work_mem, не находите? 128*300 = 38400. Сколько одновременно сессий подключено? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 09:09 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
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' ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 09:17 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
Alex URS, если не сложно - ткните носом, не совсем понял чт онадо проверить, гуглить начал, но за указание куда копать поточнее буду очень признателен ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 09:18 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
MakPolAlex URS, если не сложно - ткните носом, не совсем понял чт онадо проверить, гуглить начал, но за указание куда копать поточнее буду очень признателен что касается free -h при ядрах больше чем 4 - ни о чём, как минимум смотрим numactl для указанного случая предлагаю начать отсюда STFM после читаем как это настраивать PS приступать к настройкам БД можно только после правильной настройки ОС best practices и настройки ОС по дефолту - вещи несовместимые если использовать 8 ядер и не знать что такое NUMA - это беда ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 11:34 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
Alex URS, огромное спасибо! Где-то ядер еще больше, просто есть DBA и есть SYSADMIN и каждый свое делает. Порой на стыке приходится разбираться как одним так и другим. Еще раз спасибо! А проблемы такой до обновления не было, вот и задумался, вдруг кто с подобным сталкивался и/или столкнется ... |
|||
:
Нравится:
Не нравится:
|
|||
11.12.2018, 13:39 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
MakPol, посмотрите в логах базы, какие процессы oom killer прибивает. если он прибивает backend постгресовый, то там будет видно на каком запросе: Код: sql 1. 2.
если запрос есть - попробуйте воспроизвести с ним проблему. на старом мастере своп был? имхо стоит поставить какой-то небольшой и прописать vm.swappiness = 1 в sysctl. выбор shared_buffers, work_mem и max_connections возможно не самый удачный для такой железки. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2018, 07:38 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
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 тоже несколько иначе рекомендует, однако они оказались оптимальными, как ни странно. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2018, 08:12 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
мышки плакали, кололись, но продолжали есть кактус (с) Alexiusна старом мастере своп был?.... это не поможет в случае отсутствия настройки NUMA при указанной конфигурации автора MakPol... Отсюда и думаю, что что-то в постгресе. Методом исключений так сказать... ... тебе чёрным по белому написали в чём проблема, но ты всёравно лезешь в postgresql... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2018, 09:10 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
MakPol, покажите explain этого запроса с обоих серверов (если можно, то explain analyze со старого сервера, если там это быстро выполняется). ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2018, 09:45 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
Alex URS, если 2 абсолютно одинаковых сервера и вот именно на 11 версии при прочих равных проблема, то что надо менять настройки линукса? Не понимаю.... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2018, 12:15 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
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 , иначе опять костыли через "ж" ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2018, 15:44 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
проверьте еще параметр max_parallel_workers_per_gather, его фактическое значение select * from pg_settings where name='max_parallel_workers_per_gather' на oltp параллелизм вполне себе может навредить, надо смотреть планы запросов, там такое поведение также будет заметным ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2018, 15:48 |
|
После прыжка с 9.5 на 11.1 странное поведение, вплоть до прихода OOM
|
|||
---|---|---|---|
#18+
Alex URS, низкий поклон (без сарказма) за пояснения. Да, действительно, я думал по лайту все. Мол параметр типа work присвоить true и будет норм работать )))) 8 процов то 8 но на OpenStack, но куда копать примерно понятно. Ну и оперативы я до 32 догнал, т.к. все же база 6 с лишним терабайт. Буду планы гнать и курить, только уже на другом серваке, тестовом. Там пока полет нормальный, киллера больше не было, но и запрос несколько изменил. Однако с этим все равно буду разбираться. Огромнейшее спасибо!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2018, 19:39 |
|
|
start [/forum/topic.php?fid=53&msg=39746922&tid=1995443]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
50ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 156ms |
0 / 0 |