Производительность

Медленная доставка сообщений

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

Проверить:

1. Интервал запуска регламентного задания на стороне получателя — по умолчанию задание запускается раз в минуту; задержка может быть штатной.
2. Число одновременных потоков обработки (threads) в настройках подсистемы — если потоков мало, сообщения выстраиваются в очередь.
3. Очередь входящих сообщений не переполнена задачами с долгой обработкой, которые блокируют слоты.

Медленная отправка из 1С

Симптом: исходящий обработчик выполняется долго, очередь исходящих растёт.

Причины:

• Метод хранения «По ссылке» с тяжёлой сериализацией объекта в момент отправки.
• Большой объём сообщений в очереди при малом числе потоков отправки (threads.out).
• Сетевые задержки между 1С-сервером и DataHUB.

Действие:

1. Увеличить threads.out в форме настроек (осторожно — нагрузка на сервер 1С).
2. Убедиться, что исходящий обработчик не выполняет тяжёлых запросов при сериализации.
3. Проверить сетевую задержку до DataHUB: ping и traceroute от сервера 1С.

Высокая нагрузка на RabbitMQ

Симптом: RabbitMQ Management показывает большой Publish rate или растущие очереди.

Причины:

• Большой объём исходящих сообщений за короткий промежуток (например, начальная загрузка данных).
• Inline-вложения в теле сообщения (Base64) сильно увеличивают размер — следует перейти на хранение файлов по ссылке (S3 presigned URL).
• ACK не отправляются вовремя — сообщения зависают в статусе Unacked и блокируют слоты.

Проверить количество Unacked в RabbitMQ Management → Queues → целевая очередь.

Высокая нагрузка на PostgreSQL

Симптом: DataHUB работает медленно, в логах длинные времена SQL-запросов.

Проверить:

-- Активные соединения
SELECT count(*) FROM pg_stat_activity WHERE state = 'active';

-- Самые долгие текущие запросы
SELECT pid, now() - query_start AS duration, query
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY duration DESC
LIMIT 10;

Типичные действия:

1. Убедиться, что VACUUM выполняется регулярно на таблицах с высоким update/delete.
2. При постоянно высоком числе соединений — рассмотреть PgBouncer.

Рекомендации по начальной загрузке данных

При первоначальной загрузке большого объёма данных в DataHUB (тысячи и более сообщений за сеанс):

• Разбить загрузку на порции по 100–500 сообщений с паузами между порциями.
• Отправлять порцию, дожидаться, пока получатель её обработает, затем отправлять следующую.
• Следить за очередями RabbitMQ: если Ready растёт быстро, снизить темп отправки.
• Убедиться, что получатель успевает обрабатывать поступающий поток (статусы «Обработано» растут).