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

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

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

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

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

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

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

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

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

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

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

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

я бы не уменьшал шаред бафферс, при налиыие настроенного рейда (дисков правда малова-то, но это уже подробнее надо смотреть более подробно). Вам нужно сделать более редкими чекпойнты (поднять таймаут) и скорее всего уменьшать ворк_мемори м/или кол-во процессов. От 300 процессов пользы ноль, вреда много - с таким воркмемом вы уходите в свап как только система затыкается на чекпойнте. За баунсером вообще крайне редко нужно больше пары десятков процессов.
...
Рейтинг: 0 / 0
Высокий IO wait
    #38437984
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
Высокий IO wait
    #38438314
_Monah_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hydrobiontА как меряли соотношение чтений и записи?

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

vm.dirty_ratio = 33554432
vm.dirty_background_ratio = 268435456

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

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

vm.dirty_ratio = 33554432
vm.dirty_background_ratio = 268435456

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

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

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

Но так как сервер не выделен - то все может оч сильно зависеть не от постгреса
...
Рейтинг: 0 / 0
Высокий IO wait
    #38443880
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
Высокий IO wait
    #38446054
Knt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Возможно вопрос не в тему но сколько попугаев на такой системе дает нагрузочный тест Гилева ?
(у меня аналогичная система с меньшим обьемом памяти 16ГБ и по тесту выше 9 попугаев прыгнуть просто не выходит)
...
Рейтинг: 0 / 0
Высокий IO wait
    #38446698
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
KntВозможно вопрос не в тему но сколько попугаев на такой системе дает нагрузочный тест Гилева ?
(у меня аналогичная система с меньшим обьемом памяти 16ГБ и по тесту выше 9 попугаев прыгнуть просто не выходит)

Не нашел документации как его под Линуксом запускать через эс-эс-ха..
...
Рейтинг: 0 / 0
Высокий IO wait
    #38447364
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
Высокий IO wait
    #38447380
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Код: html
1.
2.
vm.dirty_background_bytes
vm.dirty_bytes



или же это имелось в виду..
...
Рейтинг: 0 / 0
Высокий IO wait
    #38447778
_Monah_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oustkast,
я думаю, что это.
Только разницы лично я на наших серверах не заметил от изменения этих параметров
...
Рейтинг: 0 / 0
Высокий IO wait
    #38453577
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
Высокий IO wait
    #38453586
hydrobiont
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oustkast
Код: html
1.
2.
vm.dirty_background_bytes
vm.dirty_bytes



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

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

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



Зачем это?

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

И да - у вас база за баунсером или напрямую?
...
Рейтинг: 0 / 0
Высокий IO wait
    #38455085
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
Высокий IO wait
    #38455088
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
Высокий IO wait
    #38455491
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
Высокий IO wait
    #38455996
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
Высокий IO wait
    #38456866
oustkast
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Запустил на тестовом сервере (где выставил work_mem=1 MB) тяжелый запрос и как видно он использует максимально памяти в 3 MB , получается нам за глаза хватит и размера work_mem=25 MB , к примеру ? Или ещё надо что-то учитывать ?

Код: html
1.
Sort Method: external merge  Disk: 3120kB
...
Рейтинг: 0 / 0
Высокий IO wait
    #38456986
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
Высокий IO wait
    #38458310
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
Высокий IO wait
    #38458593
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
25 сообщений из 90, страница 2 из 4
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Высокий IO wait
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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