Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Периодические зависания: найти причину / 6 сообщений из 6, страница 1 из 1
04.02.2016, 16:34
    #39163164
Kenshin
Kenshin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Периодические зависания: найти причину
Добрый день!

PostgreSQL 9.3, Centos 6.5.
Периодически база данных подвисает: все запросы, которые выполнялись за доли секунды, начинают выполняться десятки секунд. В pgAdmin окно "Состояние сервера" показывает резкое увеличение числа активных запросов. Само это окно также подвисает.
Примерно через полминуты (иногда быстрее) все приходит в норму.
Логирование запросов никаких аномалий, которые предшествуют данной проблеме, не выявляет. Единственное - показывает частое выполнение autovacuum по нескольким таблицам, но за доли секунды.
Нагрузка на процессор (смотрю через top) не растет - процессор не нагружен совсем. Памяти свободной (точнее, кешированной) достаточно.
PostgreSQL настроен с помощью pgtune.

Подскажите пожалуйста (я новичок в администрировании PostgreSQL) - каким образом можно поймать причину этих зависаний?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
04.02.2016, 19:07
    #39163299
vyegorov
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Периодические зависания: найти причину
Kenshin,

Приведите вывод запроса:
Код: sql
1.
SELECT name,setting FROM pg_settings WHERE NOT source IN ('default','overdue');



Просмотрите лог базы на наличие предупреждений и более значимых сообщений.


Приведите вывод команды:
Код: sql
1.
sysctl -a|egrep '^vm.(swap|overcommit|dirty)'



Похоже на чепойнт — либо в базе, либо в ядре :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
05.02.2016, 08:38
    #39163491
Kenshin
Kenshin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Периодические зависания: найти причину
SELECT name,setting FROM pg_settings WHERE NOT source IN ('default','overdue');
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
             name             |                 setting
------------------------------+-----------------------------------------
 application_name             | psql
 checkpoint_completion_target | 0.7
 checkpoint_segments          | 8
 client_encoding              | UTF8
 config_file                  | /var/lib/pgsql/9.3/data/postgresql.conf
 data_checksums               | off
 data_directory               | /var/lib/pgsql/9.3/data
 DateStyle                    | ISO, DMY
 default_statistics_target    | 10
 default_text_search_config   | pg_catalog.english
 effective_cache_size         | 3407872
 hba_file                     | /var/lib/pgsql/9.3/data/pg_hba.conf
 ident_file                   | /var/lib/pgsql/9.3/data/pg_ident.conf
 lc_collate                   | en_US.UTF-8
 lc_ctype                     | en_US.UTF-8
 lc_messages                  | en_US.UTF-8
 lc_monetary                  | en_US.UTF-8
 lc_numeric                   | en_US.UTF-8
 lc_time                      | en_US.UTF-8
 listen_addresses             | *
 log_autovacuum_min_duration  | 0
 log_checkpoints              | on
 log_destination              | stderr
 log_directory                | pg_log
 log_filename                 | postgresql-%a.log
 log_line_prefix              | %t [%p]: [%l-1]
 log_lock_waits               | on
 log_min_duration_statement   | 5000
 log_rotation_age             | 1440
 log_rotation_size            | 0
 log_temp_files               | 0
 log_timezone                 | W-SU
 log_truncate_on_rotation     | on
 logging_collector            | on
 maintenance_work_mem         | 1048576
 max_connections              | 200
 max_stack_depth              | 2048
 port                         | 5432
 server_encoding              | UTF8
 shared_buffers               | 1048576
 TimeZone                     | W-SU
 transaction_deferrable       | off
 transaction_isolation        | read committed
 transaction_read_only        | off
 wal_buffers                  | 512
 work_mem                     | 180224
(46 rows)

sysctl -a|egrep '^vm.(swap|overcommit|dirty)'
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.dirty_background_ratio = 10
vm.dirty_background_bytes = 0
vm.dirty_ratio = 20
vm.dirty_bytes = 0
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000
vm.swappiness = 60

