ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Высокий IO wait
90 сообщений из 90, показаны все 4 страниц
  все  
Высокий IO wait
    #38428233
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
15.10.2013, 14:23:11
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38428287
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hydrobiont
Участник
oustkast,

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

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

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

судя по 300 соеденениям включен;)
...
Рейтинг: 0 / 0
15.10.2013, 15:11:19
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38428358
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
15.10.2013, 15:26:47
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38428385
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
15.10.2013, 15:41:32
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38428558
Фотография Warstone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Warstone
Участник
Так елки... 30 * 16 = 480Мб. Вот оно переодически и всасывает, когда их из WAL'а в базу вставляет.
...
Рейтинг: 0 / 0
15.10.2013, 17:19:46
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38428567
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
15.10.2013, 17:28:02
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38428571
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hydrobiont
Участник
oustkast,

И да - что за рейд и как настроен?
...
Рейтинг: 0 / 0
15.10.2013, 17:29:16
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38429673
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
16.10.2013, 14:10:16
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38429715
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
16.10.2013, 14:32:59
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38429873
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
16.10.2013, 15:49:18
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38430095
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
16.10.2013, 17:27:17
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38430156
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
16.10.2013, 17:52:46
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38430181
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
16.10.2013, 18:09:09
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38430215
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hydrobiont
Участник
oustkast,

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


Устойчивое 51641 к 339 или вроде подтверждает то что я говорил - чекпойнт у вас срабатывает по таймауту.
...
Рейтинг: 0 / 0
16.10.2013, 18:33:14
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38430225
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
16.10.2013, 18:42:36
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38430260
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hydrobiont
Участник
oustkast,

врядли они. А конфиг однозначно с проблемами.
...
Рейтинг: 0 / 0
16.10.2013, 19:00:43
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38433385
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
18.10.2013, 18:50:23
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38433392
Фотография Ёш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ёш
Участник
oustkastКэш на рейде = 256MBЭто на запись?
...
Рейтинг: 0 / 0
18.10.2013, 18:56:13
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38433404
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Ёш,

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

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

--
какой планировщик ввода/вывода?
...
Рейтинг: 0 / 0
18.10.2013, 19:11:42
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38433410
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
и версия ядра какая?
...
Рейтинг: 0 / 0
18.10.2013, 19:12:27
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38433552
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
18.10.2013, 22:23:41
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38433704
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
oustkast,

Своп точно надо вырубать. swapoff -a

И уменьшить шаред буфера минимум в два раза.

Планировшик - noop

И наблюдать дальше )

---
Вы уверены что никакой хитрой нагрузки к вам не приходит иногда?
...
Рейтинг: 0 / 0
19.10.2013, 01:19:16
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38433735
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
Еще. Весь кеш рейд контроллера отдайте на запись.

И уменьшить упреждающее чтение хорошо через blockdev, если у вас много конкурентных индекссканов.

Вот такие общие замечания могут быть.
...
Рейтинг: 0 / 0
19.10.2013, 02:13:55
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38433739
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
Чекпоинт таймаут в 1час
И чекпоинт таргет в 1цу (checkpoint_completion_target)

И пусть всегда по времени пишется. Поставки много чекпоинт сегментс.
...
Рейтинг: 0 / 0
19.10.2013, 02:23:38
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38435462
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Misha TyurinИ уменьшить шаред буфера минимум в два раза.

Вы уверены что никакой хитрой нагрузки к вам не приходит иногда?

А могли бы пожалуйтса пояснить зачем уменьшать shared_buffers ? Рам-памяти же достаточно на машине, 72 ГБ.

Никакой хитрой нагрузки не приходит, ей некуда приходить и страдает только база данных, графики веб сервера без изменений. Бывало и так, что во время пиков активности клиентов база и вовсе не страдала, а при средней нагрузке выкидывала неприятные сюрпризы..
...
Рейтинг: 0 / 0
21.10.2013, 13:40:49
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38436057
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hydrobiont
Участник
oustkast,

я бы не уменьшал шаред бафферс, при налиыие настроенного рейда (дисков правда малова-то, но это уже подробнее надо смотреть более подробно). Вам нужно сделать более редкими чекпойнты (поднять таймаут) и скорее всего уменьшать ворк_мемори м/или кол-во процессов. От 300 процессов пользы ноль, вреда много - с таким воркмемом вы уходите в свап как только система затыкается на чекпойнте. За баунсером вообще крайне редко нужно больше пары десятков процессов.
...
Рейтинг: 0 / 0
21.10.2013, 18:59:08
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38437984
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Начал пока что со следующих изменений:

Код: html
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
-work_mem = 448MB
+work_mem = 288MB

-checkpoint_timeout = 5min
+checkpoint_timeout = 30min

-checkpoint_completion_target = 0.5
+checkpoint_completion_target = 0.7

-effective_cache_size = 50GB
+effective_cache_size = 48GB



Со следующей недели ожидается большой поток посетителей и отпишусь о результатах.
...
Рейтинг: 0 / 0
23.10.2013, 10:59:02
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38438314
_Monah_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_Monah_
Участник
hydrobiontА как меряли соотношение чтений и записи?

Дефолты не подходят совсем если памяти много. Поставьте например

vm.dirty_ratio = 33554432
vm.dirty_background_ratio = 268435456

это не в байтах случаем числа?
...
Рейтинг: 0 / 0
23.10.2013, 14:00:34
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38438411
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
_Monah_hydrobiontА как меряли соотношение чтений и записи?

Дефолты не подходят совсем если памяти много. Поставьте например

