Комментарии 19
Итого только на 10 серверах мы сэкономили на CPU и RAM 284 640 рублей за год!
Что-то я в упор не вижу, как именно вы это сэкономили... Сэкономили - это в исходном состоянии потратили бы миллион за год, а в новом потратили только полмиллиона... с учётом всех связанных и зависимых расходов.
Были 10 виртуалок на хосте, осталось 10 виртуалок на хосте, сервер жрёт энергии практически столько же, обслуживания требует столько же... где экономия?
Были 10 виртуалок на 2 хостах, стало 10 виртуалок на 1 хосте, сервер жрёт энергии вдвое меньше, обслуживания требует вдвое меньше... но если посчитать реально сэкономленное в рублях, думаю, получится куда как меньше заявленного.
Пример был реализован на 10 серверах. В нашем парке их намного больше, и раскрыть более подробно не представляется возможным, так делать можно и нужно
Да не в том проблема. Я о том, что вы насчитали там немеряные миллиарды - а сколько вы получили реальной экономии/, на сколько снизили живые затраты? сколько у вас получилось по итогу экономии в рублях, подсчитанной булгахтерами?
Не, не надо абсолютной цифири, но укажите долю реальной экономии от вами посчитанной. Если она вообще есть...
Сэкономили 30тр в месяц, а сколько потеряли за счет снижения эфективности работы пользователей? Уверяю, что гораздо больше... ЗП одного хомячка в офисе раза в 3 выше....
Кроме того Вы получили риски уйти в жесткий отказ в случае пиковых нагрузок (а такие нагрузки как правило периодические, например начали считать зп в 1с).
Ну и на сладкое как всегда риски ухода памяти в своп и отказ сервиса. Много раз видел при подобных оптимизациях.
честно не понял какая может быть дефрагментация в век когда везде ставят SSD...
про докеры - они ну точно не про оптимизацию ресурсов, они про унивесальность. хотя если сравнивать выделение отдельной ВМ с докером, то конечно докер жрет меньше
а вот про динамическое выделение ресурсов могли-бы и поподробнее написать
Из личного опыта:
если оперативки занято 80% или ЦП сумарно загружен на 80% - надо СРОЧНО бежать в магазин докупать ресурсы...
Кто-то кривит душой.
На первом графике (ДО) мы видим явно эпизодическую загрузку, cron или еще что-то такое. Прилетело, отработало.
На втором графике загрузка, с небольшими флуктуациями, равномерная без каких-либо прыжков.
Поменялся не график нагрузки, а профиль нагрузки.
Необходимо также учесть в расходах трудозатраты на разработку скриптов для очистки данных и мониторинга системы. Эти затраты следует выразить в человеко-часах.
Учитывать объем памяти, расходуемой на кэш в Windows-системах, особенно на серверных версиях, представляется весьма сложной задачей.
А ещё, когда cpu 100% что происходит с латентностью? 40% загрузки CPU - это как раз граница, когда пользователи начинают замечать ухудшение латентности и увеличение длительности выполнения опреаций, например проводок в 1С.
Тоже удивило явное несоответствие профилей нагрузки!
А ещё урезание ресурсов CPU до почти 100%-й загрузки - это вообще трэшь
Второе, очень удачно выбрано число 40% (как верхнюю границу), что позволяет порезать ресурсы вдвое, и получить нагрузку не более 80%.
И вроде бы хорошо, есть операционный запас в 25%, но тут нужно спросить себя:
1) какой у нас профиль нагрузки в первых или последних числах месяца
2) в начале или в конце квартала
3) в начале или в конце года
---
4) по праздникам и прочим ивентам.
У нас был смешной случай, начались оптимизации, порезали вдвое, стало с пиками до 80%, вроде бы ок.
Потом отделу маркетинга дали несколько миллионов инвалюты, они эту инвалюту удачно пристроили в разные каналы, а чтобы было интереснее - замутили конкурс с конкретного числа и времени, пришла нагрузка, и сервера немного приуныли.
Еще бывает веселее, когда до тебя в софте наговнокодили овер9000 threadов. И ты отнимаешь у джоб сервера 20 ядер, оставляя два, а софт наяинает срать эррорами и отваливаться. Потом что олени решили, что если я concurrent threadов нахерачу под 74473728364 - будет точно быстрее. Настодько быстрее, что с 2 ядрами и нормальным кол-вом threadов в конфиге выполнялся на 30% дольше, чем с 20 vcpu и овер9000 тредов. Тестить? Да зачееееем!
Главная причина оптимизации - это снижение cpuReady, cpuWait и coStop. (Или cpu wait time per dispatch, если другой гипервизор). То есть оптимизация своего гипервизора скорее и снижение сотношения pCPU:vCPU. Урезание жирных соседей, их шар/квот и их weightинга, чтобы они не мешали всем соседям. Раеример жирные вмки >8ядер порождают ректальную боль любому планировщику гипервизора в попытках освободить такт для такого жира.
Урезать ресурсы в 0 - ну такое. При максимальной загрузке резерв должен оставаться хотя бы 10-30% процентов для спайков вроде: ардейты начали отжимать 1 ядро. Антивирь запустил ежедневный скан. И прочее.
С рамой так вообще: начнем с того, что многие мониторинги неправильно показывают числа. Что считаем? Виртуальную память? Физическую память? С учетом кэша или нет? Плюс: чем больше свободный рамы, тем больше возможности мапить файлы в рам и читать их из рамы. Для многого - это мастхэв. Файл сервер например.
Динамические ресурсы в большинстве своем ломают NUMA. И виртуалки ложатся на физ цпу криво. В итоге нума интерконнект и все последствия. Плюс базы крайне не любят не статику.
Большинство нормальных админов ресурсы вмке дают столько, сколько просит софт согласно вайтпеперу, чтобы потом иметь возможность написать в суппорт и не быть отфутболенным: "сделайте согласно рекомендациям"
Мда, кейс напоминает что-то из моего рабочего пространства.
Пробовал много раз подойти к начальству, но не то постоянно ответ - нет. Покажу статью, может поймут:)
Инициатива...наказуема...
Вот по жизни на твои личные рвения помочьи оптимизировать. всем ПЛЕВАТЬ. В лучшем случае плечами пожмут... кто то у виска покрутить может, спасибо если не в лицо. А в самом лучшем случае, сэкономив может даже миллионы тебе просто скажут спасибо или похлопают по плечу....
Зато вот если что-то сломается...или будет плохо работать... тут уж реальные и финаносвые проблемы полезут 100% - у тебя. как у инициатора =) так что если вы не владелец всего парка в 100500 серверов(как вы и скзали)) дело это неблагодарное... ТОЛЬКО когда сами обратятся. только когда совсем плохо дело.
P.s. Уважаю!
Для таких мамкиных экономистов заготовлен отдельный кабинет...
Короче, какой-то ITшник все настроил, все прекрасно работало. Но пришли цыгане и показали директору красивую брошюрку с цифрами о "теоретической экономии". Конечно директор возбудится он "халявной экономии". А ITшника скорее всего даже не спросят о причине такого расходования ресурсов, либо он окажется слишком костноязычным, чтобы презентовать свое решение. После "оптимизации" цыгане свалят в закат, а этот директор останется расхлебывать падение серверов от ddos из-за отсутствия резервных мощностей, отсутствие резервирования ресурсов на случай "смерти" одного из серверов.
Оптимизация ресурсов виртуальных машин: как сэкономить бюджет и не потерять производительность