Лог за вчера содержит 227 записей про checkpoint, каждая примерно такого вида:
Код: plaintext
1.
2.
3.
4.
2016-02-04 16:52:32 MSK [2754]: [2787-1] LOG:  checkpoint starting: time
2016-02-04 16:56:02 MSK [2754]: [2788-1] LOG:  checkpoint complete: wrote 14815
buffers (1.4%); 0 transaction log file(s) added, 0 removed, 6 recycled; write=20
9.538 s, sync=0.669 s, total=210.219 s; sync files=691, longest=0.112 s, average
=0.000 s

Есть сообщения вида:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
2016-02-04 12:52:04 MSK [21428]: [2-1] LOG:  process 21428 still waiting for Sha
reLock on transaction 144836288 after 1000.100 ms
2016-02-04 12:55:15 MSK [15021]: [1-1] LOG:  process 15021 still waiting for Sha
reLock on transaction 144831399 after 1000.205 ms
2016-02-04 12:58:17 MSK [21428]: [4-1] LOG:  process 21428 acquired ShareLock on
 transaction 144836288 after 373905.482 ms
2016-02-04 12:58:33 MSK [26205]: [1-1] LOG:  process 26205 still waiting for Sha
reLock on transaction 144848775 after 1003.623 ms
2016-02-04 12:58:51 MSK [26205]: [3-1] LOG:  process 26205 acquired ShareLock on
 transaction 144848775 after 18709.440 ms
2016-02-04 12:59:04 MSK [15021]: [3-1] LOG:  process 15021 acquired ShareLock on
 transaction 144831399 after 230416.852 ms
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
05.02.2016, 10:48
    #39163623
vyegorov
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Периодические зависания: найти причину
Kenshin
Код: plaintext
1.
2.
3.
4.
5.
SELECT name,setting FROM pg_settings WHERE NOT source IN ('default','overdue');
             name             |                 setting
------------------------------+-----------------------------------------
 checkpoint_completion_target | 0.7
 checkpoint_segments          | 8
 ...

8 сегментов мало. Поднимите хотя бы до 64 (что соответствует 1Гб WAL).

Kenshin
Код: plaintext
1.
2.
3.
SELECT name,setting FROM pg_settings WHERE NOT source IN ('default','overdue');
 ...
 shared_buffers               | 1048576
 ...

Вам необходимо 8Гб? Если места в кэше с избытком, то будут накапливаться грязные буфера и чекпойнт будет тяжелым. Если у вас достаточно интенсивная пишущая нагрузка, я бы проверил и, возможно, понизил.

поставьте расширение `pg_buffercache` и посчитайте буфера так:
Код: sql
1.
2.
3.
4.
select usagecount, count(*),
       sum(count(*)) over (order by usagecount desc),
       round(sum(count(*)) over (order by usagecount desc)*100.0/sum(count(*)) over (), 2)
  from pg_buffercache group by usagecount;


ОСТОРОЖНО: запрос тяжелый и в продукции может иметь неприятный эффект.

Чем выше usagecount, тем более "горячие" данные. `shared_buffers` "должны" покрывать буфера 5,4,3 — в последней колонке будут необходимые проценты от вашего текущего значенияю, я бы взял значение для `usagecount=3` и соответственно поправил бы.

Kenshin
Код: plaintext
1.
2.
3.
sysctl -a|egrep '^vm.(swap|overcommit|dirty)'
 [code=plaintext]vm.overcommit_memory = 0
...
vm.swappiness = 60

