Коллеги такой вопрос. Знаю, что рекомендуется разносить на разные физические сервера СУБД и 1С Предприятие. Но вот если такой возможности нет, и сервер только один, то какая из следующих схем покажет максимальную производительность?
CentOS
-Сервер 1С Предприятие
-СУБД PostgreSQL
CentOS
-Контейнер
--Сервер 1С Предприятие
-Контейнер
--СУБД PostgreSQL
Proxmox/ESXi
-CentOS
--Сервер 1С Предприятие
-CentOS
--СУБД PostgreSQL
Может ещё какие варианты есть? Например в рамках одного физического сервера 1с Предприятие ставится на один диск, а СУБД на другой?
рекомендуется разносить на разные физические сервера СУБД и 1С Предприятие
15-17 лет назад это был вынужденный компромисс из-за значительной нехватки вычислительных ресурсов на одном экземпляре физического сервера(кол-во ядер, памяти, пропускной способности дисковых систем). Для того, чтобы хоть как-то сдвинулось с места когда все тормозит и виснет.
Первый вариант самый оптимальный для производительности.
Остальное - так же вынужденные компромиссы, когда чего-то не хватает. Денег, например.
Максимальную производительность показывает система с хорошим железом, правильно настроенная (буст, турбобуст, теплопакет, ...), с включенной схемой высокой производительность (cpufreq-set -c ALL -g performance). Любая прокладка снижает производительность, иногда давая что-то взамен (например, Proxmox дает возможность устроить бесперебойный кластер из ТРЕХ компов).
Если процессор старый, то можно юзать любую систему. Если процессор новый, то нужно юзать ту систему, ядре которой есть поддержка этого процессора. Т.е. в итоге все упрется в ядро, поддерживающее данный процессор, настройку BIOS, включение схемы высокой производительности. Дальше нужно будет настроить параметры постгреса для того, чтобы ему хватало памяти на большинство операций. Т.е. все эти майнтерайнс мем, шаред буфферс и т.д. Также есть нюанс с типом накопителя. Все эти скази-рейд-старые-УГ-шпиндельные системы можно выкинуть в корзину сразу. Для неоперативного бэкапа они, конечно, могут сгодиться, но не более. Оперативный бэкап надо держать на быстром диске.
Ну и любая виртуализация режет от половины производительности за счет того, что банально выпиливается часть кеша процессора на инфраструктуру даже "аппаратной" паравиртуализации. Плюс хост-система часто не настроена на высокую производительность, что еще раза в два-четыре снижает производительность, а гуэст-система этим не может управлять, т.к. она в контейнере.
СУБД на отдельном диске
Журналы вал - потоковая репликация - на другом диске
Бекапы - ещё один диск и архив в сейф начальника
Никакой виртуализации и контейнеров. Хотя , если хотите экстрим или потому, что модно - ваше право.
(5)Не-не, никакого экстрима, хочется спокойной и незатейливой работы. Так виртуалка могла бы помочь при зависании гостевой системы, а также легкого бэкапа системы целиком(ОС+1С+СУБД) со всеми настройками.
На какой диск ставить ОС, СУБД, БД, Бэкапы (оператив., неоператив.)
1. Система умеет 2хPCI-E 4?
2. Оперативный бэкап - это синк data кластера и репликация WAL-файлов. На любой отдельный диск из указанных.
3. Неоперативный бэкап - это ежедневные выгрузки кластера пробэкапом или чем-то аналогичным. pgdump - это не бэкап.
Систему можно и на Evo поставить. Данные разнести между дисками PCI-E 4 (отдельно логи, отдельно дата). Файловая система лучше всего для постгреса (по моим оценкам) - ext4. Она поддерживает и TRIM, что немаловажно для дисков SSD.
В остальном все упирается в проц. Видел конфиги на венде, которые даже на 12700kf в гилевском тесте показывают в районе 100, хотя у меня на линухе на 13600kf 185/192 для файловой. Память вообще никак не повлияла на производительность теста (DDR5 4800 vs DDR5 6400 никак не отразилась на показателях теста ни с базой на диске, ни с базой в оперативке), хотя скорость вычисления тех же regexp повысилась на 20-25%. Так что реальная работа и тест Гилева - это не совсем одно и то же.
В общем, с процом нужно:
1. Высокая производительность.
2. Турбобуст.
Я на своем 13600kf отключил HT и сделал андервольтинг до 1.175В, что снизило пиковые температуры в стресс-тесте с 83 до 63 градусов (на 20, КАРЛ, градусов!). При этом на показателях теста это не сказалось никак вообще. И даже на показателях гикбенча это никак не сказалось - как было 2162 в однопотоке и 14647 в многопотоке, так и осталось (с HT однопоток был 2060, многопоток до 17к+). Но температура упала на 20 градусов, что для работы 24х7 очень даже имеет смысл.
(8)у системы только два PCI-E 4
Получается такой расклад:
Win Server 2019, СУБД(MS SQL) и оперативные Бэки ставлю на SSD 500Gb Samsung 870 Evo
Файлы базы данных храню на одном 1000Gb Samsung 990 Pro
а Логи на другом 1000Gb Samsung 990 Pro
Неоперативный бэкап на отдельный не быстрый HDD
Так оптимально будет?
Про разгон проца - это пока следующим этапом, проц AMD Epyc 7643
(9) разгонять проц, особенно серверный, не нужно. Достаточно чтобы в BIOS была установлена возможность раьоты в турбобуст.
Также с серверными прцами очень важно, чтобы планок памяти ыло столько, сколько каналов памяти они поддерживают. Если проц имеет 6-ти канальный контроллерипамяти, а процов таких на мамку ставится ДВА, то планок памяти должно быть 12 штук. И вставлены они доожны быть по инструкции. В противном случае сервер не будет выдавать достаточное количество производительности, т.к. она упрется в память. А то есть отдельные товарищи, которые получают на серверном проце производительность уровня первопня, а потом рвут волосы оттого, что памяти у них там на два сокета две планки, как в игровых сборках. Ну и в итоге один проц раьотает с этой памятью в двухканал ном режиме с задержками 100+ нс, а второй проц с задержками 200+ нс, хотя даже игровые процы в двухканале имеют 50-70 нс в пределе.
Собрал...
Запускаю тест Гилева, если файловая база данных, то результат 92.59 баллов
Если MSSQL, то 32.26 баллов((
Это нормально, или судя по результатам СУБД неправильно настроена?