Недавно мы заменили наш сервер баз данных на модернизированный компьютер с четырьмя четырехъядерными процессорами и 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
источник
perfинструмента для профилирования всей системы и профилирования PostgreSQL. Посмотрите, где происходит использование процессора. Кстати, форматирование вашего второгоvmstatбезнадежно искажено, а столбцы первого смещены, поэтому их трудно прочитать. Проверьте, неcommit_delayулучшает ли добавление вещи. Проверьте, есть ли у вашего RAID-контроллера кэш обратной записи с резервным питанием от батареи, и если нет, то получите его. Много времени проведеноiowait? Это кажется , что использование процессора в некоторых отчетах, но не на самом деле.Ответы:
После дальнейшей диагностики и некоторого поиска в Google мы наткнулись на эту статью, в которой описаны многие из тех же симптомов, которые мы испытывали. Коренная причина их проблемы (и из того, что мы можем сказать, наша тоже) была связана с
Transparent Huge Pagesреализацией.После отключения
Transparent Huge Pagesэтой командой:Проблема, кажется, была решена. Последние две недели мы работали в условиях повышенной нагрузки, и проблема не выявилась. Системные контексты и прерывания последовательно составляют 1/10 от того, чем они были, и среднее системное время также уменьшилось.
Не уверен, что это решение для всех, но я выкладываю его здесь в качестве возможной причины, если это может помочь кому-либо еще решить аналогичную проблему.
источник