|
Выбор сервера под PostgreSQL
|
|||
---|---|---|---|
#18+
Итак, наступл тот момент, когда было принято решение купить новую хост-машину. На хост-машину будем ставить виртуалку postgresql. На сейчас имеем один сервер БД и 130Гб данных, причём 100Гб - это одна таблица, к которой будет в будущем очень много длительных запросов (все данные на SSD 256Гб). Эта же таблица может однократно вырасти до 2-3Тб. Нагрузки на сервер - короткие частые сессии. Управляет ими PgBouncer. Запись производится редко, но много, что сильно нагружает файловую систему. Если верить Zabbix, то "iowait time">50%. На какие параметры обратить внимание при выборе сервера? Есть ли смысл покупать SSD на несколько терабайт или лучше собрать RAID 01 (или 10) из десятка HDD без потери производительности? На сколько я понял, PostgreSQL под одно подключение выделяет одно ядро. Если у меня 6 ядерный проц сейчас, то не желательно ставить количество возможных подключений больше 6? По поводу ОЗУ тоже всё неоднозначно. Одни советуют ставить work_mem и shared_buffer побольше, другие говорят о том, что не нужно ставить больше определённого значения. Интересна Ваша мысль. Бюджет - $3k-$5k, но нужна адекватная аргументация для менеджмента. Буду благодарен за любые советы. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2017, 17:59 |
|
Выбор сервера под PostgreSQL
|
|||
---|---|---|---|
#18+
chipakunos, Не надо продукционную базу в виртуалку ставить. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2017, 22:03 |
|
Выбор сервера под PostgreSQL
|
|||
---|---|---|---|
#18+
vyegorovchipakunos, Не надо продукционную базу в виртуалку ставить. сейчас можно. и виртуализация бывает разная и продуктивные БД тоже ) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2017, 22:22 |
|
Выбор сервера под PostgreSQL
|
|||
---|---|---|---|
#18+
chipakunos... Есть ли смысл покупать SSD на несколько терабайт или лучше собрать RAID 01 (или 10) из десятка HDD без потери производительности? ... книжки по устройству HDD читать не прибывали? в мое время, начало 90-х, про головки и прочее в школе рассказывали, на уроках информатики chipakunosНа сколько я понял, PostgreSQL под одно подключение выделяет одно ядро. Если у меня 6 ядерный проц сейчас, то не желательно ставить количество возможных подключений больше 6? жестоко chipakunosБюджет - $3k-$5k, но нужна адекватная аргументация для менеджмента. chipakunosпокупать SSD на несколько терабайт RAID 01 (или 10) из десятка HDD без потери производительности жестоко Даже не глядя в ценник, пара сотен баксов нормальный корпус... адаптек RAID вроде 300-500 долларов самый дешевый, жесткий диск SAS...тоже не мало, а вы их собрались десяток ставить про SSD не знаю, но мне кажется вещь тоже не дешевая + резервирование для серверов никто не отменял chipakunos... Запись производится редко, но много, что сильно нагружает файловую систему. ... "Бить будем аккуратно, но сильно" ( C ) chipakunosЕсли верить Zabbix, то "iowait time">50%. IO в базах данных бывает разное. Файлы данных, log'и... К тому же, AFAIK в PostgreSQL процесс сброса буферов на диск вроде достаточно хорошо тюнится, по крайне мере, параметров настроек уйма. Насколько они помогают в реальной жизни - не знаю. (с большой базой на PostgreSQL игрался, но это был не продакшен) chipakunosНа какие параметры обратить внимание при выборе сервера? Ну если сейчас не справляется ввод-вывод, то ответ очевиден Ну и разумеется, кроме "параметров при выборе сервера", хорошо бы еще озаботиться "параметрами настройки PostgreSQL" chipakunosПо поводу ОЗУ тоже всё неоднозначно. Одни советуют ставить work_mem и shared_buffer побольше, другие говорят о том, что не нужно ставить больше определённого значения. Интересна Ваша мысль. Если "советуют" - это статьи из I-net, то все действительно не понятно. "другие говорят о том, что не нужно ставить больше определённого значения" - мне встречалось, другая фраза "в предыдущих версиях PostgreSQL .... т.к. имелись проблемы" Но с другой стороны, все совсем "не так однозначно". Т.к. в отличие от Oracle, PostgreSQL всегда работает через кэш файловой системы. Т.ч., если с Oracle все ясно, Buffer Cache задираем до максимума без вопросов, то с PostgreSQL это уже "не так однозначно", т.к. не понятно, сколько памяти будет хотеть ОС под кэш. Ну и целая загадочная область, это "IO scheduler" в Linux. Статей масса, но лично мне, нифига ничего не понятно. Кроме того, что "default IO scheduler" для СУБД не подходит (в этом вроде все статьи в I-net совпадают) IMHO & AFAIK ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2017, 02:28 |
|
Выбор сервера под PostgreSQL
|
|||
---|---|---|---|
#18+
Leonid KudryavtsevНу и целая загадочная область, это "IO scheduler" в Linux. Статей масса, но лично мне, нифига ничего не понятно. Кроме того, что "default IO scheduler" для СУБД не подходит (в этом вроде все статьи в I-net совпадают) Что там загадочного-то? всего-то 4 планировщика: устаревший для виртуальных машин с низким throughput по-умолчанию ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2017, 03:50 |
|
Выбор сервера под PostgreSQL
|
|||
---|---|---|---|
#18+
не понятно какой когда и зачем нужен а самое главное, куда керосин наливать ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2017, 03:55 |
|
Выбор сервера под PostgreSQL
|
|||
---|---|---|---|
#18+
chipakunosБюджет - $3k-$5k, но нужна адекватная аргументация для менеджмента. посмотрел современные ценники, как и предполагал. явно речь идет не о брендовом сервере (он в эти деньги скорее всего не впишется), но и даже самосборный сервер, IMHO выбора будет не много пара серверных SSD (если в RAID-1) + взять пару десктопных винтов для хранения архивов/дистрибутивов/порнухи (куда же на сервере без нее?)... деньги и закончатся по личному опыту, примерно 15 летней давности, я сервер выбирал так: корпус ))) + мама память RAM ну и остальное, сколько осталось денег ))) в вашем случае, наверное и сложнее и проще. Т.к. фиг его знает, в какие серверные мамы, какие высокопроизводительные серверные (!!!) SSD можно поставить. Я бы определился с SSD, какой хочется, потом посмотрел на платформы, куда его можно поставить... думаю выбор будет не сильно большой. ну и RAM по максимуму, плюс тюнинг PostgreSQL Чисто теоретически, если RAM много и настройки нормальные, то кто кэширует запись на диск сам PostgreSQL или дисковая система (RAID контроллер) - разницы быть не должно. Если RAM достаточна, что бы сгладить пики "запись производится редко, но много", то wait из-за обращения к дискам быть не должно. IMHO & AFAIK Но это теоретически. Практически, баги и непонятностей в софте/доках дофига. Не все работает так, как должно было бы работать теоретически. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2017, 15:05 |
|
Выбор сервера под PostgreSQL
|
|||
---|---|---|---|
#18+
Всем спасибо за участие в теме. Удалось расширить бюджет до 10к и собрать норм сервер. 4xIntel Eight Core E5-4650 2.70GHz, 384GB DDR3(48x8GB), 2xPS , 6TB HDD, 8x2.5' Tray for HDD, PERC H710, Idrac Express, Intel 750 Series SSDPEDMW012T4X1 для мастера, подключён напрямую в виртуалку; Samsung 850 Pro series 1TB для реплики, подключён напрямую в виртулку, на этом же сервере и бэкапы хранятся на RAID 1 из HDD; vyegorovНе надо продукционную базу в виртуалку ставить. Подключил SSD напрямую в виртуалку и iowait упал до 2-3%, база летает. REINDEX на таблицу в 70 Гб за 5 минут. Сетевая карта у сервера с базой тоже отдельная, напрямую подключена в виртуалку. Пока проблем с базой в виртуалке нет (или я их не вижу). ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 20:30 |
|
Выбор сервера под PostgreSQL
|
|||
---|---|---|---|
#18+
Сила есть, ума не надо. :fail: Для 1С-ников нужно отдельный могильник топиков заводить ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 20:55 |
|
Выбор сервера под PostgreSQL
|
|||
---|---|---|---|
#18+
Siemargl, Если я Вас правильно понял, то лучше покупать железо впритык, а через год, когда нагрузки вырастут или допилится пара-тройка софта, или надо будет поднять ещё одну виртуалку с высокими нагрузками, то продавать старое железо и всё по новой? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2017, 18:25 |
|
|
start [/forum/topic.php?fid=53&tid=1996245]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
42ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
others: | 15ms |
total: | 157ms |
0 / 0 |