хостинг

CPU steal time на виртуальном сервере, мониторинг и перцентили

Оказывается, на виртуальных серверах есть специальная метрика CPU steal time. Она показывает, сколько процессорного времени было «украдено» у вашего сервера другими виртуальными машинами на том же физическом сервере. Есть смысл проверить эту метрику, если вы сталкиваетесь с необъяснимыми подтормаживаниями. Их причина может быть не в вашей системе, а в соседях по серверу.

Я периодически сталкиваюсь с этой проблемой на моем хостинге. Она проявляется в том, что изредка база данных обрабатывает запросы в десятки раз медленнее, чем обычно. Отследить такую ситуацию без специальных инструментов почти невозможно, потому что просто ходя по сайту, вы либо не заметите, что на двадцатый раз страница открывалась дольше, либо не поймете причину. Я использую New relic, о чем уже писал.

Изучая статистику после долгого перерыва, опять заметил, что проблема вернулась. Рассмотрел график из нью-релика с использованным и «украденным» процессорным временем. На нем видно, что 9 декабря появился заметный CPU steal time. Кто-то из соседей по физическому серверу стал активно нагружать процессор.

Казалось бы, величина не сильно большая: steal time не превосходит полпроцента, в то время как собственное потребление виртуалки около 5%. Но надо помнить, что это средние значения. Мгновенные значения в отдельные моменты времени могут оказаться гораздо больше. Чтобы их оценить, нужно смотреть на графики перцентилей.

На втором графике я вывел 95-ю и 99-ю перцентили времени ответа сервера при генерации страниц блога. Перцентили вычисляются из детальной статистики, а ее нью-релик хранит только последние 8 дней, так что сейчас уже никак не узнаешь, что происходило в районе 9 декабря. Когда я обнаружил проблему, среднее и медианное время генерации были около 30 миллисекунд, а 99-я перцентиль — около 190 миллисекунд (это значит, что каждый сотый запрос выполнялся сервером дольше, чем 190 миллисекунд).

Что же делать с этой проблемой? Хостеру я писать не стал, скорее всего это бесполезно. Тариф предусматривает общий ресурс процессора, так что наверняка это штатное использование. В таких случаях я делаю временный «ресайз» виртуалки: перехожу на следующий тарифный план с дополнительным количеством памяти и дискового пространства, а потом возвращаюсь назад. С определенной долей вероятности на текущем гипервизоре не будет доступных ресурсов, и система переместит виртуалку на другой гипервизор. Если повезет, то и оборудование будет новее. При возврате к старому тарифному плану виртуалка скорее всего не будет никуда перемещаться.

Я сделал временный ресайз и виртуалка оказалась на другом гипервизоре. Этот момент я отметил на графике красной лииней. CPU steal time упал практически до нуля, перцентили приблизились к среднему и медиане. Среднее время генерации тоже снизилось с 30 до 10 миллисекунд, потому что на гипервизоре оказался более мощный процессор.

Влияние ресайза я обнаружил случайно в сентябре 2023 года, когда хотел проверить, поможет ли увеличение памяти победить непонятные подтормаживания. Эффект был, но не от увеличения объема оперативки, а от перемещения виртуалки на новый гипервизор. Это подтверждает упавший график steal time:

Однако проблема повторилась в декабре 2023 года в большем масштабе, когда steal time подскочил до 8% и дальше стал колебаться около 2%:

Пришлось опять делать ресайз. Мешающие соседи ушли, однако виртуалка оказалась на гипервизоре с более старым и слабым процессором. Получилось не так удачно, но я не стал дальше испытывать судьбу.

Я стараюсь не злоупотреблять временным ресайзом для переноса виртуалки на более новое железо. Мне кажется, этот прием из серой зоны. С одной стороны, я систему специально не взламываю, пароли не подбираю, уязвимости не ищу и не эксплуатирую, нажимаю только на доступные в интерфейсе кнопки. С другой стороны, цель моих действий — не увеличить ресурсы сервера, а избавиться от мешающих соседей. И хостер, если захочет, может ослеживать и наказывать таких умников.

Технологии, облака и хостинг

Досмотрел трехчасовой доклад Ильи Григорика о клиентской оптимизации (первая часть и вторая часть). По итогам просмотра написал свои заметки.

Сформулирую еще несколько мыслей о технологиях (есть ощущение, что я зря ленюсь и не записываю их сюда).

