![](https://habrastorage.org/webt/8s/3c/xp/8s3cxpxfv2x2_wxstdsaofocari.jpeg)
Недавно у нас случился медицинский детектив. Технико-медицинский. Почти в духе доктора Хауса. К нам обратилась компания, которая разрабатывает ПО для автоматизации процессов в медицинских учреждениях — радиологические информационные системы. В частности, софт для лучевой диагностики. Эти системы могут использовать как отдельные медицинские организации, так и целые регионы.
На одном из таких объектов, где работала система, регулярно возникали проблемы с быстродействием, особенно в часы пиковой нагрузки. При этом на других аналогичных объектах, где было установлено такое же ПО и была схожая нагрузка, этих проблем не было.
«Изначально клиент пришел с запросом на нагрузочное тестирование. Но мы предложили сначала провести аудит и починить проблемы со скоростью работы, а после уже — сделать нагрузочное (если потребуется)».
Алексей Алексеенко, главный системный администратор ITSumma.
И вот как мы ставили диагноз…
Этап 1 — предварительный осмотр
Сначала мы продиагностировали систему мониторинга. Она состояла из Zabbix, который отображал базовые параметры сервера, и Grafana, где снимались бизнесовые метрики из приложения и был настроен мониторинг PostgreSQL.
При этом первоначальный аудит не выявил никаких проблем. Нагрузка на сервер держалась в норме даже в часы пик, было большое количество свободных ресурсов, проблем в работе базы по мониторингу также обнаружено не было.
На эти процедуры мы потратили около часа.
![](https://habrastorage.org/webt/ye/bw/xc/yebwxc8a32ngnciqk9lmcfo4ljs.png)
![](https://habrastorage.org/webt/os/yx/2o/osyx2o6e1vm8yqpyeouhac5cjuo.png)
Отчет PostgreSQL Tuner с результатами аудита системы мониторинга. Ничего критичного, нужна лишь небольшая подстройка параметров.
Далее мы перешли к осмотру сервера. К сожалению, клиент по соображениям безопасности не мог предоставить нам доступ на серверы напрямую, поэтому пришлось импровизировать. Проверку организовали с помощью приложения удаленного доступа AnyDesk через ПК одного из штатных сотрудников, у которого уже был настроен удаленный доступ к серверу через PuTTY.
![](https://habrastorage.org/webt/ov/wy/vo/ovwyvov4exabrzod14citz6iigu.png)
Как в известной сказке: нужно было найти иголку-проблему в зайце (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
![](https://habrastorage.org/webt/ai/at/ug/aiatugzguyhepwhepqj0vis--k4.jpeg)
3. Отключить swap на ВМ для уменьшения нагрузки на диски.
4. Скорректировать параметры postgresql согласно рекомендациям Psqltuner (критичного там ничего нет, но в целом лучше выполнить).
5. Из-за ограничений, накладываемых виртуализацией, лучше переехать с виртуальной машины на железный сервер.
6. Из того характера нагрузки и характера использования ресурсов приложением, лучше использовать процессоры с бОльшей тактовой частотой. Сейчас стоит процессор с большим количеством ядер, но с малой частотой (всего 2.2ГГц ) и большая часть ядер простаивает, а те, которые используются, нагружены на 100%.
Что вам с этого всего?
Этот кейс навел на следующие мысли:
- Взгляд со стороны на инфраструктуру важен и нужен, даже если у вас очень сильная IT-команда в штате.
- Если вы наладите мониторинг по бестпрактисез — это прекрасно и замечательно. Но у каждой инфраструктуры есть особенности, которые можно выявить только во время нагрузочного тестирования или эксплуатации.
- Взаимодействие с клиентом — это важная часть работы. Линс очень помогали нам и оперативно реагировали. Отдельно стоит отметить, что спецы клиента выкатили новую версию контейнера за ночь в авральном порядке и, более того, в какой-то момент им пришлось срочно поднимать всю систему. Но в итоге даже трудности с доступом на сервер не повлияли на результат.
Если у вас тоже есть какая-то проблема, которую вы не можете долго решить — обращайтесь, проконсультируем: consulting@itsumma.ru
Комментарии (9)
WinLin2
20.12.2022 18:41https://www.opennet.ru/opennews/art.shtml?num=58340
Вышел xen 4.17.
Cittrix Xenserver 6.2 раньше использовал но потом стали денег просить и возможности бесплатной версии урезать.
AlexeyKovyazin
20.12.2022 23:04Postgres Professional Можете прокомментировать настройку
vm.swappiness = 0
для PG?ITSumma Автор
21.12.2022 07:30Вопрос не к нам, но всё же позволю себе заметить, что, учитывая большое количество свободной памяти, свап следует исключить.
MUTbKA98
Xen точно вышел из употребления? 8-О
tutunak