vm.dirty_ratio = 33554432
vm.dirty_background_ratio = 268435456

это не в байтах случаем числа?

в байтах да
...
Рейтинг: 0 / 0
23.10.2013, 14:51:50
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38442965
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
oustkast,

А зачем вам 16gb ? Всегда рекомендуют начинать с 4 gb. Большие буфера - вероятны оверхеды. Их можно исключить. А значет нужно уменьшаит . практически уверен что вам и 4/8 gb хватит более чем.

Но так как сервер не выделен - то все может оч сильно зависеть не от постгреса
...
Рейтинг: 0 / 0
28.10.2013, 07:00:17
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38443880
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Misha Tyurinoustkast,

А зачем вам 16gb ? Всегда рекомендуют начинать с 4 gb. Большие буфера - вероятны оверхеды. Их можно исключить. А значет нужно уменьшаит . практически уверен что вам и 4/8 gb хватит более чем.

Но так как сервер не выделен - то все может оч сильно зависеть не от постгреса

Изначально выставил в 16GB из примера мануала по настройке Postgres-a : 1/4 of RAM. Если будет мешать - снижу до 8GB , а вообще план добавить в ближайшем будущем ещё 48 GB RAM-a.

С чего берёте, что сервер не выделен ? =) В первом посте приведена полная спецификация сервера и уточню, что кроме Postgres-a на сервере ничего больше не бегает.
...
Рейтинг: 0 / 0
28.10.2013, 17:06:08
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38446054
Knt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Knt
Участник
Возможно вопрос не в тему но сколько попугаев на такой системе дает нагрузочный тест Гилева ?
(у меня аналогичная система с меньшим обьемом памяти 16ГБ и по тесту выше 9 попугаев прыгнуть просто не выходит)
...
Рейтинг: 0 / 0
30.10.2013, 06:37:14
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38446698
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
KntВозможно вопрос не в тему но сколько попугаев на такой системе дает нагрузочный тест Гилева ?
(у меня аналогичная система с меньшим обьемом памяти 16ГБ и по тесту выше 9 попугаев прыгнуть просто не выходит)

Не нашел документации как его под Линуксом запускать через эс-эс-ха..
...
Рейтинг: 0 / 0
30.10.2013, 14:31:14
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38447364
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
hydrobiont
Дефолты не подходят совсем если памяти много. Поставьте например

vm.dirty_ratio = 33554432
vm.dirty_background_ratio = 268435456



hydrobiont,

пардон, если туплю, но прогуглив эти параметры, числа должны быть указаны в процентах (0-100), а не байтах:

Код: html
1.
2.
3.
vm.dirty_background_ratio is the maximum percentage of ((Cache + Free) - Mapped) memory that can be dirty before it is written to disk by the pdflush process.

vm.dirty_ratio is the value that represents the percentage of MemTotal that can consume dirty pages before all processes must write dirty buffers back to disk and when this value is reached all I/O is blocked for any new writes until dirty pages have been flushed.



Может уточните, откуда такие длинные числа ? )
...
Рейтинг: 0 / 0
30.10.2013, 19:23:55
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38447380
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Код: html
1.
2.
vm.dirty_background_bytes
vm.dirty_bytes



или же это имелось в виду..
...
Рейтинг: 0 / 0
30.10.2013, 19:40:24
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38447778
_Monah_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_Monah_
Участник
oustkast,
я думаю, что это.
Только разницы лично я на наших серверах не заметил от изменения этих параметров
...
Рейтинг: 0 / 0
31.10.2013, 09:50:39
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38453577
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Ситуация начала повторяться, но уже слабее, слоты пока ещё не переполнялись.

Кол-во воркеров скакало от нормальных ~90 до 220 в пик нагрузки вне зависимости от чекпойнта. С чем это связано непонятно.. Походу память временами забивается.


(самая длинная полоска - это запуск команды ANALYZE ALL каждый день в 5 утра)



Код: html
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
2013-11-05 14:14:37 EET LOG:  checkpoint starting: time
2013-11-05 14:35:12 EET LOG:  checkpoint complete: wrote 50223 buffers (2.4%); 0 transaction log file(s) added, 0 removed, 22 recycled; write=1235.699 s, sync=0.006 s, total=1235.722 s; sync files=313, longest=0.001 s, average=0.000 s
2013-11-05 14:44:37 EET LOG:  checkpoint starting: time
2013-11-05 15:04:06 EET LOG:  checkpoint complete: wrote 44806 buffers (2.1%); 0 transaction log file(s) added, 0 removed, 23 recycled; write=1168.942 s, sync=0.015 s, total=1168.965 s; sync files=312, longest=0.008 s, average=0.000 s
2013-11-05 15:14:37 EET LOG:  checkpoint starting: time
2013-11-05 15:35:37 EET LOG:  checkpoint complete: wrote 50148 buffers (2.4%); 0 transaction log file(s) added, 0 removed, 21 recycled; write=1259.916 s, sync=0.010 s, total=1259.933 s; sync files=329, longest=0.006 s, average=0.000 s
2013-11-05 15:44:37 EET LOG:  checkpoint starting: time
2013-11-05 16:05:25 EET LOG:  checkpoint complete: wrote 48816 buffers (2.3%); 0 transaction log file(s) added, 0 removed, 24 recycled; write=1247.935 s, sync=0.012 s, total=1247.955 s; sync files=338, longest=0.005 s, average=0.000 s
2013-11-05 16:14:37 EET LOG:  checkpoint starting: time
2013-11-05 16:35:29 EET LOG:  checkpoint complete: wrote 41609 buffers (2.0%); 0 transaction log file(s) added, 0 removed, 19 recycled; write=1252.397 s, sync=0.009 s, total=1252.836 s; sync files=350, longest=0.004 s, average=0.000 s



