Postgres DISK IO очень высокий. Что я могу сделать, чтобы уменьшить это немедленно?

Я знаю, что более быстрые диски, чем то, что я использую, помогут, но это займет больше времени, и я пытаюсь использовать некоторые экстренные меры для уменьшения дискового ввода-вывода. поверх постоянно сообщает об использовании DSK на красной. Это для postgres 8.3.

Моя настройка shared_buffers составляет 24 МБ, хотя на сервере есть 16 ГБ оперативной памяти, которые используются не полностью. Моей первой мыслью было дать базе данных как можно больше памяти, но я не уверен, как это сделать (это выделенный сервер базы данных).

Любое решение, которое не требует перезагрузки, предпочтительнее, но я возьму то, что смогу получить в этот момент.

Благодарность!

Параметр 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.

и т. д. и т. д. надеюсь, что это поможет вам хорошо начать

Переустановите диски с noatime

Помимо предложений, приведенных здесь, вы также можете посмотреть в настройках автовакуума. По умолчанию он запускается примерно после 50 обновлений, и, если ваша база данных выполняет много обновлений / вставок, это может вызвать ненужное количество пустых операторов, которые будут генерировать много операций ввода-вывода.

В системе, которая очень близка к максимальной пропускной способности ввода-вывода при нормальной работе, вы можете увеличить checkpoint_completion_target, чтобы уменьшить нагрузку ввода-вывода с контрольных точек . Недостатком этого является то, что продление контрольных точек влияет на время восстановления, поскольку необходимо будет хранить больше сегментов WAL для возможного использования при восстановлении.

Подробнее здесь .

Если diskio в postgresql очень высокий, вы должны проверить выполняющиеся операторы, особенно для операторов, выполняющих «сортировку на диске», и установить правильные индексы.

Просто поищите в Google «Настройка производительности Postgresql», и вы найдете достаточно подсказок, с чего начать.