powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Высокий IO wait
25 сообщений из 90, страница 1 из 4
Высокий IO wait
    #38428233
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Уважаемые, эксперты!


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

В нормальном состоянии система работает идеально:

Код: html
1.
2.
3.
load average: 0.36, 0.31, 0.28
Tasks: 274 total
0.2%wa




Затем в какой-то момент (несколько раз в месяц) база начинает не успевать обрабатывать запросы и вследствие чего резко возрастает количество "idle" соединений ( с ~70 до ~300) и всё начинает жутко тормозить:

Код: html
1.
2.
3.
load average: 96.09, 39.48, 15.15
Tasks: 441 total
~60%wa



Такая ситуация держится примерно 5-10 минут и также резко нормализуется. Программисты исключают вину клиента и грешат на мотор базы данных.

Что может происходить в моменты перегрузки в базе данных и как это отследить ? Может как-нибудь конфиг оптимизировать ?
Код: html
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
max_connections = 250
shared_buffers = 16GB
temp_buffers = 16MB
max_prepared_transactions = 0
work_mem = 448MB
maintenance_work_mem = 4GB
max_stack_depth = 6MB
wal_buffers = 18MB
checkpoint_segments = 30
checkpoint_timeout = 5min
checkpoint_warning = 30s
random_page_cost = 4.0
cpu_tuple_cost = 0.01
cpu_index_tuple_cost = 0.005
effective_cache_size = 50GB
default_statistics_target = 100
autovacuum = on



Другие значения дефолтные.

Код: xml
1.
2.
3.
4.
5.
RAM 74 GB
2x Xeon E5606
PostgreSQL 9.1.9, Debian 6
Database size on disc: 84GB data + 23GB indexes. 
RAID 10 15K SCSI.
...
Рейтинг: 0 / 0
Высокий IO wait
    #38428287
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oustkast,

Сколько сегментов у вас пишется в моменты пиков? checkpoint_timeout маленький для 30 сегментов по 18Мб.

By the way - вам effective_cache_size = 50GB вместо 32Gb и maintenance_work_mem постоянно выставленная в 4GB?
...
Рейтинг: 0 / 0
Высокий IO wait
    #38428290
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
By the way - вам effective_cache_size = 50GB вместо 32Gb и maintenance_work_mem постоянно выставленная в 4GB?
зачем вам я имел ввиду
...
Рейтинг: 0 / 0
Высокий IO wait
    #38428322
Фотография Ёш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oustkast,

а swap включен в ОС?
...
Рейтинг: 0 / 0
Высокий IO wait
    #38428328
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ёш,

судя по 300 соеденениям включен;)
...
Рейтинг: 0 / 0
Высокий IO wait
    #38428358
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Свап включён и проблем с ним не замечалось, максимально уходит в 300МБ в не зависимости от перегрузки.

Код: html
1.
2.
3.
4.
             total       used       free     shared    buffers     cached
Mem:         72632      71751        881          0        199      67753
-/+ buffers/cache:       3799      68833
Swap:         7627        175       7452
...
Рейтинг: 0 / 0
Высокий IO wait
    #38428385
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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.
# - Checkpoints -

checkpoint_segments = 30		# in logfile segments, min 1, 16MB each
checkpoint_timeout = 5min		# range 30s-1h
#checkpoint_completion_target = 0.5	# checkpoint target duration, 0.0 - 1.0
checkpoint_warning = 30s		# 0 disables

max_wal_senders = 3
(master-slave репликация)



maintenance_work_mem = 4GB - да, постоянно
...
Рейтинг: 0 / 0
Высокий IO wait
    #38428558
Фотография Warstone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так елки... 30 * 16 = 480Мб. Вот оно переодически и всасывает, когда их из WAL'а в базу вставляет.
...
Рейтинг: 0 / 0
Высокий IO wait
    #38428567
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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?
...
Рейтинг: 0 / 0
Высокий IO wait
    #38428571
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oustkast,

И да - что за рейд и как настроен?
...
Рейтинг: 0 / 0
Высокий IO wait
    #38429673
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hydrobiont,

1. А какие настройки поменять, чтоб не уходило ? Хотя с другой стороны ~200 МБ свапа - ничего криминального.