Что думаете, может попробовать теперь снизить shared_buffers с 16GB до 8GB и ещё work_mem с 288MB до 250MB ?
...
Рейтинг: 0 / 0
05.11.2013, 18:43:13
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38453586
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hydrobiont
Участник
oustkast
Код: html
1.
2.
vm.dirty_background_bytes
vm.dirty_bytes



или же это имелось в виду..

Да, конечно это, сорри.

[quot oustkast]
Код: html
1.
ANALYZE ALL



Зачем это?

И зачем вам такой большой воркмем? каждая сессия реально в таковом нуждается?

И да - у вас база за баунсером или напрямую?
...
Рейтинг: 0 / 0
05.11.2013, 18:51:02
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38455085
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
hydrobiont,

ANALYZE для оптимизации планировщика запросов. Рекомендацию нашел из вики: Using ANALYZE to optimize PostgreSQL queries] http://wiki.postgresql.org/wiki/Introduction_to_VACUUM,_ANALYZE,_EXPLAIN,_and_COUNT

Используем джававский баунсер - c3p0 .

как насчёт таких уменьшений, разумно ?

Код: html
1.
2.
3.
maintenance_work_mem = 4GB --> 2GB
shared_buffers = 16GB --> 8GB
work_mem = 288MB --> 128MB



Правильно ли я понимаю, что каждый процесс Postgres использует количество памяти = work_mem или же это максимальное значение, что сможет при надобности использовать процесс ?

Т.е. 90 процессов будут использовать кол-во памяти равное 90*128MB=11.25GB или не обязательно ?
...
Рейтинг: 0 / 0
06.11.2013, 19:09:56
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38455088
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
hydrobiont,

ANALYZE для оптимизации планировщика запросов. Рекомендацию нашел из вики: Using ANALYZE

Используем джававский баунсер - c3p0 .

как насчёт таких уменьшений, разумно ?

Код: html
1.
2.
3.
maintenance_work_mem = 4GB --> 2GB
shared_buffers = 16GB --> 8GB
work_mem = 288MB --> 128MB



Правильно ли я понимаю, что каждый процесс Postgres использует количество памяти = work_mem или же это максимальное значение, что сможет при надобности использовать процесс ?

Т.е. 90 процессов будут использовать кол-во памяти равное 90*128MB=11.25GB или не обязательно ?
...
Рейтинг: 0 / 0
06.11.2013, 19:11:17
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38455491
nedba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nedba
Участник
oustkast,

oustkastmaintenance_work_mem = 4GB --> 2GB
shared_buffers = 16GB --> 8GB
work_mem = 288MB --> 128MB


Правильно ли я понимаю, что каждый процесс Postgres использует количество памяти = work_mem или же это максимальное значение, что сможет при надобности использовать процесс ?

Т.е. 90 процессов будут использовать кол-во памяти равное 90*128MB=11.25GB или не обязательно ?


maintenance_work_mem берется из расчета 75% размера от самой большой таблицы. Отъедает по maintenance_work_mem раз сколько у вас воркеров будет запущено. Оптимально для почти всех видов баз в которых никто ничего не понимает 512 мб при средней нагрузке.

структуры shared_buffers формируются при старте БД и содержат разделяемые структуры (буферы, спинлоки, двухфазные метки транзакций и др). Чем структура больше, тем каждый бэкэнд неповоротливее. Но не может быть слишком маленьким иначе начнутся тормоза. условно перемножте количество структур в БД на 2 мб (это метрика _снизу_) .

work_mem формируется при подключении бакенда. Оптимально установить 1Мб и смотреть в логи на запросы которые выполняются больше 100мс. к этим запросам выполнить экплейн аналайз и посмотреть нет ли сортировки на диске, если есть - то увеличивать work_mem на указанную величину. (повторить по необходимости).

effective_cache_size носит рекомендательный характер для построения плана (агрессивно или деликатно использовать ресурсы). effective_cache_size обычно 75% всей оперативки.

сиблинг поставьте больше, к примеру 16 или 24.
проверьте ваши фризы - возможно у вас уже 97% от 200 000 000 000, по тому постгрес и стартует воркеры так часто.
...
Рейтинг: 0 / 0
07.11.2013, 08:09:34
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38455996
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
nedbamaintenance_work_mem берется из расчета 75% размера от самой большой таблицы. Отъедает по maintenance_work_mem раз сколько у вас воркеров будет запущено. Оптимально для почти всех видов баз в которых никто ничего не понимает 512 мб при средней нагрузке.

сиблинг поставьте больше, к примеру 16 или 24.
проверьте ваши фризы - возможно у вас уже 97% от 200 000 000 000, по тому постгрес и стартует воркеры так часто.

Самая большая таблица в базе 30 GB.

попробую увеличить и это тогда:
Код: html
1.
commit_siblings = 5 --> 16


Сорри, но как проверить фризы ?
...
Рейтинг: 0 / 0
07.11.2013, 13:19:33
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38456866
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Запустил на тестовом сервере (где выставил work_mem=1 MB) тяжелый запрос и как видно он использует максимально памяти в 3 MB , получается нам за глаза хватит и размера work_mem=25 MB , к примеру ? Или ещё надо что-то учитывать ?

