Нещодавно наш сервер баз даних замінив оновлену машину з 4-х чотирьохядерними процесорами та 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 Гб накопичувачі 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 ESTperfінструменту, щоб зробити кілька системних профілів та деякі PostgreSQL-профілювання. Подивіться, де відбувається використання процесора. До речі, форматування вашої 2-ї vmstatбезнадійно налаштовано, а стовпці 1-ї - нерівні, тому важко читати. Перевірте, чи додає commit_delayпокращення. Перевірте, чи є у вашого RAID-контролера керований кеш-пам'ять резервного копіювання, а якщо його немає, знайдіть його. Чи багато часу проводиться в iowait? Це здається , що використання процесора в деяких звітів, але не на самому ділі.