Настройка высокой производительности PostgreSQL

• Хорошо, давайте начнем. Используемый сервер базы данных и приложений не должен менять местами. Теперь я понимаю, что «подкачка не используется, например, части ядра и т. Д.», Но пространство подкачки 64 ГБ - это нелепо. Нет НИКАКОГО способа, которым компьютер может использовать это разумным образом с приличной скоростью. Слишком долго. Сократите это. Существенный. ОЧЕНЬ знаменательно. Вроде 8 ГБ или около того. Может быть, 12 или 16. Но просто нет возможности даже удаленно использовать те 64 ГБ, которые вы сейчас назначаете.

• Надеюсь, вашему серверу придется много делать с точки зрения вычислений, потому что, хотя это и не жалко, это НЕ высокопроизводительный сервер базы данных. Плохие новости. ДЕЙСТВИТЕЛЬНО плохие новости. Один рейд 10 на все общие вещи - не лучшая идея. Но 6 дисков - это НЕ высокая производительность 15к или нет. У меня здесь меньший сервер db, на котором 6 дисков в RAID 10 только для данных. Что бы вы ни делали, с точки зрения транзакций, вы снова будете ограничены производительностью диска, если вы не сделаете OLAP. Дисковая подсистема никак не может запихнуть ОДИН 12-ядерный процессор, 4 из них абсолютно невозможно. В большинстве случаев одно 4-ядерное устройство может перегружать диски. На самом деле, лучше займитесь вычислениями.

Предложения:

• Добавьте еще один SSD для журналов. Это очень быстро и имеет очень быстрое время отклика. База данных должна записать изменения на диск как можно скорее, и это в некоторых случаях «списывается и очищается».

• Убедитесь, что вам нужно то, что вы покупаете. Я знаю, что Java может потреблять много ресурсов, но в этих измерениях? Вам ДЕЙСТВИТЕЛЬНО нужно 48 ядер? С этим справляется Centos? Linux DID имеет проблемы со слишком большим количеством ядер. Я знаю, что эти времена в основном прошли, но 48 ядер могут быть довольно трудными. Мне очень нравятся мощные серверы, но когда я обычно работаю с базами данных, их размер составляет 4 цифры вверх (1000 + ГБ), а дисковая подсистема имеет минимум 10, часто более 1000 дисков, чтобы прокормить этого монстра с необходимым бюджетом ввода-вывода. ИЛИ серверы предназначены для виртуализации.

• Возможно, добавить больше оперативной памяти. 32 ГБ звучат впечатляюще, но для 48 ядер это, на мой взгляд, немного невысоко. Я предпочитаю использовать минимум 1-2 гигабайта НА ЯДРО.

• Если вы выберете AMD, не забудьте разделить модули между процессорами;)

Разделение одного большого тома RAID10 на несколько разделов не дает ничего полезного. Шаблоны использования дисков ОС, WAL и дисков базы данных достаточно различаются, чтобы их можно было разместить отдельно. диски делает PostgreSQL быстрее. Например, WAL - это все последовательные записи, поэтому наличие выделенного диска для этого может помочь с рядом вещей. Отдельные разделы на одном и том же большом томе диска не улучшают производительность одинаково.

В конечном счете, это не имеет значения, когда ваш набор данных настолько мал по сравнению с объемом оперативной памяти на вашем сервере. Для этого вам вообще не нужна высокопроизводительная установка диска, нужны только быстрые процессоры и оперативная память.

Единственное, о чем вы не упомянули, - это какой RAID-контроллер вы используете и есть ли у вас батарея для резервного копирования кеша. Это гораздо важнее, чем мелочи по разделам. Видеть Надежные записи ссылки на дополнительную информацию можно найти здесь.

• ++ что написал TomTom.
• IIRC причина для отдельных разделов для data / xlog / OS состоит в том, чтобы разместить их на разных наборах шпинделей - я не понимаю, как их всех на одном наборе RAID можно добиться.
• Хотя PostgreSQL неплохо масштабируется на несколько ядер, 48 кажется излишним.
• Еще есть скорость ядер. Из того, что я видел: чем больше количество ядер, тем медленнее работают отдельные ядра - вам может быть лучше обслуживать меньшее количество ядер, но быстрее.

Есть книга, PostgreSQL 9.0 Высокая производительность это очень хорошо описывает все тонкости высокопроизводительного PostgreSQL.

Стандартный ответ производительности - «протестируй и посмотри». Итак, если вы можете попробовать несколько разных конфигураций под нагрузкой и посмотреть, какая из них лучше для вашей нагрузки с вашими данными это будет «правильная» конфигурация.

С базой данных 20 ГБ вы можете поместить (почти) всю базу данных в кеш файловой системы и / или буферный кеш Postgresql. У вас может не быть даже такого количества физических операций ввода-вывода, когда сервер прогреется.

Возможно, хорошее место для начала - создать 2-х дисковое зеркало RAID 1 для ОС и использовать остальные 6 дисков в массиве RAID 10 для pgdata + swap. Пока у вас нет данных для резервного копирования, я не вижу необходимости разделять xlogs и pgdata. Эта настройка, по крайней мере, позволит вам переместить журнал на зеркальный диск, если вам действительно нужно.

То же самое и с вариантами крепления. noatime - почти всегда хорошая идея, но все остальное я бы оставил в покое, пока оно вам не понадобится.

Одна вещь, на которую следует обратить внимание в CentOS / RHEL, - это LVM. Вероятно, стоит задать еще один вопрос, но я никогда не использую LVM и вместо этого создаю простые разделы ext3. (Я очень надеюсь, что вы имели в виду аппаратный RAID для ваших дисков, а не LVM RAID)

Базы данных обычно связаны с вводом-выводом. Ничего не зная о вашем конкретном приложении, я бы отказался от трех процессоров и посмотрел на получение карты Fusion IO (или, возможно, SSD) для раздела pgdata.

Я бы также настроил RAID немного иначе. Шаблон использования xlog (последовательный) обычно будет отличаться от раздела pgdata (random). По этой причине я бы предложил разместить их на отдельных физических устройствах.