Код: html
1.
Sort Method: external merge  Disk: 3120kB
...
Рейтинг: 0 / 0
07.11.2013, 19:14:50
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38456986
eye-cutter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eye-cutter
Участник
oustkastЗапустил на тестовом сервере (где выставил work_mem=1 MB) тяжелый запрос и как видно он использует максимально памяти в 3 MB , получается нам за глаза хватит и размера work_mem=25 MB , к примеру ? Или ещё надо что-то учитывать ?

Код: html
1.
Sort Method: external merge  Disk: 3120kB



"Sort Method: external merge Disk: 3120kB" говорит о том, что work_mem не хватает для этого запроса, приблизительно 10 МБ, тк при записи на диск хорошо жмется.
...
Рейтинг: 0 / 0
07.11.2013, 21:03:44
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38458310
nedba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nedba
Участник
oustkast,

0) 30Гб - если на таблице нет триггеров и референсов, возможно ее стоит партиционировать - снять нагрузку с вакуума и менеджера запросов.
1) Ну, дам вам удочку про фризы http://www.databasesoup.com/2012/09/freezing-your-tuples-off-part-1.html
2) maintenance_work_mem вам нужен только для _измененной_ части таблицы. Условно: из 30Гб меняется не так много блоков. Каждый блок структур по 4Кб (для таблиц), в блоке содержится заголовок, указатель на первый свободный блок для туплов, пустое пространство, сами туплы и их версионированые строки, контрольная сумма блока (у индексов почти так же, только организовано в виде дерева и туплы содержат указатели на данные и линки на следующий и предыдущий элементы). Вакуум (не фулл) бежит по блокам с первого к последнему и те блоки в которых находит версионированые данные пытается сопоставить с текущими (виртуальными) транзакциями. Все завершенные транзакции и их версии признаются устаревшими и помечаются внутри блока как свободные. все блоки в _конце_ таблицы помеченые полностью как пустые возвращаются в общий пул и уменьшают место на диске. Не так много существует систем в которых транзакции одновременно затрагивают очень много строк и висят долгое время в пустую расширяя таблицу. В большинстве случаев таких блоков с версиями у которых транзакций уже нет не так много.

Чем больше maintenance_work_mem тем больше нужно выкинуть из кэша данных, чтобы просто запустить воркер (ненужная нагрузка).

3) bloated table - возможно, что у вас данные давно не оптимальны на диске. Оптимизатор собрав статистику может на это делать поправку (чтобы не хранить почти пустые блоки с мусором в кэше, а всегда их считывать с диска).
Посмотреть можно, для таблиц и индексов: SELECT relname AS table_name, pg_size_pretty(pg_relation_size(oid)) AS table_size, pg_size_pretty(pg_total_relation_size(oid)) AS total_size FROM pg_class WHERE relkind in ('r','i') ORDER BY pg_relation_size(oid) DESC; и для страниц SELECT relname, relkind, reltuples, relpages FROM pg_class ORDER BY relpages DESC;

4) Очень полезный набор скриптов https://github.com/ikatson/postgres-useful-sql/blob/master/postgres_useful.sql (дальше из схемы adm выбрать adm.bloat)
...
Рейтинг: 0 / 0
08.11.2013, 18:15:03
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38458593
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
nedba,

Спасибо за линки и разъяснения, сейчас снизил только значения work_mem = 32 MB , maintenance_work_mem = 2 GB .

С фризами пока что всё ок:

Код: html
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
relname 	xid_age 	table_size
x	115360939	6954 MB
x	114673617	1628 MB
x	115346016	21 GB
x	115357451	2182 MB
x	114439767	5455 MB
x	114774147	4275 MB
x       135773432	1975 MB
x	115222463	5012 MB
x	114539484	1683 MB
x	135773429	2664 MB
x	114868458	2007 MB



Слежу дальше..
...
Рейтинг: 0 / 0
09.11.2013, 03:24:06
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38458594
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
nedba
3) bloated table - возможно, что у вас данные давно не оптимальны на диске.

По поводу tbloat , примерно раз в месяц запускаю команду CLUSTER на проблемные таблицы, так что с этим тоже должно быть всё ок.
...
Рейтинг: 0 / 0
09.11.2013, 03:27:01
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38472837
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
И так.. с новыми настройками система работает более менее стабильно и колом не вставала, load больше 4-х не поднимался, но почему-то по прежнему уходит в swap .

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

config:
Код: html
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
max_connections = 250
shared_buffers = 16GB
temp_buffers = 16MB
work_mem = 32MB
maintenance_work_mem = 2GB
max_stack_depth = 6MB
wal_buffers = 18MB
checkpoint_segments = 30
checkpoint_timeout = 30min
checkpoint_warning = 30s
effective_cache_size = 48GB



meminfo:
Код: 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.
34.
35.
36.
37.
38.
39.
40.
41.
42.
MemTotal:       74375964 kB
MemFree:          680872 kB
Buffers:          343976 kB
Cached:         70114640 kB
SwapCached:        31296 kB
Active:         48982688 kB
Inactive:       22185068 kB
Active(anon):   17319472 kB
Inactive(anon):   489300 kB
Active(file):   31663216 kB
Inactive(file): 21695768 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       7811064 kB
SwapFree:        7701880 kB
Dirty:              4824 kB
Writeback:             8 kB
AnonPages:        679544 kB
Mapped:         15371796 kB
Shmem:          17099668 kB
Slab:            1153504 kB
SReclaimable:    1124372 kB
SUnreclaim:        29132 kB
KernelStack:        2160 kB
PageTables:      1091496 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    44999044 kB
Committed_AS:   18453708 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      291180 kB
VmallocChunk:   34317170176 kB
HardwareCorrupted:     0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        6384 kB
DirectMap2M:     2080768 kB
DirectMap1G:    73400320 kB



