Metrika42 помогла медицинской сети клиник выявить причину высокой нагрузки на сервер и PostgreSQL

Metrika42 помогла медицинской сети клиник локализовать источник высокой нагрузки в корпоративной системе на базе «1С». Анализ технологического журнала, метрик инфраструктуры и прикладного кода показал, что значительную часть нагрузки создавали фоновые задания интеграции медицинской информационной системы. Диагностика позволила пройти от общего симптома — высокой загрузки процессора — до конкретного регламентного задания, запросов PostgreSQL и участков кода, требующих оптимизации. Об этом CNews сообщили представители Metrika42.

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

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

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

Один из запусков задания продолжался около 2 ч 45 мин и использовал около 20,4 мин чистого процессорного времени. Внутри него были зафиксированы продолжительные обращения к PostgreSQL. Наиболее тяжелая операция записи во временную таблицу выполнялась 427 сек, а объем отдельных промежуточных наборов данных достигал примерно 140–238 тыс. строк.

Анализ предыдущих запусков показал, что проблема носила систематический характер. Сопоставимые фоновые задания выполнялись и в другие дни, причем отдельные вызовы потребляли до 64–67 мин процессорного времени. Таким образом, речь шла не о единичном всплеске нагрузки или случайном инфраструктурном сбое, а о повторяющемся сценарии обработки данных.

Дополнительная диагностика позволила восстановить общую картину нагрузки. В тот же период под служебной учетной записью выполнялись и другие ресурсоемкие фоновые процессы, в том числе еще одна интеграционная выгрузка и контроль задач. К концу исследуемого интервала загрузка процессора сервера PostgreSQL достигала примерно 97–98%.

При этом Metrika42 позволила исключить несколько альтернативных версий. Признаков блокировок PostgreSQL, способных объяснить наблюдаемое потребление ресурсов, в исследуемом интервале обнаружено не было. Сервер приложений «1С» также не испытывал дефицита CPU. Интерактивные операции сотрудников медицинской сети по уровню потребления ресурсов существенно уступали фоновым процессам.

Следующим этапом стал анализ прикладного кода интеграции. Он подтвердил технический механизм возникновения нагрузки.

Выяснилось, что регламентное задание MedBI при каждом запуске повторно обрабатывало данные за предыдущие 90 дней. Инкрементальный механизм, при котором система выгружает преимущественно новые или изменившиеся данные, не использовался. В результате каждый новый запуск вновь формировал крупные промежуточные наборы.

Одна из основных процедур выгрузки также содержала сложный пакет запросов с большим количеством временных таблиц и соединений. В отдельных запросах использовалось более 20 соединений таблиц.

Активы «СКБ Контур». Инфографика CNews

После получения данных результат целиком выгружался в таблицу значений и дополнительно обрабатывался построчно. В ходе этой обработки выполнялись разыменования ссылок и обращения к связанным объектам. На больших объемах медицинских данных такой подход способен создавать значительное количество дополнительных операций и увеличивать нагрузку на СУБД и прикладной контур.

Таким образом, диагностика прошла несколько уровней: от высокой загрузки CPU — к служебной учетной записи, затем к конкретному фоновому заданию интеграции MedBI, его запросам к PostgreSQL и далее к участкам прикладного кода, формировавшим тяжелый профиль выполнения.

«В медицинских информационных системах проблема производительности редко ограничивается одним медленным запросом. За внешним симптомом могут одновременно находиться расписание фоновых заданий, объем обрабатываемых данных, логика интеграции и особенности конкретного участка кода. В этом кейсе нам удалось пройти всю цепочку — от высокой загрузки CPU до конкретного регламентного задания и механизма в коде, который эту нагрузку создавал. Это дает ИТ-команде не просто диагноз, а понятный план оптимизации и возможность проверить результат изменений на следующем цикле работы системы», — сказал Денис Пахомов, руководитель Metrika42.

По итогам расследования были определены основные направления оптимизации. В частности, вместо повторной обработки полного 90-дневного периода может быть рассмотрен переход к инкрементальной выгрузке. Кроме того, целесообразно сократить объем промежуточных выборок, оптимизировать сложные SQL-запросы и уменьшить объем построчной обработки данных.

Как машиностроению выполнять заказы, когда не хватает людей и оборудования, и где тут ИТ Цифровизация

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

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

Кейс медицинской сети показывает, что высокая загрузка серверов «1С» и PostgreSQL не всегда означает необходимость увеличивать вычислительные ресурсы. В данном случае Metrika42 позволила связать инфраструктурный симптом с конкретным бизнес-процессом обмена медицинскими данными и затем подтвердить причину на уровне прикладной реализации.

В результате ИТ-команда получила конкретный план дальнейших действий: какие регламентные задания необходимо оптимизировать, какие запросы исследовать, какие участки кода переработать и по каким показателям оценивать эффект изменений.