Недавно у нас случился медицинский детектив. Технико-медицинский. Почти в духе доктора Хауса. К нам обратилась компания, которая разрабатывает ПО для автоматизации процессов в медицинских учреждениях — радиологические информационные системы. В частности, софт для лучевой диагностики. Эти системы могут использовать как отдельные медицинские организации, так и целые регионы.

На одном из таких объектов, где работала система, регулярно возникали проблемы с быстродействием, особенно в часы пиковой нагрузки. При этом на других аналогичных объектах, где было установлено такое же ПО и была схожая нагрузка, этих проблем не было.

«Изначально клиент пришел с запросом на нагрузочное тестирование. Но мы предложили сначала провести аудит и починить проблемы со скоростью работы, а после уже — сделать нагрузочное (если потребуется)».
Алексей Алексеенко, главный системный администратор ITSumma.

И вот как мы ставили диагноз…

Этап 1 — предварительный осмотр

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

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

На эти процедуры мы потратили около часа.





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

Далее мы перешли к осмотру сервера. К сожалению, клиент по соображениям безопасности не мог предоставить нам доступ на серверы напрямую, поэтому пришлось импровизировать. Проверку организовали с помощью приложения удаленного доступа AnyDesk через ПК одного из штатных сотрудников, у которого уже был настроен удаленный доступ к серверу через PuTTY.



Как в известной сказке: нужно было найти иголку-проблему в зайце (AnyDesk), который спрятан в утке (PuTTY), в утке — яйцо (сам сервер)… и не факт, что иголка в яйце ещё окажется та самая!

Мы стали проверять hardware-сервера. И тут нас ждал сюрприз. Помимо работавшего с задержкой в несколько секунд AnyDesk, аудит усложняла проприетарная система, которая функционировала на базе XEN — виртуального сервера, вышедшего из массового использования лет 7 назад.

Но и на этом этапе также не обнаружилось проблем, которые влияли бы на быстродействие. Поэтому пришел черед проверить, как работает софт.

Сложности в лечении

Из-за ограниченного доступа в систему мы не могли увидеть, что тормозит с точки зрения клиента, на каких страницах он испытывает проблемы, — как и не могли воспроизвести эти проблемы. Поэтому приходилось действовать вслепую, а обратную связь получать от специалиста клиента, постоянно переспрашивая: «а сейчас тормозит? а теперь тормозит? а теперь?»

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

Вооружившись docker logs, мы начали искать хоть какие-то зацепки. Это опять же заняло у нас около часа.

В логах контейнеров, на первый взгляд, не было ничего криминального, без явных сообщений о таймаутах и ошибок или каких-то обрывов связи. Поэтому мы двинулись дальше, распутывая взаимодействие всех компонентов системы. В этом помогали strace и tcpdump. С их помощью мы обнаружили единственную улику: при обращении к сокет-серверу коннекты нередко доходили до него со статусом Connection Refused. Попытка его дебага strace не показала каких-либо подвисаний, в ядро процессора сокет-сервер не упирался.

Мы предположили, что проблема кроется в недостаточном количестве воркеров Daphne. О чем и сообщили клиенту с подробным описанием симптомов и логики нашей гипотезы.

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

Ночью заказчик всё же выкатил новую версию контейнера с веб-сокетом. Утром продолжилась игра в «А сейчас тормозит?», которая показала, что проблема с ограниченным доступом стала единственной. Система заработала корректно и быстро.

После чего мы доделали аудит системы, дали рекомендации по корректировкам параметров ОС, PostgreSQL и прочего ПО.

Итог: 2 админа, 1 монитор, 3 часа диагностики — и проблема, которую клиент не мог найти примерно месяц, решена!

Рекомендации, которые получил клиент

Проанализировав настройки виртуальной машины, мы выяснили, что медленная скорость работы всей системы была вызвана недостаточным числом воркеров daphne; проблему решили увеличением их количества. Также нашлось несколько моментов, которые можно «подстроить»:

1. Скорректировать настройки sysctl.conf, чтобы исключить достижения лимитов ядра, файловых дескрипторов и сети:
vm.swappiness = 0
fs.file-max = 1500000
kernel.msgmax = 65536
kernel.msgmnb = 65536
kernel.shmall = 4294967296
kernel.shmmax = 68719476736
net.core.netdev_max_backlog = 10000
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.somaxconn = 10000
net.core.wmem_max = 16777216
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_max_orphans = 400000
net.ipv4.tcp_max_syn_backlog = 3240000
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_wmem = 4096 65536 16777216

2. Увеличить лимиты в /etc/security/limits.conf



3. Отключить swap на ВМ для уменьшения нагрузки на диски.

4. Скорректировать параметры postgresql согласно рекомендациям Psqltuner (критичного там ничего нет, но в целом лучше выполнить).

5. Из-за ограничений, накладываемых виртуализацией, лучше переехать с виртуальной машины на железный сервер.

6. Из того характера нагрузки и характера использования ресурсов приложением, лучше использовать процессоры с бОльшей тактовой частотой. Сейчас стоит процессор с большим количеством ядер, но с малой частотой (всего 2.2ГГц ) и большая часть ядер простаивает, а те, которые используются, нагружены на 100%.

Что вам с этого всего?

Этот кейс навел на следующие мысли:

• Взгляд со стороны на инфраструктуру важен и нужен, даже если у вас очень сильная IT-команда в штате.
• Если вы наладите мониторинг по бестпрактисез — это прекрасно и замечательно. Но у каждой инфраструктуры есть особенности, которые можно выявить только во время нагрузочного тестирования или эксплуатации.
• Взаимодействие с клиентом — это важная часть работы. Линс очень помогали нам и оперативно реагировали. Отдельно стоит отметить, что спецы клиента выкатили новую версию контейнера за ночь в авральном порядке и, более того, в какой-то момент им пришлось срочно поднимать всю систему. Но в итоге даже трудности с доступом на сервер не повлияли на результат.

Если у вас тоже есть какая-то проблема, которую вы не можете долго решить — обращайтесь, проконсультируем: consulting@itsumma.ru