load average: 0.38, 0.31, 0.30

SWAP 109184k used
...
Рейтинг: 0 / 0
21.11.2013, 13:27:08
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38473405
nedba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nedba
Участник
Самый плохой случай: ((8 воркеров Х 2Гб) + 48 + 16) и еще (32+16+6 на каждый коннект Х 250) Итого 70Гб + 13,5Гб максимум на что рассчитывает постгрес.

По факту, пиковых нагрузок на пределе возможностей нет, по тому в своп попали системные либы (скорее всего экзотическая аутентификация, ненужные драйвера и т.д.).

1) Используйте pgbouncer. (тогда разгрузите shared)
2) Постепенно снижайте все параметры (по одному за раз), пока не упретесь в проседания.
...
Рейтинг: 0 / 0
21.11.2013, 18:58:59
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38474035
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
nedba,

Ну понятно, спасибо!
...
Рейтинг: 0 / 0
22.11.2013, 12:05:02
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38483885
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
.. и снова привет!

В общем с очередным большим наплывом посетителей ситуация начала повторяться, но уже в другом ракурсе:

резко, в течении 20 секунд, на базу пришло порядком 100 запросов:
Код: html
1.
2.
3.
2013-11-27 15:24:46 EET LOG:  connection received: host=x.x.x.x port=60408
2013-11-27 15:24:46 EET LOG:  connection received: host=x.x.x.x port=35294
...


что привело к тормозам:

Код: html
1.
2.
3.
4.
5.
6.
2013-11-27 15:24:49 EET LOG:  duration: 3484.295 ms  execute S_2: COMMIT
2013-11-27 15:24:49 EET LOG:  duration: 3482.354 ms  execute S_2: COMMIT
2013-11-27 15:24:49 EET LOG:  duration: 3479.254 ms  execute S_2: COMMIT
2013-11-27 15:24:49 EET LOG:  duration: 3476.793 ms  execute S_2: COMMIT
2013-11-27 15:24:49 EET LOG:  duration: 3426.473 ms  execute S_2: COMMIT
...


и, как следствие, к переполнению слотов:

Код: html
1.
2013-11-27 15:24:58 EET FATAL:  remaining connection slots are reserved for non-replication superuser connections



В отличии от прошлых перегрузок, load average теперь остаётся в норме.

Пожалуйста посоветуйте, что ещё можно тут предпринять во избежание переполнения слотов ?

Крутить конфиг или взяться за железо и добавить RAM-памяти ? Поможет ли добавление памяти как-то ускорить переработку запросов или же просто даст возможность увеличить "max_connections" ?
...
Рейтинг: 0 / 0
29.11.2013, 18:16:33
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38483895
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
oustkast,

авторрезко, в течении 20 секунд, на базу пришло порядком 100 запросов

какие запросы? где планы?

20 секунд, 100 запросов - это ваще-то оч мало запросов
...
Рейтинг: 0 / 0
29.11.2013, 18:20:41
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38483957
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Misha Tyurin,

Не совсем понял вопроса, explain analyze запросов предоставить ) ? Просто запросы бегут постоянно одни и те же, нету каких-либо особенных или сверхтяжелых.
...
Рейтинг: 0 / 0
29.11.2013, 18:47:05
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38484021
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
oustkast,

explain analyze buffers
...
Рейтинг: 0 / 0
29.11.2013, 19:27:35
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38505020
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Misha TyurinЕще. Весь кеш рейд контроллера отдайте на запись.

И уменьшить упреждающее чтение хорошо через blockdev, если у вас много конкурентных индекссканов.

Вот такие общие замечания могут быть.

Кешь рэйда настраивается только через биос ?
...
Рейтинг: 0 / 0
18.12.2013, 13:16:30
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38505130
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Уменьшил shared_buffers до 8GB , но всё равно система не стабильна. В данный момент на ресурсе пик нагрузки по трафику и база данных прекрасно со всем справляется, но утром (08:30-35 график подтверждает), когда трафик не был ещё таким большим она встала на пару минут колом.

Кажется, что с распределением памяти (swap pagein?) что-то не того, может кто увидит ключ к разгадке ?






...
Рейтинг: 0 / 0
18.12.2013, 14:04:39
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38505419
Фотография Ёш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ёш
Участник
oustkast, а почему Вы swap не отключаете?
...
Рейтинг: 0 / 0
18.12.2013, 16:30:21
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38505455
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Ёш,

Да стрёмно в продакшене совсем без свапа, вруг системе памяти не хватит и база отвалится ?
...
Рейтинг: 0 / 0
18.12.2013, 16:47:39
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38505467
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
oustkast,

авторshared_buffers до 8GB - OK

у вас же видно !явно, что дело в свапе. убирите его и всё. линукс работает с памятью и свапом оч специфически. свап вам не нужен. сделайте небольшой ворк мем. контролируетйе кол-во запущенных процессов через пгбоунсер. у вас памяти вагоны совбодной, всё под кеш. так что убирите свап, и всё будет совсем хорошо
...
Рейтинг: 0 / 0
18.12.2013, 16:54:05
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38505478
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
oustkastЁш,

Да стрёмно в продакшене совсем без свапа, вруг системе памяти не хватит и база отвалится ?

