|
|
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Уважаемые, эксперты! Пожалуйста помогите разобраться в чем может быть причина спонтанных скачков нагрузки на жесткий диск. В нормальном состоянии система работает идеально: Код: html 1. 2. 3. Затем в какой-то момент (несколько раз в месяц) база начинает не успевать обрабатывать запросы и вследствие чего резко возрастает количество "idle" соединений ( с ~70 до ~300) и всё начинает жутко тормозить: Код: html 1. 2. 3. Такая ситуация держится примерно 5-10 минут и также резко нормализуется. Программисты исключают вину клиента и грешат на мотор базы данных. Что может происходить в моменты перегрузки в базе данных и как это отследить ? Может как-нибудь конфиг оптимизировать ? Код: html 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Другие значения дефолтные. Код: xml 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2013, 14:23:11 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkast, Сколько сегментов у вас пишется в моменты пиков? checkpoint_timeout маленький для 30 сегментов по 18Мб. By the way - вам effective_cache_size = 50GB вместо 32Gb и maintenance_work_mem постоянно выставленная в 4GB? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2013, 14:42:46 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
By the way - вам effective_cache_size = 50GB вместо 32Gb и maintenance_work_mem постоянно выставленная в 4GB? зачем вам я имел ввиду ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2013, 14:44:57 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkast, а swap включен в ОС? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2013, 15:06:01 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Ёш, судя по 300 соеденениям включен;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2013, 15:11:19 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Свап включён и проблем с ним не замечалось, максимально уходит в 300МБ в не зависимости от перегрузки. Код: html 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2013, 15:26:47 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
hydrobiontoustkast, Сколько сегментов у вас пишется в моменты пиков? checkpoint_timeout маленький для 30 сегментов по 18Мб. By the way - вам effective_cache_size = 50GB вместо 32Gb и maintenance_work_mem постоянно выставленная в 4GB? Пишется как и обычно, по 1-2 сегмента в минуту. Все значения выставлял по рекомендациям, где их брал уже не помню, но расчитывались они исходя от кол-ва RAM-памяти. maintenance_work_mem = 4GB - да, постоянно А какие бы значения выставили вы ? Код: html 1. 2. 3. 4. 5. 6. 7. 8. 9. maintenance_work_mem = 4GB - да, постоянно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2013, 15:41:32 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Так елки... 30 * 16 = 480Мб. Вот оно переодически и всасывает, когда их из WAL'а в базу вставляет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2013, 17:19:46 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkast, 1. То что в свап уходит плохо. 2. Рискну предположить, что в пиках у вас происходит затык по IO тк чекпойнты наезжают по друг на друга (у вас не получается воспользоваться выигрышем от checkpoint_segments = 30 тк таймаут 5 минут, за это время пишется максимум 10 сегментов и чекпоинт происходит чаще чем надо). В результате растет кол-во воркеров (до 300) что при work_mem = 448MB съедает всю память и база чувствует себя погано. 3. effective_cache_size лучше shared_buffers * 2б в большинстве случаев это разумная настройка. 4. maintenance_work_mem лучше держать небольшим и выставлять сессионно в большое значение только там где надо, напирме для перестройки индекса, иначе у вас например каждый автовакуум съедает эти 4Гб попробуйте для начала сильно увеличить checkpoint_timeout - до получаса или даже часа. Потом можно еще поиграть с checkpoint_completion_target в промежутке 0.5-0.7, чтобы поравномерней диск грузился. А как настроен актовакуум и bgwriter? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2013, 17:28:02 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkast, И да - что за рейд и как настроен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2013, 17:29:16 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
hydrobiont, 1. А какие настройки поменять, чтоб не уходило ? Хотя с другой стороны ~200 МБ свапа - ничего криминального. 2. Прокопал все логи последних пиков и нигде чекпойнты друг на друга не накладываются, каждый чекпойнт длится ~150 сек (при нормальной нагрузке также), но один раз во время пика скаканул до 277 сек. Правильно я понимаю, что каждые 5 минут мотор пишет в базу все 30 сегментов, когда необходимо вписать только 10, и некоторые сегменты просто переписываются заново ? Нашел в логах и такое: Код: html 1. что связано с чекпойнтами. Не пойму одного, если уменьшить частоту чекпойнтов, то диск будет же всё равно грузится, но только реже, как это может помочь данной ситуации ? 3. "effective_cache_size лучше shared_buffers * 2б" - не понял какие значения им выставить, пожалуйста поясните. 4. maintenance_work_mem - и до скольки гигов советуете его снизить ? актовакуум и bgwriter: Код: html 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. RAID10 (4x 300GB 15K SCSI) дефолтные настройки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2013, 14:10:16 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Чекпойнты во время пика: Код: html 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2013, 14:32:59 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkast, 1. Меньше воркеров, меньше воркмем. Любой уход в свап машины с бд это плохо. Часто даже vm.swappiness = 0 имеет смысл 2. Чекпойнт наступает либо когда накопилось указанное кол-во сегментов, либо когда сработал таймаут. И пишется тогда столько сегментов, сколько накопилось на момент таймаута. Если вы хотите выиграть от более редких чекпойнтов (что оправданно когда писанины много), настройка checkpoint_segments = 30 оправдана (если ее тянет ваш рейд). Если мы 270 разделим на 60, то получим, что база занималась чекпойнтом почти все время между двумя таймаутами. Какой кэш на рейде? Во что выставлены vm.dirty_ratio и dirty_background_ratio (если у вас линукс)? 3. опечатка, сорри. effective_cache_size в два раза больше чем shared_buffers, тк есть еще кэш ОС. 4. Поставьте 512, где надо больше, подымайте на сессию. 5. на таком объеме записи уже лучше вакуум иметь более агрессивный autovacuum_vacuum_scale_factor = 0.01 6. bgwriter тоже лучше настроить агрессивней. что сейчас в select * from pg_stat_bgwriter;? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2013, 15:49:18 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
hydrobiont, 2. Спасибо за пояснение! Кэш на рейде = 256MB . Во время пиков чтение с диска в 3 раза больше чем писанины. То есть нагрузка идёт именно на чтение с диска. vm.dirty_ratio = 20 vm.dirty_background_ratio = 10 (Debian 6 defaults) 4. "Поставьте 512, где надо больше, подымайте на сессию." - не совсем понял как это делается.. поднимать со стороны клиента ? 6. select * from pg_stat_bgwriter;? Код: html 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2013, 17:27:17 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkasthydrobiont, 2. Спасибо за пояснение! Кэш на рейде = 256MB . Во время пиков чтение с диска в 3 раза больше чем писанины. То есть нагрузка идёт именно на чтение с диска. vm.dirty_ratio = 20 vm.dirty_background_ratio = 10 А как меряли соотношение чтений и записи? Дефолты не подходят совсем если памяти много. Поставьте например vm.dirty_ratio = 33554432 vm.dirty_background_ratio = 268435456 oustkast4. "Поставьте 512, где надо больше, подымайте на сессию." - не совсем понял как это делается.. поднимать со стороны клиента ? Да, глобально у вас стоит например 512МБ, если надо конкретной сессии дать больше (например перестроить индекс) - делаете в ней set oustkast6. select * from pg_stat_bgwriter;? Код: html 1. 2. Гм, а можете вывести 3-4 вызова с промежутком примерно в минуту? Типа psql#\x и потом select now(), * from pg_stat_bgwriter;? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2013, 17:52:46 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
hydrobiont, авторА как меряли соотношение чтений и записи? Munin: Код: html 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2013, 18:09:09 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkast, Хорошая картинка с мунина. Эти пики чтения - перезаполнение баферкэша. Система встала колом на чекпойнте, провела некоторое время в ожидании, потом вокреры начали в шаренную память подымать то что им нужно, получился еще один пик, на чтение. Устойчивое 51641 к 339 или вроде подтверждает то что я говорил - чекпойнт у вас срабатывает по таймауту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2013, 18:33:14 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
hydrobiont, Ну понятно, значит поправлю параметры конфигурации и сдам их позже на проверку =) Кстати, в версии 9.1.9, короторую сейчас и юзаем, замечены несколько багов с утечкой памяти: авторFix checkpoint memory leak in background writer when wal_level = hot_standby (Naoya Anzai) Fix memory leak caused by lo_open() failure (Heikki Linnakangas) Fix memory overcommit bug when work_mem is using more than 24GB of memory (Stephen Frost) Link Может это они и есть или всё таки кривой конфиг ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2013, 18:42:36 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkast, врядли они. А конфиг однозначно с проблемами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2013, 19:00:43 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Проштудировал ещё раз настройку сервера (при 72GB RAM) и решил поменять следующие параметры: Код: html 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. Источник рекомендаций: Работа с PostgreSQL - настройка и масштабирование 1. Не уверен по настройке cpu_tuple_cost, cpu_index_tuple_cost , стоит их менять или нет, является ли XEON E5606 достаточно быстрым )) ? 2. Исходя из всего вышепречисленного смелю предположить, что проблема перегрузки заключается в слишком частых чекпойнтах, только непонятно одно, почему это происходит рэндомно? Получается спонтанный конфликт между выделенной памятью Postgres и памятью ОС ? Ведь встаёт колом не при каждом чекпойнте же. Буду рад дельным отзывам и комментариям! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2013, 18:50:23 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkastКэш на рейде = 256MBЭто на запись? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2013, 18:56:13 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Ёш, Yep, HP Smart Array P410i/256 MB BBWC Controller ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2013, 19:09:48 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkast, какая файловая система? как смонтирована? -- какой планировщик ввода/вывода? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2013, 19:11:42 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
и версия ядра какая? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2013, 19:12:27 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38430095&tid=1998903]: |
0ms |
get settings: |
7ms |
get forum list: |
22ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
196ms |
get topic data: |
11ms |
get forum data: |
4ms |
get page messages: |
87ms |
get tp. blocked users: |
2ms |
| others: | 197ms |
| total: | 532ms |

| 0 / 0 |