2. Прокопал все логи последних пиков и нигде чекпойнты друг на друга не накладываются, каждый чекпойнт длится ~150 сек (при нормальной нагрузке также), но один раз во время пика скаканул до 277 сек. Правильно я понимаю, что каждые 5 минут мотор пишет в базу все 30 сегментов, когда необходимо вписать только 10, и некоторые сегменты просто переписываются заново ?

Нашел в логах и такое:

Код: html
1.
WARNING:  pgstat wait timeout



что связано с чекпойнтами. Не пойму одного, если уменьшить частоту чекпойнтов, то диск будет же всё равно грузится, но только реже, как это может помочь данной ситуации ?


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.
#bgwriter_delay = 200ms			# 10-10000ms between rounds
#bgwriter_lru_maxpages = 100		# 0-1000 max buffers written/round
#bgwriter_lru_multiplier = 2.0		# 0-10.0 multipler on buffers scanned/round

autovacuum = on			# Enable autovacuum subprocess?  'on'
					# requires track_counts to also be on.
#log_autovacuum_min_duration = -1	# -1 disables, 0 logs all actions and
					# their durations, > 0 logs only
					# actions running at least this number
					# of milliseconds.
#autovacuum_max_workers = 3		# max number of autovacuum subprocesses
					# (change requires restart)
#autovacuum_naptime = 1min		# time between autovacuum runs
#autovacuum_vacuum_threshold = 50	# min number of row updates before
					# vacuum
#autovacuum_analyze_threshold = 50	# min number of row updates before
					# analyze
#autovacuum_vacuum_scale_factor = 0.2	# fraction of table size before vacuum
#autovacuum_analyze_scale_factor = 0.1	# fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000	# maximum XID age before forced vacuum
					# (change requires restart)
#autovacuum_vacuum_cost_delay = 20ms	# default vacuum cost delay for
					# autovacuum, in milliseconds;
					# -1 means use vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1	# default vacuum cost limit for
					# autovacuum, -1 means use
					# vacuum_cost_limit

WAL:

#fsync = on				# turns forced synchronization on or off
#synchronous_commit = on		# synchronization level; on, off, or local
#wal_sync_method = fsync



RAID10 (4x 300GB 15K SCSI) дефолтные настройки
...
Рейтинг: 0 / 0
Высокий IO wait
    #38429715
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Чекпойнты во время пика:

Код: html
1.
2.
3.
4.
5.
6.
2013-10-16 13:15:44 EEST LOG:  checkpoint starting: time
2013-10-16 13:18:19 EEST LOG:  checkpoint complete: wrote 18099 buffers (0.9%); 0 transaction log file(s) added, 0 removed, 8 recycled; write=149.997 s, sync=5.375 s, total=155.380 s; sync files=224, longest=5.367 s, average=0.023 s
2013-10-16 13:20:50 EEST LOG:  checkpoint starting: time
2013-10-16 13:24:40 EEST LOG:  checkpoint complete: wrote 15063 buffers (0.7%); 0 transaction log file(s) added, 0 removed, 8 recycled; write=92.975 s, sync=94.468 s, total=230.621 s; sync files=195, longest=94.437 s, average=0.484 s
2013-10-16 13:25:50 EEST LOG:  checkpoint starting: time
2013-10-16 13:28:17 EEST LOG:  checkpoint complete: wrote 15419 buffers (0.7%); 0 transaction log file(s) added, 0 removed, 5 recycled; write=134.170 s, sync=7.695 s, total=146.970 s; sync files=212, longest=7.689 s, average=0.036 s
...
Рейтинг: 0 / 0
Высокий IO wait
    #38429873
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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;?
...
Рейтинг: 0 / 0
Высокий IO wait
    #38430095
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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.
checkpoints_timed 	checkpoints_req 	buffers_checkpoint 	buffers_clean 	maxwritten_clean 	buffers_backend 	buffers_backend_fsync 	buffers_alloc 	stats_reset
51634	339	279759953	1805015	12345	16440091	0	874315771	2013-04-19 17:03:13
...
Рейтинг: 0 / 0
Высокий IO wait
    #38430156
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
checkpoints_timed 	checkpoints_req 	buffers_checkpoint 	buffers_clean 	maxwritten_clean 	buffers_backend 	buffers_backend_fsync 	buffers_alloc 	stats_reset
51634	339	279759953	1805015	12345	16440091	0	874315771	2013-04-19 17:03:13



