Тест на производительность

Сегодня рано утром в в серверном центре Wialon произошел сбой – у коммуникационного сервера, который принимает все данные от объектов, зависло сетевое соединение на сервер резервного копирования (ошибка удаленной файловой системы NFS). Коммуникационный сервер хитрым образом подвис – данные от устройств он принимал, но на сервер БД не передавал. Так продолжалось некоторое время до момента диагностики проблемы сотрудником техподдержки.

Потом в течении нескольких минут проблема была диагностирована, сетевая файловая система NFS была размонтирована и сервис перезапущен. И в дело вступили системы защиты, благодаря которым мы и говорим о высокой надежности как ПО Wialon, так и конфигурации серверного центра – при отсутствии связи с сервисом БД коммуникационный сервис накапливал и сохранял все сообщения. А после восстановления соединения он их слил.

А данных было много… И нам удалось заснять объем поступающих данных в этот момент:

600.000 сообщений в минуту, это 10.000 сообщений в секунду в среднем в 1 минуту. Это примерно в 100 раз больше обычной нагрузки.

Загрузка CPU коммуникационного сервера составляла 50%, при 8 ядрах это 12% от всех ресурсов. Но он сообщения не принимал, а только вычитывал с локального кэша и отправлял.

Более интересна была загрузка CPU сервера БД – 250% при 800% максимум, это примерно 30% всех ресурсов.

Таким образом, вся инфраструктура продемонстрировала именно ту живучесть, которая была заложена в неё изначально. И хотя хочется, чтобы таких испытаний было как можно меньше, тем не менее, именно они являются настоящей проверкой ПО и его окружения на выживаемость и производительность.

С проблемой системы NFS мы попробуем разобраться, но это первый такой случай за 3 года, и с большой долей вероятности можно говорить, что он не должен возникнуть снова. Да и не программисты мы ядра Linux-а. В Windows был бы уже «синий экран смерти», а тут остановил сервисы, перемонтировал файловую систему, и продолжал работать, даже не перезапуская сервер.

Кстати по времени это совпало с моментом перевода времени на час вперед. Значит, примерно год у нас есть в запасе. Или полгода до перевода на час назад…

Кстати, по поводу Linux:  время работы нашего сервера файрвола и маршрутизатора:

s1:~# uptime
 08:15:28 up 493 days, 10:03,  1 user,  load average: 0.00, 0.00, 0.00

Скоро будет уже 500 день…

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *