Pull to refresh

Ошибки квантования времени в виртуальных машинах

Reading time3 min
Views10K
Вступление

Проводя работу по изучению производительности разных задач в виртуальных машинах, я использовал старый проверенный метод для количественного осмысления полученных результатов, а именно бенчмарки. Многие из них довольно хорошо себя зарекомендовали ранее, плюс даже пару своих написал на волне энтузиазма. Собрав уже неплохую статистику, не сильно сомневаясь в полученных результатах, на одном из тестов я случайно заметил, что затраченное на задачу время, о котором радостно отрапортовала программа, в несколько раз больше того, сколько я ждал этого результата. Повторные замеры с секундомером подтвердили мои наблюдения: да, время в виртуальной машине может идти не так, как мы ожидаем. За подробностями и чем нам это грозит прошу под хаброкат.

Суть

Все ниже описываемое проводилось в Windows 2008 Server R2 со всеми актуальными обновлениями и пакетами интеграции как на хост машине так и на виртуалке. Гипервизором являлся Hyper-V.

Суть проблемы: если в свойствах у виртуальной машины не стоит в пакетах интеграции синхронизация времени(а это иногда настоятельно рекомендуют делать, пример), то возможны ошибки квантования времени в зависимости от нагрузки на железо.
Как это наглядно проверить? Отдайте виртуальной машине 5% от одного ядра при отключенной в свойствах синхронизации времени. Запустите в ней любой бенчмарк, загружающий ЦП, я использовал SuperPi. Мало того, что сразу заметна разница в результатах- программа заявляла о 18 секундах на выполнение, реально я ждал более 10 минут, так и если открыть часы в области уведомлений видно, что секундная стрелка движется в несколько раз медленнее, чем в той реальности, к которой мы все так привыкли.
От чего зависит размер ошибки? От выделенных виртуальной машине ресурсов и загруженности хост машины. Чем меньше выделено ресурсов и чем более загружена виртуалка и/или хост машина, тем ошибка будет больше.

Чем это грозит?
  • Замеряя производительность подобной виртуальной машины можно получить прошлогоднюю температуру на южном полюсе Марса, а не объективные данные
  • Время на виртуальной машине может начать значительно отставать, что для некоторых сервисов и служб может быть критичным
  • Рассчитанное время на выполнение каких-либо задач и сервисов может разойтись с реально полученными результатами
  • В данном пункте не уверен(другие гипервизоры не мучал), но теоретически может сложиться ситуация, когда на облачном хостинге внутренние замеры использования ресурсов могут разойтись с предъявленными хостером
  • И т.д, и т.п.
Как еще можно использовать эти знания?

Например, можно на хостинге понять что стало причиной тормозов в работе сервисов. Для этого нужно изначально провести замеры каким- либо бенчмарком и сохранить результаты выданной программой и замеренных секундомером(все сервисы на время тестов должны быть отключены для точности измерений). При появлении подозрительных задержек можно провести аналогичный тест еще раз. Полученные варианты можно интерпретировать так:
  1. Время показанное бенчмарком и секундомером не изменилось (+-погрешность) — виноваты ваши сервисы или нагрузка на них со стороны клиентов
  2. Время показанное бенчмарком не изменилось, замеренное секундомером выросло — вашу виртуальную машину урезал в ресурсах хостер или выросла нагрузка на хост-машину и вам попросту не хватает ресурсов
  3. Время показанное бенчмарком выросло — все равно, что покажет секундомер, т.к. тут и так понятно, что вашу виртуальную машину урезали в ресурсах или выросла нагрузка на хост-машину
Вместо заключения

Такая вот сказка о потерянном времени. Напоследок хотелось бы еще поделиться ссылкой для заинтересовавшихся этим вопросом, которую дали специалисты из Microsoft в ходе обсуждения данной темы.
Tags:
Hubs:
+25
Comments14

Articles

Change theme settings