У нас есть «веб-приложение» django (из ада), которое мы размещаем на выделенном сервере. После некоторого тестирования я обнаружил, что «Приложение» на удивление плохо справляется с операциями с базой данных (в настоящее время рефакторинг недоступен). Он порождает безбожное количество операций чтения и записи. Прямо сейчас мы получаем еще один (второй) выделенный сервер для повышения производительности и небольшого количества аварийного резервирования. Обе машины имеют 24 ядра (Intel (R) Xeon (R) CPU E5645 @ 2,40 ГГц) и 48 ГБ оперативной памяти (также есть Raid 10, 6 x 150 ГБ 15 КБ).
Мне было интересно, как мы можем улучшить настройку.
(мы тем временем переписываем приложение надлежащим образом, но получение текущего - дерьмового - одного, работающего немного быстрее, жизненно важно, нам нужно, чтобы оно продержалось с увеличением трафика по крайней мере в течение следующих 3 месяцев ...)
Не могли бы вы посоветовать немного улучшить настройку? С упором на подготовку структуры машины базы данных для смехотворно неэффективного приложения из ада.
Некоторые базовые советы по производительности БД на уровне ОС:
Имейте больше оперативной памяти, чем вы думаете, что с ней делать.
Если вы можете поместить весь запрос в ОЗУ или, по крайней мере, сохранить данные в базе данных или в кеше ОС, ваша производительность значительно улучшится.
Потратьте деньги на быстрый диск и хороший RAID-контроллер.
RAID 10, если вы можете его получить, и с резервным аккумулятором на контроллере RAID, чтобы вы могли в полной мере использовать кэширование записи.
Настройте параметры сервера Postgres
(В ответе Халеда есть ссылка на вики-страницу Postgres по настройке)
Воспользуйтесь преимуществами ведомых устройств только для чтения
Если вы используете Postgres 9.x, у вас могут быть подчиненные серверы только для чтения. Разгрузите подчиненным серверам некоторую работу с интенсивным чтением (например, создание отчетов), чтобы ваша основная база данных не была занята этим, когда вы пытаетесь делать обновления.
никогда никогда никогда НИКОГДА виртуализировать производственный сервер базы данных
Почти никогда. Виртуализация сервера БД убивает производительность.
Для конкретных советов по БД вы можете проверить dba.SE - Огромный прирост производительности может быть достигнут за счет правильного индексирования и разработки запросов.
Мне всегда говорили - хотя у меня нет опыта с этим - что для оптимальной скорости базы данных вы должны запустить демон базы данных на голом железе (а не в виртуальной машине) на массиве RAID10. Насколько я понимаю, RAID1 + LVM в этом случае считается RAID10 и загружает RAM. ВМ будут съедать доступную вам оперативную память
Также я не уверен, что будет делать хорошая балансировка нагрузки перед виртуальными машинами на одном физическом сервере (хотя, возможно, я совершенно ошибаюсь в этом).
Есть несколько вещей, которые можно сделать, чтобы улучшить производительность сервера БД. Вот некоторые:
Максимально оптимизируйте свои запросы.
Устанавливать log_min_duration_statement в вашем файле конфигурации Postgres до того, что вы считаете границей приемлемой скорости, а затем атакуйте медленные запросы с помощью EXPLAIN чтобы узнать, почему они медленные.
Настройте параметры вашего сервера postgresql. Ты можешь найти ресурсы в сети о том, как это сделать.
Если применимо, разделите службы на разные машины.
Это не только хорошо для производительности, но и для безопасности.
Создайте необходимый индекс (-ы) в таблице (-ах) БД, чтобы ускорить запросы.
Результат EXPLAIN из (1) выше, вероятно, поможет вам