для начала попробуйте vm.swappiness = 1
если еще не сделали....
скорее всего поможет
...
Рейтинг: 0 / 0
18.12.2013, 16:59:31
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38505494
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
oustkast,

авторсделайте небольшой ворк мем
сделайте 16MB. и поставте логгироваться врменые файлы.
18.8.3. What To Log
http://www.postgresql.org/docs/9.3/static/runtime-config-logging.html
log_temp_files (integer)
A value of zero logs all temporary file information

если они будут появляться, то 1) увеличивайте ворк мем для всего сервера на немного или
2) увеличивайте ворк мем только для тех транзакций, где надо, прямо через команды set local work_mem
...
Рейтинг: 0 / 0
18.12.2013, 17:06:25
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38505515
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
oustkast,

по вашим картинкам у вас диски ТОЛЬКО СВАП обслуживают (база вся в где-то в памяти у вас).

а далее возможны такие варианты

1) в этот свап попадает что-то нужное пг (часть какого-то индекса, например)

2) диски не справляются под нагрузкой свопа (что врятли, но возможно, покажите графики иопс/латенси),
а пг что-то делает с дисками синхронно, например, транзакции коммитятся синхронно.

ИТОГО. убирайте свап.
я за вариант сразу swapoff -a // при условии, что вы поработаете с воркмемом

ну и можно пробывать вариант Максима vm.swappiness = 1 и/или другие еще настрйоки vm. мне из vm помогали когда-то только настройки ридахеда. как раз на ядре 2.6.32 при планировщике NOOP. а vm.swappiness = 1 - не помогало, свап продожал что-то делать.
...
Рейтинг: 0 / 0
18.12.2013, 17:20:18
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38505555
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
графики иопс/латенси:






С work_mem экспериментировать пока не буду, т.к заказаны дополнительные 72 GB ram-памяти и придут они уже в начале года.

А скажите, vm.swappiness = 1 можно поменять на лету (sysctl -p) без каких-либо рисков ? Сейчас значение> vm.swappiness = 60
...
Рейтинг: 0 / 0
18.12.2013, 17:44:54
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38505564
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Код: 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.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
Smart Array P410i in Slot 0 (Embedded)
   Bus Interface: PCI
   Slot: 0
   Serial Number: 5**
   Cache Serial Number: PA**
   RAID 6 (ADG) Status: Disabled
   Controller Status: OK
   Hardware Revision: Rev C
   Firmware Version: 5.70
   Rebuild Priority: Medium
   Expand Priority: Medium
   Surface Scan Delay: 15 secs
   Surface Scan Mode: Idle
   Queue Depth: Automatic
   Monitor and Performance Delay: 60 min
   Elevator Sort: Enabled
   Degraded Performance Optimization: Disabled
   Inconsistency Repair Policy: Disabled
   Wait for Cache Room: Disabled
   Surface Analysis Inconsistency Notification: Disabled
   Post Prompt Timeout: 0 secs
   Cache Board Present: True
   Cache Status: OK
   Accelerator Ratio: 25% Read / 75% Write
   Drive Write Cache: Disabled
   Total Cache Size: 512 MB
   No-Battery Write Cache: Disabled
   Cache Backup Power Source: Batteries
   Battery/Capacitor Count: 1
   Battery/Capacitor Status: OK
   SATA NCQ Supported: True

   Array: A
      Interface Type: SAS
      Unused Space: 0 MB
      Status: OK



      Logical Drive: 1
         Size: 558.7 GB
         Fault Tolerance: RAID 1+0
         Heads: 255
         Sectors Per Track: 32
         Cylinders: 65535
         Strip Size: 256 KB
         Status: OK
         Array Accelerator: Enabled
         Unique Identifier: 6005**
         Disk Name: /dev/cciss/c0d0
         Mount Points: /boot 487 MB
         OS Status: LOCKED
         Logical Drive Label: ADFCAC2F5001438021F00D903DF1
         Mirror Group 0:
            physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
            physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, OK)
         Mirror Group 1:
            physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
            physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
...
Рейтинг: 0 / 0
18.12.2013, 17:48:19
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38505769
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
oustkast,

у вас там lvm что-ли еще? как она работает?
...
Рейтинг: 0 / 0
18.12.2013, 19:34:48
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38506466
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Misha Tyurin,

Да, изначально дисковая система была настроена на LVM, чтобы при необходимости была возможность менять размер дисков на лету. Но это никак не должно сказоваться на производительности системы в целом, т.к в среднем пишется по одному WAL-файлу (17MB) в минуту.
...
Рейтинг: 0 / 0
19.12.2013, 13:37:54
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38508215
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oustkast
Гость
Поменял в ядре такие значения:

Код: html
1.
2.
vm.swappiness=1
vm.overcommit_memory=2



и буду следить дальше.

Всем спасибо!
...
Рейтинг: 0 / 0
20.12.2013, 17:08:04
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38511787
_Monah_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_Monah_
Участник
Сори, что влезаю в чужую тему.
Подскажите пожалуйста, что можно сделать в такой ситуации:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
2013-12-25 08:53:00 FET  PID:23292 TID: 0 LOG:  checkpoint complete: wrote 183662 buffers (17.5%); 0 transaction log file(s) added, 0 removed, 61 recycled; write=13.169 s, sync=146.090 s, total=165.334 s; sync files=287, longest=16.449 s, average=0.509 s
2013-12-25 08:53:00 FET  PID:23292 TID: 0 LOG:  checkpoint starting: xlog
2013-12-25 08:57:20 FET  PID:23292 TID: 0 LOG:  checkpoint complete: wrote 198635 buffers (18.9%); 0 transaction log file(s) added, 0 removed, 72 recycled; write=81.896 s, sync=175.407 s, total=260.276 s; sync files=327, longest=21.261 s, average=0.536 s
2013-12-25 08:57:20 FET  PID:23292 TID: 0 LOG:  checkpoint starting: xlog
2013-12-25 09:02:20 FET  PID:23292 TID: 0 LOG:  checkpoint complete: wrote 159368 buffers (15.2%); 0 transaction log file(s) added, 11 removed, 71 recycled; write=79.125 s, sync=205.506 s, total=300.513 s; sync files=425, longest=21.696 s, average=0.483 s
2013-12-25 09:02:20 FET  PID:23292 TID: 0 LOG:  checkpoint starting: xlog
2013-12-25 09:07:17 FET  PID:23292 TID: 0 LOG:  checkpoint complete: wrote 142119 buffers (13.6%); 0 transaction log file(s) added, 0 removed, 69 recycled; write=83.368 s, sync=200.674 s, total=296.280 s; sync files=418, longest=33.860 s, average=0.480 s
2013-12-25 09:07:17 FET  PID:23292 TID: 0 LOG:  checkpoint starting: xlog


Код: sql
1.
2.
3.
4.
postgres=# select * from pg_stat_bgwriter;
 checkpoints_timed | checkpoints_req | buffers_checkpoint | buffers_clean | maxwritten_clean | buffers_backend | buffers_backend_fsync | buffers_alloc |          stats_reset
-------------------+-----------------+--------------------+---------------+------------------+-----------------+-----------------------+---------------+-------------------------------
                 8 |             523 |          102840769 |       4426963 |            42417 |        54774231 |                     0 |     218853340 | 2013-12-23 14:25:38.281495+03


Настройки:
checkpoint_segments = 40
checkpoint_timeout = 30min
checkpoint_completion_target = 0.7

Постоянный iowait 20% и больше.
...
Рейтинг: 0 / 0
25.12.2013, 10:39:38
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38512227
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
_Monah_,

авторcheckpoint starting: xlog
checkpoint_segments = 40

ваши 40 валов за несколько минут копятся. сделайте много сегментов.

но оч вероятно, что ваши проблемы с iowait в другом
...
Рейтинг: 0 / 0
25.12.2013, 15:24:46
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38512414
_Monah_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_Monah_
Участник
Misha Tyurin,

я недавно с постгресом познакомился.
В чем может быть проблема?
...
Рейтинг: 0 / 0
25.12.2013, 17:57:51
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38512427
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
_Monah_,

я давно, и тоже не знаю, в чем у вас может быть проблема. не телепат) много возможных мест
...
Рейтинг: 0 / 0
25.12.2013, 18:13:26
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38512472
_Monah_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_Monah_
Участник
Misha Tyurin,

увеличил количество сегментов до 80 и checkpoint_completion_target = 0.9 - появляются окна, но iowait не падает. Постоянно растет размер бд. Где-то 15Гб в сутки.
...
Рейтинг: 0 / 0
25.12.2013, 19:24:17
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38512517
nedba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nedba
Участник
nedba Очень полезный набор скриптов https://github.com/ikatson/postgres-useful-sql/blob/master/postgres_useful.sql (дальше из схемы adm выбрать adm.bloat)

_Monah_

Во первых сколько у вас коннектов одновременно.
Во вторых размер самой большой таблицы с которой идет работа.
В третьих vacuum analyze на все БД.
Индексы (все ли есть на референсы, уники и первичные ключи)
Используете ли pgbouncer(или аналог, так как бакенды дорогой ресурс)
Кто еще использует диск (бэкапер, крон и т.д). vmstat.
Железо в каком состоянии - состояние рейда, формат рейда (не 5(0) и не 6(0)), контроллер и его батарейка.
В сислог не сыпятся ли ошибки про DMA и RAM?
Нет ли в стойке с сервером устройства, которое рассылает флуд пакеты.
и т.д.

Будет интересно, сообщайте побольше подробностей. А так только могу советовать все (!) партиционировать (так вы снимите нагрузку с перестройки индексов) и перенести архивные данные на физически другое устройство (возможно медленное, но так вы разгрузите бутылочное горлышко IO)
...
Рейтинг: 0 / 0
25.12.2013, 20:35:24
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38512701
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
_Monah_Misha Tyurin,

увеличил количество сегментов до 80 и checkpoint_completion_target = 0.9 - появляются окна, но iowait не падает. Постоянно растет размер бд. Где-то 15Гб в сутки.

вариантов собственно два -
1)железо не соответсвующее текущей нагрузке
(какой у вас размер базы? что в нее пишется и как? сколько памяти на сервере? какая конфигурация дисковой подсистемы?)

или

2)напрограмировали что то не то при работе с базой и она не справляется под получившейся нагрузкой

По сути одно и тоде но с важным различием:
1) - нагрузка по делу и надо ддумать о обновлениии железа
2) - нагрузка не по делу и надо искать от чего идет столько записи и лечить код

возможно сочетание 1 и 2
...
Рейтинг: 0 / 0
26.12.2013, 01:28:43
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38512949
tadmin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tadmin
Участник
Стоит посмотреть, жива ли батарейка на RAID контроллере. Правильные контроллеры, обнаружив проблемы с батареей, тут же выключают write-back. В результате очень сильно проседает IO на запись.
...
Рейтинг: 0 / 0
26.12.2013, 12:22:54
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38514555
_Monah_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_Monah_
Участник
to all,
джавовский c3p0 Используется. коннектов в среднем 140, в пиках до 250.
Самая большая таблица порядка 30Гб
autovacuum трудится(но, по-моему, не справляется)
индексы на фк надо проверять
Код: sql
1.
2.
3.
4.
vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 2  5      0 738516  11896 52452908    0    0    78   488    0    0  2  0 96  2


