Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
ditok Member Откуда: Сообщений: 1 |
Добрый день! Имеем функционирующее корпоративное хранилище данных на виртуальной машине с выделенными 64 ядрами и экземпляром сервера MS SQL SERVER 2016 Enterprise. К производительности на данный момент вопросов нет. Но встал вопрос о закупке лицензий "Под ядро". Покупать на все уже выделенные на виртуалке ядра никто не позволит. Есть желание понять каково оптимальное число ядер для обеспечения нормальной производительности нашего КХД. Для этих целей хотим настроить счетчики и посмотреть их трасировку в пиковые нагрузки с различным числом ядер, выделенных виртуалке. Собственно вопрос: реален ли такой подход, какие счетчики лучше всего использовать? Или же можно как-то еще подойти к решению данной задачи? |
9 ноя 17, 14:27 [20940177] Ответить | Цитировать Сообщить модератору |
s_ustinov Member Откуда: Munchen, DE Сообщений: 2209 |
ditok, выбрать любое четное число от 2 до 64 (лицензия по 2 ядра), посчитать стоимость и показать эту сумму финдиру. Если ему станет совсем плохо - уменьшить число, если будет видно недоумение "чего вы ко мне с такой мелочью лезете" - увеличить число. Повторять итерации, пока финдиру не будет грустно, но терпимо. Потом в виртуальной машине уменьшить количество ядер до нужного числа и посмотреть, что будет. Если за пару недель никто ничего не заметит - покупать и не париться. Если начнут прибегать пользователи с претензией на тормоза - отправлять к финдиру - пусть доказывают, что очень нужно. А вообще, интересно почитать обоснование, зачем на хранилище данных именно Enterprise? Вы проверяли, что вам мало 24 ядра или 128 Гб оперативки? Если проверяли - то просто повторите те же тесты. Если не проверяли... Значит оно вам и не надо, а алгоритм действий написал выше ![]() |
9 ноя 17, 15:08 [20940416] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31782 |
И когда деньги уже выделены, просьба увеличить вызовет скандал и слетание голов.
А потом лимитировать ядра в виртуалке (или в настройках сиквела) и посмотреть, как работает. |
||||
9 ноя 17, 16:49 [20940757] Ответить | Цитировать Сообщить модератору |
Критик Member Откуда: Москва / Калуга Сообщений: 34749 Блог |
ditok, есть возможность постепенно уменьшать количество выделенных ядер? если да, то пробуйте + запланировать переезд с ВМ на отдельную железку |
9 ноя 17, 18:19 [20941053] Ответить | Цитировать Сообщить модератору |
iii2 Member Откуда: Сообщений: 202 |
Господитыжбожемой! Поставьте триал, и изнасилуйте его. 180 дней на тесты не хватит что ли? А вообще, критерий: Меньшее из 2х - 1. Максимум суммы, который готов заплатить финотдел и 2. Увеличение количества ядер вдвое сокращает рутинным отчетам время генерации менее, чем на 10% (для хранилищ) [значит берем предыдущее колво ядер], или средняя загрузка процессоров в течение операционного дня колеблется в районе 60% (для oltp) [как достигли - всё, что больше, в общем, пустая трата денег]. Всё ИМХО, разумеется. |
10 ноя 17, 23:07 [20945112] Ответить | Цитировать Сообщить модератору |
Alex_496 Member [заблокирован] Откуда: https://www.dvbi.ru Сообщений: 3869 |
Как руководитель Планово-экономической службы (в прошлом) я бы рекомендовал Главному инженеру предприятия уволить Вас за такой "экспертный" подход. ditok, могу предположить, что 64 ядер перебор, их всех еще надо суметь загрузить работой по полной, и чтобы дисковая подсистема не затыкалась от задач всех этих ядер. Лучше, лучше оперативную память наращивать. |
||
10 ноя 17, 23:16 [20945125] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31782 |
Вот это непрофессионально, давать приговор ядрам, абсолютно ничего не зная про систему.. А ограничить ядра и посмотреть - это как раз нормальный подход, потому что никакими счётчиками и вычислениями поведение реальной системы и комфорт пользователей не рассчитаешь. |
||
11 ноя 17, 00:22 [20945210] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37155 |
Сообщение было отредактировано: 11 ноя 17, 01:14 |
||
11 ноя 17, 01:10 [20945241] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
А хранилище будет выдавать отчеты пользователям службой SSRS на той же виртуальной машине (мало ли после загрузки данных и формирования агрегированных таблиц нужно будет шедулером по почте рассылать PDF/Excel со свежими цифрами, вот озадачит руководство прикручиванием KPI по продажам или оборачиваемости, если такое можно посчитать в этом хранилище)? Или только сам SQL и SSIS? А если Вы захотите еще и Tabular SSAS собрать там же? Я бы отталкивался от того, что заранее обсудил, что будет из задач на инстансе - если захотят все и сразу, тогда выбивать лицензии одним пакетом. Потому как один раз протащить в бюджет большие деньги это одно, а половину и потом еще раз половину - могут зарезать или перенести на бюджет в следующем году. |
||
11 ноя 17, 01:58 [20945259] Ответить | Цитировать Сообщить модератору |
s_ustinov Member Откуда: Munchen, DE Сообщений: 2209 |
Как хорошо, что у большинства моих коллег с юмором все в порядке. ![]() |
||
11 ноя 17, 19:09 [20945980] Ответить | Цитировать Сообщить модератору |
s_ustinov Member Откуда: Munchen, DE Сообщений: 2209 |
А потом ВНЕЗАПНО окажется, что база на сотню гигабайт ![]() А тут - Enterprise Edition, 64 ядра... |
||
11 ноя 17, 23:09 [20946319] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
Технически счетчики смотреть по загрузке CPU - по-моему с октября 2007 принципиально ничего не поменялось, когда на технете выложили подробную статью. Подробно, наглядно, но мнению Зака я бы доверять на 100% не стал, таки он не MVP был, а простой DBA в Levi Strauss на тот момент. |
||
11 ноя 17, 23:42 [20946359] Ответить | Цитировать Сообщить модератору |
KRS544 Member Откуда: Сообщений: 497 |
Ну как минимум сжатие таблиц и online построение индексов... |
||
13 ноя 17, 19:30 [20950691] Ответить | Цитировать Сообщить модератору |
Критик Member Откуда: Москва / Калуга Сообщений: 34749 Блог |
KRS544, сжатие и SE поддерживает, начиная с 2016 SP1 https://docs.microsoft.com/ru-ru/sql/sql-server/editions-and-components-of-sql-server-2016 |
13 ноя 17, 20:15 [20950781] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |