Новый IBProvider Trial [сборка 25117]
Неделю назад обнаружил, что нагрузочное тестирование 32-битной сборки зависло. Причем висит уже около суток. Состояние процесса показывало, что процесс в пике выедал практически все 4GB адресного пространства. Я было собрался просто убить процесс отмахнуться – «ну бывает, да», но потом решил, что такой подход ни к чему хорошему не приведет. И подключился к тесту отладчиком.
Зависание произошло по причине бесконечного ожидания уведомления о завершении асинхронной загрузки результатов запроса. Уведомления, понятное дело, тоже асинхронные – глупо приостанавливать загрузку и ожидать пока клиент обработает сигнал об изменении состояния процесса фоновой загрузки.
Общая схема «кто кого запускает» выглядит так:
Отладчик показал, что все выше обозначенные потоки находятся в завершенном состоянии. Поэтому клиент (тест) однозначно никогда ничего не дождется. И это была первая проблема – клиент не должен уходить в бесконечное ожидание. Нужно указывать timeout.
Второй проблемой была прямолинейность по отношению к ошибкам – возможность восстановления работоспособности после сбоя отсутствовала как класс.
При устранении этой проблемы, среди всего прочего, был добавлен специальный «сторож», который следит за состоянием очередей сообщений и пинает обрабатывающие потоки. Сторож запускается при подключении первого клиента и завершает свою работу после отключения последнего клиента.
Расходы на сторожа минимальны – он живет в «ресурсном» потоке провайдера, который обслуживает различные задачи, выполняемые по расписанию.
Третьей проблемой были исключения. А+B это не тоже самое что B+A. В очередной раз убедился.
И на последнем этапе было немного сокращено использование динамической памяти.
Вся работа над ошибками заняла неделю. Походу была обнаружена пара других мелких багов, написаны три новых теста (включая стрессовый) и приведены в порядок существующие тесты.
Забавно, что эта проблема не всплыла раньше – полное выжирание памяти 32-битыми тестами провайдера достаточно частое явление в последние годы.
Dmitry Kovalenko on 15 марта, 2017
Обнаружил интересное описание проблем, решенных в новой сборке Windows10 — 14393.953:
Решена проблема, приводившая к сбоям транзакций из-за нехватки памяти.
Наверное тоже 32-бита …