Умные ребята давно поняли, что слово «облачный» в применении к информационным технологиям наполнено исключительно маркетинговым смыслом, и в «облачных технологиях» нет ничего принципиально нового. В то же время прорывные технологии появляются незаметно и со временем получают признание без особого пиара.

Отличный недавний пример — BitTorrent Sync. Это программа для синхронизации файлов на компьютерах и (теперь уже) мобильных устройствах. В ее основе лежит тот же протокол, что и в торентах, а по функциям программа ближе всего к дропбоксу. Интерфейс крайне прост, для подключения к папкам достаточно обменяться короткой хеш-строкой.

Задача синхронизации файлов с разным успехом решалась давно. Торентам тоже больше десяти лет. Догадались и успешно совместили их только сейчас.

Единственное существенное отличие BitTorrent Sync от дропбокса — отсутствие центрального сервера. Иными словами, кроме ваших устройств файлы больше нигде не хранятся, и синхронизация происходит только тогда, когда устройства одновременно подключены к сети. Впрочем, никто не мешает запустить btsync на сервере и устранить этот возможный недостаток. В организациях роль сервера легко сыграет постоянно включенный компьютер.

Перед описанием опыта использования я должен вспомнить о хостинге. Я использую и рекомендую виртуальные серверы Linode. За всё время использования этого хостинга сервер отключался один раз в ходе планового апргейда. Ссылка в этом абзаце с моим реферальным кодом. По нему зарегистрировались 6 человек, благодаря чему я заплатил за хостинг на 120 долларов меньше. Спасибо вам, добрые люди :)

Со времен прошлой заметки трехлетней давности тарифные планы Linode регулярно обновлялись. В 2011 году на самом дешевом тарифе за 20 долларов в месяц увеличили дисковое место с 16 до 20 гигабайт, потом снизили стоимость дополнительного трафика. Этой зимой дисковое место увеличилось до 24 гигабайт. Весной началось глобальное обновление: оперативная память удвоилась с 512 мегабайт до 1 гигабайта, включенный в тариф трафик увеличился с 200 гигабайт до 2 терабайт, и количество ядер процессора возросло с 4 до 8. Наконец, совсем недавно дисковое место снова увеличилось, с 24 гигабайт до 48.

Ясно, что мы видим не доброту владельцев хостинга, а проявление законов рынка и конкуренции. Я слышал отзывы о хостинге DigitalOcean. Самый дешевый тариф выглядит интересно, я бы поэкспериментировал: 512 мегабайт оперативки, 1 ядро, 20 гигабайт SSD, 1 терабайт трафика за 5 долларов в месяц.

Так вот, из образовавшихся 48 гигабайт на моем сервере занято от силы 5. Чтобы остальное место не простаивало, я запустил btsync и залил в «личное облако» музыкальную коллекцию. Под линуксом программа не требует настройки и управляется через веб-интерфейс на нестандартном порту. По соображениям безопасности его нужно закрывать в файерволе сразу же после добавления или удаления папок.

BitTorrent Sync — простой и мощный инструмент. Сценарии его использования на сервере гораздо шире «облачного диска». Самое простое — синхронизировать папку с резервными копиями. При добавлении бекапов туда они автоматически копируются на другие компьютеры. Или отказаться от загрузки файлов сайта через классический FTP и загружать их через btsync. Полет фантазии ничем не ограничен :)

Добавлено 20.12.2022: описываемая программа переименовывалась в resilio sync. Я от нее отказался в пользу открытой и более стабильной альтернативы — syncthing.

Почта для домена

Недавно я писал об окончательном переезде на vps-хостинг Linode. Тогда я отказался от попыток поднять полноценный почтовый сервер и просто настроил пересылку на гмейл-ящик.

Такой способ был вполне рабочим. Однако в спам попадало слишком много писем. Устанавливать на сервере костыли вроде SpamAssassin не хотелось. И в итоге я перешел на яндексовскую почту для доменов.

Сначала перенес старый домен. Чисто для проверки :) Количество спама значительно сократилось. Сейчас перенес и written.ru. Настройка заняла минут десять и заключалась в создании ящиков (в веб-интерфейсе), фильтров для пересылки на гмейл-ящик и изменении MX-записи домена. Еще через пять минут всё заработало.

Так что почту для домена вполне можно использовать. Особенно, если учесть, что такой же сервис Гугла является платным.