Бэкапы делаются на сетевой диск
Железо: 2 Intel Xeon E5-2620 (12 Cores CPU) 56GB RAM RAID5 (8x600GB) 15,000RPM SAS (или что вы имеете ввиду?)
контроллер хардварный, 448Мб памяти вроде. батарейка живая.
Ошибки в лог не сыпятся, иначе приходили б смски.
Нет ли в стойке с сервером устройства, которое рассылает флуд пакеты
не знаю. сервера арендованные

Партицинировать нету смысла, потому что нету архивных данных. Все постоянно обновляется
...
Рейтинг: 0 / 0
27.12.2013, 17:50:54
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38514606
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
_Monah_ <>
Партицинировать нету смысла, потому что нету архивных данных. Все постоянно обновляетсяесли всё постоянно обновляется, надо делать периодические реиндексы (таки надо, как показывает практика -- поправьте, если не так)

а партицирование, вероятно, позволяло бы реиндексировать меньшее кол-во записей за раз

хотя того же можно добиться условным индексом, но на условный не навесишь фк (и да, партицирование сильно усложняет возможность обвеситься фкеями)
...
Рейтинг: 0 / 0
27.12.2013, 18:22:44
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38514636
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
_Monah_,

RAID5 - это очень подозрительно.

10ку надо - это максимальная производительность.
...
Рейтинг: 0 / 0
27.12.2013, 19:08:11
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38514639
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
_Monah_,

"448Мб" - а размер шаред буферов какой у вас при этом?
...
Рейтинг: 0 / 0
27.12.2013, 19:09:32
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38514768
_Monah_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_Monah_
Участник
qwwq,
была большая таблица одна, мы ее разбили на части, но на нее не было фк. Автовакуумы стали отрабатывать.
Реиндекс ж лочит таблицу.
pg_reorg еще работает, но запустили его не очень давно, поэтому статистики маловато.

Misha Tyurin,
надо, но нужно нагрузочное тестирование проводить, чтобы сравнить производительность
shared_buffers = 8192MB
...
Рейтинг: 0 / 0
27.12.2013, 22:06:22
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38514909
йццй
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
йццй
Гость
_Monah_qwwq,
<>
Реиндекс ж лочит таблицу.
<>
а куда деваццо
пример:
таблица - пол1000 записей
2 [составных] unique индекса, оба 2- по несколько мегов (изрядно многостраничны, даже после [авто]вакуума)
вакуум (простой) не спасает
...
Рейтинг: 0 / 0
28.12.2013, 11:37:22
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38514930
_Monah_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_Monah_
Участник
йццй,
надо подумать. возможно созданием технологических окон
...
Рейтинг: 0 / 0
28.12.2013, 12:41:07
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38515298
_Monah_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_Monah_
Участник
йццйа куда деваццо

Возможно созданием рядом такого же индекса concurrently, прибиваем старый и переименовываем новый
...
Рейтинг: 0 / 0
29.12.2013, 12:35:16
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38515302
йццй
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
йццй
Гость
_Monah_йццйа куда деваццо

Возможно созданием рядом такого же индекса concurrently, прибиваем старый и переименовываем новыйну, да, но

при наличии ф-кея (реиндекс п-кея)-- требуется ещё кучка пассов руками - снос ф-кея, дроп старого индекса создание ф-кея на новом. одной транзакцией.
...
Рейтинг: 0 / 0
29.12.2013, 13:01:37
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38520591
_Monah_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_Monah_
Участник
Misha Tyurin_Monah_,

RAID5 - это очень подозрительно.

10ку надо - это максимальная производительность.
и как по-вашему должна выглядеть дисковая подсистема с таким количеством дисков?
...
Рейтинг: 0 / 0
09.01.2014, 15:30:44
| Ответить | Цитировать | Написать  
Высокий IO wait
    #38522764
Sergei.Agalakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergei.Agalakov
Участник
_Monah_Misha Tyurin_Monah_,

RAID5 - это очень подозрительно.

10ку надо - это максимальная производительность.
и как по-вашему должна выглядеть дисковая подсистема с таким количеством дисков?
4 зеркала. RAID5 по записи в 2 раза менее эффективен, чем RAID10. В RAID5 для записи одного измененного блока вам надо прочитать старые данные, старую контрольную сумму, посчитать новую контрольную сумму, записать новые данные, записать новую контрольную сумму. Итого 4 I/O. В RAID10 просто пишется две копии новых данных. Итого 2 I/O. Это если на пальцах, потому что разные производители контроллеров делают всякие оптимизации, но если затык по записи, то с RAID5 надо соскакивать. Ну еще хорошо в этот RAID10 добавить дисков и WAL выкинуть на отдельное зеркало.
...
Рейтинг: 0 / 0
11.01.2014, 03:59:47
| Ответить | Цитировать | Написать  
90 сообщений из 90, показаны все 4 страниц
  все  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Высокий IO wait
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=53&tid=1998903]:
 0ms
get settings:
 8ms
get forum list:
 20ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 242ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 64ms
get tp. blocked users:
 1ms
others: 196ms
total:  546ms
созд. / загр.: 546ms
x
x
Закрыть


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