|
|
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkast, Своп точно надо вырубать. swapoff -a И уменьшить шаред буфера минимум в два раза. Планировшик - noop И наблюдать дальше ) --- Вы уверены что никакой хитрой нагрузки к вам не приходит иногда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2013, 01:19:16 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Еще. Весь кеш рейд контроллера отдайте на запись. И уменьшить упреждающее чтение хорошо через blockdev, если у вас много конкурентных индекссканов. Вот такие общие замечания могут быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2013, 02:13:55 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Чекпоинт таймаут в 1час И чекпоинт таргет в 1цу (checkpoint_completion_target) И пусть всегда по времени пишется. Поставки много чекпоинт сегментс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2013, 02:23:38 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Misha TyurinИ уменьшить шаред буфера минимум в два раза. Вы уверены что никакой хитрой нагрузки к вам не приходит иногда? А могли бы пожалуйтса пояснить зачем уменьшать shared_buffers ? Рам-памяти же достаточно на машине, 72 ГБ. Никакой хитрой нагрузки не приходит, ей некуда приходить и страдает только база данных, графики веб сервера без изменений. Бывало и так, что во время пиков активности клиентов база и вовсе не страдала, а при средней нагрузке выкидывала неприятные сюрпризы.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2013, 13:40:49 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkast, я бы не уменьшал шаред бафферс, при налиыие настроенного рейда (дисков правда малова-то, но это уже подробнее надо смотреть более подробно). Вам нужно сделать более редкими чекпойнты (поднять таймаут) и скорее всего уменьшать ворк_мемори м/или кол-во процессов. От 300 процессов пользы ноль, вреда много - с таким воркмемом вы уходите в свап как только система затыкается на чекпойнте. За баунсером вообще крайне редко нужно больше пары десятков процессов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2013, 18:59:08 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Начал пока что со следующих изменений: Код: html 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Со следующей недели ожидается большой поток посетителей и отпишусь о результатах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2013, 10:59:02 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
hydrobiontА как меряли соотношение чтений и записи? Дефолты не подходят совсем если памяти много. Поставьте например vm.dirty_ratio = 33554432 vm.dirty_background_ratio = 268435456 это не в байтах случаем числа? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2013, 14:00:34 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
_Monah_hydrobiontА как меряли соотношение чтений и записи? Дефолты не подходят совсем если памяти много. Поставьте например vm.dirty_ratio = 33554432 vm.dirty_background_ratio = 268435456 это не в байтах случаем числа? в байтах да ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2013, 14:51:50 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkast, А зачем вам 16gb ? Всегда рекомендуют начинать с 4 gb. Большие буфера - вероятны оверхеды. Их можно исключить. А значет нужно уменьшаит . практически уверен что вам и 4/8 gb хватит более чем. Но так как сервер не выделен - то все может оч сильно зависеть не от постгреса ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2013, 07:00:17 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Misha Tyurinoustkast, А зачем вам 16gb ? Всегда рекомендуют начинать с 4 gb. Большие буфера - вероятны оверхеды. Их можно исключить. А значет нужно уменьшаит . практически уверен что вам и 4/8 gb хватит более чем. Но так как сервер не выделен - то все может оч сильно зависеть не от постгреса Изначально выставил в 16GB из примера мануала по настройке Postgres-a : 1/4 of RAM. Если будет мешать - снижу до 8GB , а вообще план добавить в ближайшем будущем ещё 48 GB RAM-a. С чего берёте, что сервер не выделен ? =) В первом посте приведена полная спецификация сервера и уточню, что кроме Postgres-a на сервере ничего больше не бегает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2013, 17:06:08 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Возможно вопрос не в тему но сколько попугаев на такой системе дает нагрузочный тест Гилева ? (у меня аналогичная система с меньшим обьемом памяти 16ГБ и по тесту выше 9 попугаев прыгнуть просто не выходит) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2013, 06:37:14 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
KntВозможно вопрос не в тему но сколько попугаев на такой системе дает нагрузочный тест Гилева ? (у меня аналогичная система с меньшим обьемом памяти 16ГБ и по тесту выше 9 попугаев прыгнуть просто не выходит) Не нашел документации как его под Линуксом запускать через эс-эс-ха.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2013, 14:31:14 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
hydrobiont Дефолты не подходят совсем если памяти много. Поставьте например vm.dirty_ratio = 33554432 vm.dirty_background_ratio = 268435456 hydrobiont, пардон, если туплю, но прогуглив эти параметры, числа должны быть указаны в процентах (0-100), а не байтах: Код: html 1. 2. 3. Может уточните, откуда такие длинные числа ? ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2013, 19:23:55 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Код: html 1. 2. или же это имелось в виду.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2013, 19:40:24 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkast, я думаю, что это. Только разницы лично я на наших серверах не заметил от изменения этих параметров ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2013, 09:50:39 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Ситуация начала повторяться, но уже слабее, слоты пока ещё не переполнялись. Кол-во воркеров скакало от нормальных ~90 до 220 в пик нагрузки вне зависимости от чекпойнта. С чем это связано непонятно.. Походу память временами забивается. (самая длинная полоска - это запуск команды ANALYZE ALL каждый день в 5 утра) Код: html 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Что думаете, может попробовать теперь снизить shared_buffers с 16GB до 8GB и ещё work_mem с 288MB до 250MB ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2013, 18:43:13 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkast Код: html 1. 2. или же это имелось в виду.. Да, конечно это, сорри. [quot oustkast] Код: html 1. Зачем это? И зачем вам такой большой воркмем? каждая сессия реально в таковом нуждается? И да - у вас база за баунсером или напрямую? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2013, 18:51:02 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
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. Правильно ли я понимаю, что каждый процесс Postgres использует количество памяти = work_mem или же это максимальное значение, что сможет при надобности использовать процесс ? Т.е. 90 процессов будут использовать кол-во памяти равное 90*128MB=11.25GB или не обязательно ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2013, 19:09:56 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
hydrobiont, ANALYZE для оптимизации планировщика запросов. Рекомендацию нашел из вики: Using ANALYZE Используем джававский баунсер - c3p0 . как насчёт таких уменьшений, разумно ? Код: html 1. 2. 3. Правильно ли я понимаю, что каждый процесс Postgres использует количество памяти = work_mem или же это максимальное значение, что сможет при надобности использовать процесс ? Т.е. 90 процессов будут использовать кол-во памяти равное 90*128MB=11.25GB или не обязательно ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2013, 19:11:17 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
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, по тому постгрес и стартует воркеры так часто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2013, 08:09:34 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
nedbamaintenance_work_mem берется из расчета 75% размера от самой большой таблицы. Отъедает по maintenance_work_mem раз сколько у вас воркеров будет запущено. Оптимально для почти всех видов баз в которых никто ничего не понимает 512 мб при средней нагрузке. сиблинг поставьте больше, к примеру 16 или 24. проверьте ваши фризы - возможно у вас уже 97% от 200 000 000 000, по тому постгрес и стартует воркеры так часто. Самая большая таблица в базе 30 GB. попробую увеличить и это тогда: Код: html 1. Сорри, но как проверить фризы ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2013, 13:19:33 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
Запустил на тестовом сервере (где выставил work_mem=1 MB) тяжелый запрос и как видно он использует максимально памяти в 3 MB , получается нам за глаза хватит и размера work_mem=25 MB , к примеру ? Или ещё надо что-то учитывать ? Код: html 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2013, 19:14:50 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
oustkastЗапустил на тестовом сервере (где выставил work_mem=1 MB) тяжелый запрос и как видно он использует максимально памяти в 3 MB , получается нам за глаза хватит и размера work_mem=25 MB , к примеру ? Или ещё надо что-то учитывать ? Код: html 1. "Sort Method: external merge Disk: 3120kB" говорит о том, что work_mem не хватает для этого запроса, приблизительно 10 МБ, тк при записи на диск хорошо жмется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2013, 21:03:44 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
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) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2013, 18:15:03 |
|
||
|
Высокий IO wait
|
|||
|---|---|---|---|
|
#18+
nedba, Спасибо за линки и разъяснения, сейчас снизил только значения work_mem = 32 MB , maintenance_work_mem = 2 GB . С фризами пока что всё ок: Код: html 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Слежу дальше.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2013, 03:24:06 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38442965&tid=1998903]: |
0ms |
get settings: |
9ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
176ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
79ms |
get tp. blocked users: |
1ms |
| others: | 230ms |
| total: | 532ms |

| 0 / 0 |