Добавлено: Как подсказывают в комментариях, у Гугла есть и бесплатная версия сервиса максимум на 50 аккаунтов. У Яндекса же можно сделать до 1000 аккаунтов или даже больше, и это всё бесплатно.

Еще добавлено: как заставить exim не доставлять почту локально.

Про Linode, written.ru и S2

Давно я не писал о хостинге. Не писал, потому что с хостингом у меня до недавнего времени ничего не менялось.

Зимой я решил опубликовать код движка S2 и стал подыскивать репозиторий для исходников. SourceForge, как и другие похожие сервисы для проектов с открытым кодом, имеет в лицензионном соглашении какое-то жуткое условие (если верить переводу в Википедии):

В одном из пунктов условий использования говорится, что передавая какие-либо данные через SourceForge.net, пользователи дают SourceForge, Inc. неисключительную пожизненную лицензию на их использование, изменение и продажу.

Мне это не понравилось, и я решил заказать виртуальный сервер, поднять на нем репозиторий subversion и со временем перенести на этот сервер все свои сайты.

Примерно в это же время Иван Сагалаев написал о переезде на VPS-хостинг Linode и дал ему положительную характеристику.

Я заказал самый дешевый вариант. Виртуальный сервер с жестким диском 16 гигабайт, 384 мегабайтами оперативной памяти и месячным трафиком в 200 гигабайт стоил 20 долларов в месяц. Летом, в честь дня рождения Linode, увеличили количество оперативной памяти до 512 мегабайт. Для моих целей такого сервера более чем достаточно.

Приведу свой реферальный код: 8c0e35f89f3d4065678d05cdb156f494d9e8d4c3. Если вы укажете его при регистрации и станете клиентом Linode, мне перепадет копеечка в благодарность за рекомендацию :)

А рекомендаций Linode действительно заслуживает: есть возможность простой смены тарифного плана; переездов между дата-центрами; размещения серверов в Лондоне (меньше время ответа, чем для серверов в США); покупки дополнительного места на диске, или оперативной памяти, или трафика, или даже регулярных бекапов. Единственный потенциальный недостаток — англоязычная поддержка, но это можно потерпеть.

Со временем я установил и настроил практически все нужные программы. Единственное, с чем не справился — с настройкой почтового сервера. Если быть точным, я повторил инструкцию по настройке SMTP и POP/IMAP серверов с виртуальными почтовыми ящиками, и они даже заработали. Но у меня не хватило терпения, чтобы прикрутить к этому делу хоть какой-нибудь веб-интерфейс (у почты же должен быть веб-интерфейс!).

Да и конфигурация почтового сервера не для простых смертных. Я пытался изменить поведение SMTP-сервера, чтобы уменьшить количество спама, но у меня ничего не получилось. Наверно, всё-таки, можно разобраться в логике работы и множестве параметров, но это целесообразно, если вы собираетесь подрабатывать системным администратором и каждую неделю поднимать почтовые серверы.

Мне ничего не оставалось, кроме как сдаться Гуглу — настроить пересылку всех писем на ящик на gmail.com.

Предыдущей ночью настал момент истины. На старом хостинге заканчивается оплаченный период, и я перенес written.ru на свой сервер. Скопировал файлы и содержимое базы данных, переделал .htaccess в конфигурацию nginx, обновил конфигурацию exim, настроил DNS-записи, прописал адреса новых ns-серверов. За два часа сайт заработал на новом месте.

Вообще-то, у меня были большие планы — поднять сайт на самой последней версии S2. Дело в том, что почти год назад я скопировал код сайта (это был еще SiteX 0.91), переименовал в S2 и начал доводить до ума. Cайт остался на старой версии, с небольшими багами и без новых вкусных плюшек. В итоге я не успел доделать некоторые специфичные для written.ru вещи, которые не нужны в S2. Пришлось переносить старый код.

В качестве лирического отступления расскажу о достоинствах модульной архитектуры S2. Специфичные для конкретных сайтов вещи лучше всего оформить в виде плагинов — расширений. При этом код ядра и других расширений остается нетронутым, и его легко обновлять до новых версий.

Сайт на новом месте себя чувствует очень хорошо. Включил отображение времени работы скриптов в нижней части страницы. Оно редко превышает 10 миллисекунд. Это говорит о том, что и хостинг хороший, и движок хороший :)

Если вдруг заметите, что перестало что-то работать, сообщите, пожалуйста, в комментариях.