Первый параметр отвечает за поведение ядра при нехватке виртуальной памяти. При вашей (умолчательной) настройке, ядро будет выдавать виртуальной памяти процессам больше, чем есть (реже встречается Not enough memory ошибка). Однако, если оно "навыдает" виртуалки и все процессы "вдруг" её потребуют, то ядро (для высвобождения физической памяти) найдет процесс, который (1) работает давно (2) отхватил существенный кусок памяти и (3) был неактивным — и прервёт его. Увы, под такие характеристики отлично попадают процессы Postgres'а (и других СУБД), что приводит к аварийному перезапуску базы.


меняйте на `vm.overcommit_memory=2` на всех серверах с Postgres'ом

`vm.swappiness = 60` (цифра == проценты) отвечает за то, будет ли ядро предпочитать кэширование файлов, вытесняя процессы в своп. Чем выше цифра, тем агрессивнее ядро будет вытеснять процессы для освобождения места под кэши.


для хорошего времени отклика меняйте на `vm.swappiness = 0`. Это не исключает своппинга в принципе (если будет нехватка памяти), но это заставит ядро максимально держать процессы в памяти.

KenshinЛог за вчера содержит 227 записей про checkpoint, каждая примерно такого вида:
Код: plaintext
1.
2.
3.
4.
2016-02-04 16:52:32 MSK [2754]: [2787-1] LOG:  checkpoint starting: time
2016-02-04 16:56:02 MSK [2754]: [2788-1] LOG:  checkpoint complete: wrote 14815
buffers (1.4%); 0 transaction log file(s) added, 0 removed, 6 recycled; write=20
9.538 s, sync=0.669 s, total=210.219 s; sync files=691, longest=0.112 s, average
=0.000 s

Ничего криминального вроде нету.

KenshinЕсть сообщения вида:
Код: plaintext
1.
2.
3.
4.
5.
2016-02-04 12:52:04 MSK [21428]: [2-1] LOG:  process 21428 still waiting for ShareLock on transaction 144836288 after 1000.100 ms
2016-02-04 12:55:15 MSK [15021]: [1-1] LOG:  process 15021 still waiting for ShareLock on transaction 144831399 after 1000.205 ms
2016-02-04 12:58:17 MSK [21428]: [4-1] LOG:  process 21428 acquired ShareLock on transaction 144836288 after 373905.482 ms
2016-02-04 12:58:33 MSK [26205]: [1-1] LOG:  process 26205 still waiting for ShareLock on transaction 144848775 after 1003.623 ms
2016-02-04 12:58:51 MSK [26205]: [3-1] LOG:  process 26205 acquired ShareLock on transaction 144848775 after 18709.440 ms
2016-02-04 12:59:04 MSK [15021]: [3-1] LOG:  process 15021 acquired ShareLock on transaction 144831399 after 230416.852 ms

Проверьте наличие `idle in transaction` сессий — они зло!
Ситуаций, когда транзакции ждут какую-то сессию 4 минуты, быть не должно.

Также рекомендую пониторить систему (IO, VM, CPU) системными средствами и смотреть, что происходит в моменты подвисаний.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
05.02.2016, 11:16
    #39163673
Kenshin
Kenshin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Периодические зависания: найти причину
Vyegorov, cпасибо, все попробую.
Сессий в статусе "idle in transaction" постоянно висит от 10 штук. Это вопрос к разработчику?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
05.02.2016, 11:25
    #39163684
vyegorov
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Периодические зависания: найти причину
KenshinСессий в статусе "idle in transaction" постоянно висит от 10 штук. Это вопрос к разработчику?
Да, но они не любят таких вопросов.

Быстрее будет запилить скрипт, который idle-in-transaction сессии с началом транзакции минут 5 назад будет обрывать.
Правда, можно аппликуху положить...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Периодические зависания: найти причину / 6 сообщений из 6, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 544ms
Закрыть
start [/forum/topic.php?fid=53&mobile=1&tid=1997468]:
 0ms
get settings:
 8ms
get forum list:
 18ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 198ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 30ms
get tp. blocked users:
 1ms
others: 274ms
total:  544ms
x
x
Закрыть


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