Как можно оценить требования к количеству ядер на существующем SQL Server? Стоит задача обновить его, но учитывая стоимость Enterprise-редакции хотелось бы знать сколько лицензий реально необходимо.
Я пытался прикинуть через среднюю загрузку процессора по логам Zabbix, но это довольно грубая оценка получается. Может есть более правильный метод?
ЗЫ. Если потребуется сервер будет виртуализован с нужным количеством ядер.
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте.
S>Как можно оценить требования к количеству ядер на существующем SQL Server? Стоит задача обновить его, но учитывая стоимость Enterprise-редакции хотелось бы знать сколько лицензий реально необходимо.
S>Я пытался прикинуть через среднюю загрузку процессора по логам Zabbix, но это довольно грубая оценка получается. Может есть более правильный метод?
S>ЗЫ. Если потребуется сервер будет виртуализован с нужным количеством ядер.
Если сервер уже существует, то прикидываете рост системы. И покупаете лицензию на то что есть + закладываетесь на рост. Или можете вообще погонять триалку и посмотреть разницу между текущей версией и новой.
Здравствуйте, BlackEric, Вы писали:
BE>Если сервер уже существует, то прикидываете рост системы. И покупаете лицензию на то что есть + закладываетесь на рост. Или можете вообще погонять триалку и посмотреть разницу между текущей версией и новой.
Сервер сейчас как раз гоняется в триальном режиме. Проблема в том, что сервер очень большой и полностью лицензировать его будет стоить довольно дорого. Поэтому нужно оценить насколько текущие задачи нагружают систему и во сколько ядер можно упаковать его без заметного падения производительности.
Здравствуйте, Somescout, Вы писали:
S>Сервер сейчас как раз гоняется в триальном режиме. Проблема в том, что сервер очень большой и полностью лицензировать его будет стоить довольно дорого. Поэтому нужно оценить насколько текущие задачи нагружают систему и во сколько ядер можно упаковать его без заметного падения производительности.
Так упаковывайте уже сейчас, последовательными приближениями найдете оптимум.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Ну грубо если — меряешь cpu time процесаа sqlserver за неделю
Делишь на 7 — вот тебе raw core count с учетом всей технологической нагрузки, если они будут загружены на 100%
Я бы помножил это на 4 (потому что пики днем и запас на будущее)
Потом берешь и выставляешь афаинити маск на нужное кол-во, и экспериментально проверяешь, достаточно ли производительности запросов при таком ограничении.
P.S: надо понимать что это вообще говоря дает нехилый разброс во времени исполнения однотипных запросов, см теорию массового обслуживания
если нужна стабильность, то целевая загрука CPU должна быть ~15%, и множить там нужно нифига не на 4
