|
|
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Misha Tyurin, увеличил количество сегментов до 80 и checkpoint_completion_target = 0.9 - появляются окна, но iowait не падает. Постоянно растет размер бд. Где-то 15Гб в сутки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2013, 19:24:17 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
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) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2013, 20:35:24 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
_Monah_Misha Tyurin, увеличил количество сегментов до 80 и checkpoint_completion_target = 0.9 - появляются окна, но iowait не падает. Постоянно растет размер бд. Где-то 15Гб в сутки. вариантов собственно два - 1)железо не соответсвующее текущей нагрузке (какой у вас размер базы? что в нее пишется и как? сколько памяти на сервере? какая конфигурация дисковой подсистемы?) или 2)напрограмировали что то не то при работе с базой и она не справляется под получившейся нагрузкой По сути одно и тоде но с важным различием: 1) - нагрузка по делу и надо ддумать о обновлениии железа 2) - нагрузка не по делу и надо искать от чего идет столько записи и лечить код возможно сочетание 1 и 2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2013, 01:28:43 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Стоит посмотреть, жива ли батарейка на RAID контроллере. Правильные контроллеры, обнаружив проблемы с батареей, тут же выключают write-back. В результате очень сильно проседает IO на запись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2013, 12:22:54 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
to all, джавовский c3p0 Используется. коннектов в среднем 140, в пиках до 250. Самая большая таблица порядка 30Гб autovacuum трудится(но, по-моему, не справляется) индексы на фк надо проверять Код: sql 1. 2. 3. 4. Бэкапы делаются на сетевой диск Железо: 2 Intel Xeon E5-2620 (12 Cores CPU) 56GB RAM RAID5 (8x600GB) 15,000RPM SAS (или что вы имеете ввиду?) контроллер хардварный, 448Мб памяти вроде. батарейка живая. Ошибки в лог не сыпятся, иначе приходили б смски. Нет ли в стойке с сервером устройства, которое рассылает флуд пакеты не знаю. сервера арендованные Партицинировать нету смысла, потому что нету архивных данных. Все постоянно обновляется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2013, 17:50:54 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
_Monah_ <> Партицинировать нету смысла, потому что нету архивных данных. Все постоянно обновляетсяесли всё постоянно обновляется, надо делать периодические реиндексы (таки надо, как показывает практика -- поправьте, если не так) а партицирование, вероятно, позволяло бы реиндексировать меньшее кол-во записей за раз хотя того же можно добиться условным индексом, но на условный не навесишь фк (и да, партицирование сильно усложняет возможность обвеситься фкеями) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2013, 18:22:44 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
_Monah_, RAID5 - это очень подозрительно. 10ку надо - это максимальная производительность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2013, 19:08:11 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
_Monah_, "448Мб" - а размер шаред буферов какой у вас при этом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2013, 19:09:32 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
qwwq, была большая таблица одна, мы ее разбили на части, но на нее не было фк. Автовакуумы стали отрабатывать. Реиндекс ж лочит таблицу. pg_reorg еще работает, но запустили его не очень давно, поэтому статистики маловато. Misha Tyurin, надо, но нужно нагрузочное тестирование проводить, чтобы сравнить производительность shared_buffers = 8192MB ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2013, 22:06:22 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
_Monah_qwwq, <> Реиндекс ж лочит таблицу. <> а куда деваццо пример: таблица - пол1000 записей 2 [составных] unique индекса, оба 2- по несколько мегов (изрядно многостраничны, даже после [авто]вакуума) вакуум (простой) не спасает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2013, 11:37:22 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
йццй, надо подумать. возможно созданием технологических окон ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2013, 12:41:07 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
йццйа куда деваццо Возможно созданием рядом такого же индекса concurrently, прибиваем старый и переименовываем новый ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2013, 12:35:16 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
_Monah_йццйа куда деваццо Возможно созданием рядом такого же индекса concurrently, прибиваем старый и переименовываем новыйну, да, но при наличии ф-кея (реиндекс п-кея)-- требуется ещё кучка пассов руками - снос ф-кея, дроп старого индекса создание ф-кея на новом. одной транзакцией. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2013, 13:01:37 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Misha Tyurin_Monah_, RAID5 - это очень подозрительно. 10ку надо - это максимальная производительность. и как по-вашему должна выглядеть дисковая подсистема с таким количеством дисков? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2014, 15:30:44 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
_Monah_Misha Tyurin_Monah_, RAID5 - это очень подозрительно. 10ку надо - это максимальная производительность. и как по-вашему должна выглядеть дисковая подсистема с таким количеством дисков? 4 зеркала. RAID5 по записи в 2 раза менее эффективен, чем RAID10. В RAID5 для записи одного измененного блока вам надо прочитать старые данные, старую контрольную сумму, посчитать новую контрольную сумму, записать новые данные, записать новую контрольную сумму. Итого 4 I/O. В RAID10 просто пишется две копии новых данных. Итого 2 I/O. Это если на пальцах, потому что разные производители контроллеров делают всякие оптимизации, но если затык по записи, то с RAID5 надо соскакивать. Ну еще хорошо в этот RAID10 добавить дисков и WAL выкинуть на отдельное зеркало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 03:59:47 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38520591&tid=1998903]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
63ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 223ms |
| total: | 364ms |

| 0 / 0 |
