PostgreSQL pg_stat_activity показывает COMMIT

Недавно мы заменили наш сервер баз данных на модернизированный компьютер с четырьмя четырехъядерными процессорами и 32 ГБ оперативной памяти. Мы также переназначили нашу старую коробку в качестве ведомой с потоковой репликацией. Оба бокса работают под управлением CentOS 6.3 и PostgreSQL 9.2. Postgres - единственное, что работает на каждой из коробок.

Эта конфигурация существовала около месяца или около того, когда мы неожиданно столкнулись с некоторыми проблемами, когда трафик начал расти. То, что мы начали видеть, это чрезвычайно высокая загрузка ЦП (верхняя часть показывает среднюю загрузку 270), и когда мы pg_stat_activityувидим, мы увидим, что большинство наших соединений находятся в COMMITсостоянии. Если оставить его в покое, это в конечном итоге закончится, и система станет реагировать на возникновение соединений IDLE. Мы попытались отключить репликацию, чтобы выяснить, может ли это быть проблемой, но проблема все еще сохраняется.

Мы попытались диагностировать происходящее и немного потеряли. Результат работы perfпоказывает что-то похожее на приведенное ниже, и я понятия не имею, что 0x347ba9представляет.

+  41.40%       48154  postmaster  0x347ba9         f 0x347ba9                                   ◆
+   9.55%       10956  postmaster  0x2dc820         f set_config_option                          ▒
+   8.64%        9946  postmaster  0x5a3d4          f writeListPage     
+   5.75%        6609  postmaster  0x5a2b0          f ginHeapTupleFastCollect                    ▒
+   2.68%        3084  postmaster  0x192483         f build_implied_join_equality                ▒
+   2.61%        2990  postmaster  0x187a55         f build_paths_for_OR                         ▒
+   1.86%        2131  postmaster  0x794aa          f get_collation_oid                          ▒
+   1.56%        1822  postmaster  0x5a67e          f ginHeapTupleFastInsert                     ▒
+   1.53%        1766  postmaster  0x1929bc         f distribute_qual_to_rels                    ▒
+   1.33%        1558  postmaster  0x249671         f cmp_numerics

Ни один из запросов, выполняемых приложением, не является особенно сложным, так как планы объяснения занимают не более 1 секунды (большинство гораздо быстрее). Кроме того, хотя это происходит, когда трафик начинает набирать обороты, мы не говорим об огромной нагрузке на трафик (старая машина раньше справлялась с этим довольно легко).

На данный момент я немного озадачен тем, что попробовать дальше. Любая помощь или предложения будут оценены. Если есть какая-либо дополнительная информация, которая может помочь, просто спросите, и я могу изменить вопрос.

Конфигурация диска:

RAID-контроллер Perc 6i
5 х 146 ГБ 15K дисков SAS
Конфигурируется как 2x146GB RAID-1 для WAL и 3x146GB RAID-5 для системы и данных

Обновить:

Ниже приведен вывод VMStat, когда система функционирует нормально и когда процессор загружается. Когда есть проблема, прерывания, кажется, стремительно растут.

Во время нормальной работы:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 18938590 303763 21947154    0    0    28    52 7466 12649  2  1 97  0  0   2013-01-14 16:03:25 EST
 0  0      0 18938396 303763 21947154    0    0     0    19 7107 12679  2  0 98  0  0   2013-01-14 16:03:35 EST
 1  0      0 18938904 303763 21947162    0    0     0    54 7042 12708  1  1 99  0  0   2013-01-14 16:03:45 EST
 1  0      0 18938520 303763 21947260    0    0    33    66 7120 12738  1  1 99  0  0   2013-01-14 16:03:55 EST

Когда загрузка процессора высока:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
343 0      0 32680468 226279 11339612    0    0     0   214 26692 12225 80  20  0  0  0   2013-01-11 16:45:53 EST
374 1      0 32673764 226291 11340345    0    0     0    77 54893 11572 80  20  0  0  0   2013-01-11 16:46:03 EST
383 0      0 32616620 226304 11340956    0    0     0   102 55540 12922 82  18  0  0  0   2013-01-11 16:46:13 EST
315 0      0 32602038 226320 11341378    0    0     0    79 54539 12441 82  18  0  0  0   2013-01-11 16:46:23 EST

postgresql

— jcern
источник

Какие диски у новой коробки? Это происходит на обоих узлах или только на одном из них?

— Trygve Laugstøl

@trygvis - Я обновил вопрос со спецификациями диска. Проблема происходит на главном узле. Я не пытался рекламировать Slave и направлять на него трафик, поэтому я не уверен, что это проблема там же при тех же обстоятельствах. Как раб, машина, похоже, не испытывает никаких проблем.

— Jcern

Подумайте об использовании этого perfинструмента для профилирования всей системы и профилирования PostgreSQL. Посмотрите, где происходит использование процессора. Кстати, форматирование вашего второго vmstatбезнадежно искажено, а столбцы первого смещены, поэтому их трудно прочитать. Проверьте, не commit_delayулучшает ли добавление вещи. Проверьте, есть ли у вашего RAID-контроллера кэш обратной записи с резервным питанием от батареи, и если нет, то получите его. Много времени проведено iowait? Это кажется , что использование процессора в некоторых отчетах, но не на самом деле.

— Крейг Рингер

@CraigRinger контроллер имеет кэш-память с резервным питанием от батареи, которая в настоящее время включена. Ждать от iostat осталось от однозначного до младшего двузначного числа. Мы продолжим пробовать профилирование с помощью perf. Я также исправил форматирование второго VMStat, спасибо за указание на это.

— Jcern

После дальнейшей диагностики и некоторого поиска в Google мы наткнулись на эту статью, в которой описаны многие из тех же симптомов, которые мы испытывали. Коренная причина их проблемы (и из того, что мы можем сказать, наша тоже) была связана с Transparent Huge Pagesреализацией.

После отключения Transparent Huge Pagesэтой командой:

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

Проблема, кажется, была решена. Последние две недели мы работали в условиях повышенной нагрузки, и проблема не выявилась. Системные контексты и прерывания последовательно составляют 1/10 от того, чем они были, и среднее системное время также уменьшилось.

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

— jcern
источник