Гм, а можете вывести 3-4 вызова с промежутком примерно в минуту? Типа psql#\x и потом select now(), * from pg_stat_bgwriter;?
...
Рейтинг: 0 / 0
Высокий IO wait
    #38430181
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hydrobiont,

авторА как меряли соотношение чтений и записи?

Munin:



Код: html
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
checkpoints_timed 	checkpoints_req 	buffers_checkpoint 	buffers_clean 	maxwritten_clean 	buffers_backend 	buffers_backend_fsync 	buffers_alloc 	stats_reset
51641	339	279839908	1805052	12345	16440709	0	874547028	2013-04-19 17:03:13

51641	339	279845447	1805052	12345	16440745	0	874554083	2013-04-19 17:03:13

51641	339	279845447	1805056	12345	16440767	0	874567290	2013-04-19 17:03:13

51642	339	279850635	1805057	12345	16440789	0	874576032	2013-04-19 17:03:13

51642	339	279856316	1805058	12345	16440848	0	874585274	2013-04-19 17:03:13
...
Рейтинг: 0 / 0
Высокий IO wait
    #38430215
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oustkast,

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


Устойчивое 51641 к 339 или вроде подтверждает то что я говорил - чекпойнт у вас срабатывает по таймауту.
...
Рейтинг: 0 / 0
Высокий IO wait
    #38430225
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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

Может это они и есть или всё таки кривой конфиг ?
...
Рейтинг: 0 / 0
Высокий IO wait
    #38430260
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oustkast,

врядли они. А конфиг однозначно с проблемами.
...
Рейтинг: 0 / 0
Высокий IO wait
    #38433385
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Проштудировал ещё раз настройку сервера (при 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.
-work_mem = 448MB
+work_mem = 288MB

maintenance_work_mem = 4GB // решил не менять, т.к. есть очень большие таблицы от 9 до 28 GB 

checkpoint_segments = 30
-checkpoint_timeout = 5min
+checkpoint_timeout = 30min

-cpu_tuple_cost = 0.01
+cpu_tuple_cost = 0.001

(0.001 для быстрых cpu, 0.01 для медленных;)
 
-cpu_index_tuple_cost = 0.005
+cpu_index_tuple_cost = 0.0005

(0.0005 для быстрых cpu, 0.005 для медленных;)

-effective_cache_size = 50GB
+effective_cache_size = 48GB // решил сильно не менять, находится в пределах рекомен. нормы
(effective_cache_size = 0.9 от значения cached, которое показывает free; 0.9*66GB = 59.4GB !?)



Источник рекомендаций: Работа с PostgreSQL - настройка и масштабирование

1. Не уверен по настройке cpu_tuple_cost, cpu_index_tuple_cost , стоит их менять или нет, является ли XEON E5606 достаточно быстрым )) ?

2. Исходя из всего вышепречисленного смелю предположить, что проблема перегрузки заключается в слишком частых чекпойнтах, только непонятно одно, почему это происходит рэндомно? Получается спонтанный конфликт между выделенной памятью Postgres и памятью ОС ? Ведь встаёт колом не при каждом чекпойнте же.

Буду рад дельным отзывам и комментариям!
...
Рейтинг: 0 / 0
Высокий IO wait
    #38433392
Фотография Ёш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oustkastКэш на рейде = 256MBЭто на запись?
...
Рейтинг: 0 / 0
Высокий IO wait
    #38433404
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ёш,

Yep, HP Smart Array P410i/256 MB BBWC Controller
...
Рейтинг: 0 / 0
Высокий IO wait
    #38433407
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oustkast,

какая файловая система? как смонтирована?

--
какой планировщик ввода/вывода?
...
Рейтинг: 0 / 0
Высокий IO wait
    #38433410
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
и версия ядра какая?
...
Рейтинг: 0 / 0
Высокий IO wait
    #38433552
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Misha Tyurin,

Код: html
1.
2.
3.
4.
5.
ext3    noatime        0       2

io scheduler cfq registered (default)

2.6.32-5-amd64
...
Рейтинг: 0 / 0
25 сообщений из 90, страница 1 из 4
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Высокий IO wait
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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