Является ли сокращение свободного места на диске хорошим общим индикатором слишком низкой настройки `work_mem`?

Насколько я понимаю (после долгих поисков в интернете)...

1- Если компонент запроса (сортировка, объединение и т. д.) использует больше ОЗУ/памяти, чем моя настройка work_mem или, общая память, используемая всеми текущими операциями на сервере, превышает доступную память ОС, запрос начнет запись на диск.

Это правда?

2- Postgres (и многие другие хорошие механизмы БД) используют много памяти для кэширования, поэтому запросы выполняются быстрее; следовательно, сервер должен указывать на низкий уровень свободной памяти, даже если сервер на самом деле не голодает памяти. Таким образом, низкий уровень свободной памяти на самом деле не указывает ни на что, кроме хорошего механизма БД и здорового использования.

Это правда?

3- Если и № 1, и № 2 выше верны, сохраняя все остальное содержимое, если я хочу, чтобы индикатор платы с параметром work_mem был слишком низким или не хватало общей памяти ОС, я должен посмотреть, есть ли на сервере свободное место на диске. идет вниз?

Я правильно об этом думаю?

ссылки:

https://www.postgresql.org/docs/current/static/runtime-config-resource.html

http://patshaughnessy.net/2016/1/22/is-your-postgres-query-starved-for-memory

https://www.enterprisedb.com/monitor-cpu-and-memory-percentage-used-each-process-postgresqlppas-9

https://dba.stackexchange.com/questions/18484/tuning-postgresql-for-large-amounts-of-ram

Я знаю, что могу установить log_temp_files и просмотреть отдельные временные файлы, чтобы настроить параметр work_mem, но мне нужен общий показатель, который я мог бы использовать, чтобы определить, возможно work_mem слишком низкое, прежде чем я начну копаться в поисках временных файлов. размеры файлов превышают мою настройку work_mem.

У меня PostgreSQL 10.


postgresql performance memory-management memory postgresql-performance
person mountainclimber11    schedule 15.11.2017    source источник
comment
1) нет 2) определение свободной памяти зависит от ОС 3) это зависит (от типичного запроса), в любом случае: свободное место на диске не является хорошей мерой.   -  person wildplasser    schedule 15.11.2017
comment
@wildplasser - Спасибо! Я удивлен вашим отказом на № 1. Можете ли вы дать мне одно пояснение, чтобы указать мне правильное направление для поиска в Интернете?   -  person mountainclimber11    schedule 15.11.2017
comment
Перечитай свою первую и четвертую ссылку. (и игнорируйте второй, это ерунда, по крайней мере, для unix)   -  person wildplasser    schedule 15.11.2017
comment
@wildplasser - еще раз спасибо. К сожалению, я прочитал все эти ссылки. Не сказать, что все понял, но прочитал. Я думаю, вы указываете, что это сложнее, чем ваш OQ, а не то, что вы упускаете из виду ключевой момент ________. Если да, можете ли вы указать, например, причину № 1 неправильно? Если нет, можете ли вы назвать ключевой момент, который я упускаю? спасибо / извините. Я больше финансист, чем разработчик.   -  person mountainclimber11    schedule 15.11.2017
comment
Уменьшение свободного места на диске — плохой показатель. Временные таблицы обычно имеют размер 10...100 МБ и очищаются в конце транзакции. Могут появиться очень большие файлы, если какой-то запрос (случайно) создаст декартово произведение. В этом случае вы заметите...   -  person joop    schedule 16.11.2017

Ответы (1)


arrow_upward
2
arrow_downward

Обработка запроса состоит из нескольких шагов:

  1. генерировать (все) возможные планы
  2. оценить стоимость выполнения этих планов (с точки зрения ресурсов: дисковый ввод-вывод, буферы, память, ЦП) на основе констант настройки и статистики.
  3. выбрать «оптимальный» план, основываясь на константах настройки
  4. выполнить выбранный план.

В большинстве случаев план, который, как ожидается (шаг 2), потребует большего количества work_mem, чем установленное значение work_mem, не будет выбран на шаге 3. (поскольку «сброс на диск» считается очень дорогим). Как только шаг 4 обнаруживает, что ему нужно больше рабочей_памяти, его единственным выбором является сброс на диск. Дерьмо случается ... По крайней мере, это не зависит от подкачки страниц ОС в перегруженной памяти.)

Правила очень просты:

  • хэш-соединения часто оптимальны, но требуют памяти
  • не пытайтесь использовать больше памяти, чем у вас есть
  • если есть разница между ожидаемой (шаг 2) и наблюдаемой (шаг 4) памятью, ваша статистика неверна. Вы будете наказаны разливом на диск.
  • отсутствие пригодных для использования индексов приведет к хэш-соединениям или последовательностям сканирования.
  • сортировка также использует work_mem. Механизм аналогичен: плохие оценки приводят к плохим планам.
  • CTE часто/всегда (?) материализуются. Это будет записано на диск, как только ваше буферное пространство переполнится.
  • CTE не имеют статистики и не имеют индексов.

Несколько правил/советов:

  • используйте правильную модель данных (и не денормализуйте)
  • используйте правильные PK/FK и вторичные индексы.
  • запустите ANALYZE the_table_name;, чтобы собрать свежую статистику после значительных изменений структуры или данных таблицы.

Мониторинг:

  • проверьте лог-файл Postgres
  • проверить план запроса, сравнить наблюдаемое ‹--> ожидаемое
  • контролировать использование системных ресурсов (в Linux: через top/vmstat/iostat)
person wildplasser    schedule 15.11.2017
comment
Я не думаю, что есть какой-либо сайт, который описывает ваши пункты 1-4 и абзац после них где-либо еще в Интернете, по крайней мере, там, где это делается так кратко, используя простой язык. Благодарю вас! - person mountainclimber11; 16.11.2017