Postgres DISK IO очень высокий. Что я могу сделать, чтобы уменьшить это немедленно?
Я знаю, что более быстрые диски, чем то, что я использую, помогут, но это займет больше времени, и я пытаюсь использовать некоторые экстренные меры для уменьшения дискового ввода-вывода. поверх постоянно сообщает об использовании DSK на красной. Это для postgres 8.3.
Моя настройка shared_buffers составляет 24 МБ, хотя на сервере есть 16 ГБ оперативной памяти, которые используются не полностью. Моей первой мыслью было дать базе данных как можно больше памяти, но я не уверен, как это сделать (это выделенный сервер базы данных).
Любое решение, которое не требует перезапуска, предпочтительнее, но я возьму то, что смогу получить на этом этапе.
Спасибо!
5 ответов
Параметр shared_buffers размером 24 МБ является консервативным по умолчанию, я бы сказал, что он должен быть намного выше для выделенной базы данных с 16 ГБ доступной оперативной памяти. Но да, вам придется перезапустить сервер, чтобы изменить его размер. http://wiki.postgresql.org/wiki/Performance_Optimization - это хорошее место для начала по настройке производительности. Установка shared_buffers на 4 ГБ или 6 ГБ может показаться более разумным.
Обратите внимание, что в linux вам нужно настроить параметр sysctl kernel.shmmax (в /etc/sysctl.conf или просто записав /proc/sys/kernel/shmmax), чтобы выделить блок этой разделяемой памяти. Если вы этого не сделаете, вы получите ошибку, указывающую, сколько было запрошено, вы должны установить kernel.shmmax выше, чем это.
Поскольку у вас много памяти, вы можете также рассмотреть возможность установки значения по умолчанию work_mem выше, что приведет к тому, что такие вещи, как сортировки и хэши (группа / порядок / отличные и т. Д.), Будут работать в памяти, а не использовать временные файлы. Вам не нужно перезагружать сервер, чтобы сделать это, просто обновите файл конфигурации, перезагрузите службу, и новые сеансы получат новый параметр. Рабочая память по умолчанию для сеанса составляет 1 МБ. Вы можете рассчитать максимум, который можно использовать за один раз, как work_mem * max_client_connections и оцените, какое влияние это окажет.
Вам также следует увеличитьффективный_кэш-размер, чтобы указать планировщику, что уровень FS ядра, вероятно, будет кэшировать много страниц в памяти вне общих буферов postgresql.
и т.п.
Помимо приведенных здесь советов, вы также можете посмотреть настройки автовакуума. По умолчанию он запускается примерно после 50 обновлений, и если ваша база данных выполняет много обновлений / вставок, это может вызвать ненужное количество пустых операторов, которые будут генерировать много операций ввода-вывода.
В системе, которая очень близка к максимальной пропускной способности ввода-вывода при нормальной работе, вы можете увеличить checkpoint_completion_target, чтобы уменьшить нагрузку ввода-вывода с контрольных точек. Недостатком этого является то, что продление контрольных точек влияет на время восстановления, поскольку необходимо будет хранить больше сегментов WAL для возможного использования при восстановлении.
Подробнее здесь.
Если diskio в postgresql очень велик, вы должны проверить выполняющиеся операторы, особенно для операторов, выполняющих "сортировку на диске", и установить правильные индексы.
Просто поищите в Google "Настройка производительности Postgresql", и вы найдете достаточно подсказок, с чего начать.