Комментарии 10
Удачи с виртуалками… Эх…
Поясню комментарий: в виртуализированной среде зачастую очень сложно отлаживать проблемы производительности из-за многих факторов:
1. Недоступность многих метрик производительности (в том числе наверняка cpu throttle не пробрасывается)
2. «Шумные соседи» могут, к примеру, вымывать кеш процессора, повышая CPU usage в вашей системе, но при этом суммарно ресурсов будет всем хватать
3. Практически всегда отсутствие возможности посмотреть метрики хостовой системы
При этом, я не утверждаю, что виртуализация вредна, но такие проблемы до сих пор никто не решил по-человечески, и вряд ли Azure или Amazon их тоже как-то прямо очень хорошо решают, к сожалению (хотя мне ни разу не удавалось их уличить в overprovisioning'е).
1. Недоступность многих метрик производительности (в том числе наверняка cpu throttle не пробрасывается)
2. «Шумные соседи» могут, к примеру, вымывать кеш процессора, повышая CPU usage в вашей системе, но при этом суммарно ресурсов будет всем хватать
3. Практически всегда отсутствие возможности посмотреть метрики хостовой системы
При этом, я не утверждаю, что виртуализация вредна, но такие проблемы до сих пор никто не решил по-человечески, и вряд ли Azure или Amazon их тоже как-то прямо очень хорошо решают, к сожалению (хотя мне ни разу не удавалось их уличить в overprovisioning'е).
- Ну да, если гипервизор вне контроля, нам приходится доверять провайдеру, тут особо ничего не придумать.
- Насколько я понимаю, если виртуалка свою память выделила, то кэш ей уже никто вымыть не может, это скорее о процессах/контейнерах без лимитов памяти. С точки зрения гипервизора виртуалка это процесс (по крайней мере в kvm так), отобрать у него память вроде никак нельзя, а то что pagecache внутри виртуалки, для гипервизора просто used.
- Да, это боль, но с другой стороны мы же хотели абстракции над железом — это оно и есть:)
Ну, справедливости ради, серьёзные хостеры и провайдеры vps не занимаются, как правилом, ощутимым оверселлом. Думаю, они закладывают некоторый запас от полного исчерпания ресурсов. Это же не какие-нибудь супербюджетные вутхостинг и альфарэкс с OVZ cерверами 1cpu/1GB/40Gb/100Mbps за $10 в год. Удовлетворённость клиента для крупных провайдеров уже не на последнем месте, ибо это имидж и будущие подписки.
А из-за чего температура выросла в итоге?
Именно из-за сложности выбрать хороший порог для триггера, многие инженеры мечтают о детекторе аномалий, который без настроек сам найдет то, не знаю что :)
Попробуйте мониторинг настроить при помощи карт Шухарта. Метод известен довольно давно (с 1924 года). С тех пор очень хорошо себя зарекомендовал. И эти карты просто просятся для применения в мониторинге ЦОД-а.
Критерии можно взять из ГОСТ Р 50779.42-99. А можно из какой нибудь книги по статистическому управлению. Вот с подбором размера партии придется помучиться, это да.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простые метрики и способ сэкономить время при поиске проблем в инфраструктуре