Я знаю, что более быстрые диски, чем те, которые я использую, помогут, но это займет больше времени, и я пытаюсь использовать некоторые экстренные меры для уменьшения дискового ввода-вывода. наверху почти постоянно сообщает об использовании 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 и оцените, какое влияние это окажет.
Вам также следует увеличить effective_cache_size, чтобы указать планировщику, что уровень FS ядра, скорее всего, будет кэшировать много страниц в памяти за пределами общих буферов postgresql.
и т.д. и т.п. надеюсь, что это даст вам хорошее начало.
Перемонтируйте диски с помощью noatime
Помимо приведенных здесь предложений, вы также можете изучить настройки автоматической вакцины. По умолчанию он срабатывает примерно после 50 обновлений, и если ваша база данных выполняет много обновлений / вставок, это может вызвать ненужное количество операторов вакуума, которые будут генерировать много операций ввода-вывода.
В системе, которая очень близка к максимальной пропускной способности ввода-вывода при нормальной работе, вы можете увеличить checkpoint_completion_target, чтобы уменьшить нагрузку на ввод-вывод с контрольных точек. Недостатком этого является то, что продление контрольных точек влияет на время восстановления, потому что для возможного использования при восстановлении необходимо будет хранить больше сегментов WAL.
Узнать больше Вот.
Если diskio postgresql очень велик, вы должны проверить выполняемые операторы, особенно для операторов, выполняющих «сортировку на диске», и установить правильные индексы.
Просто введите в Google строку «Настройка производительности Postgresql», и вы найдете достаточно информации, с которой можно начать.