Ошибка 1450 (0x5AA) Недостаточно системных ресурсов¶
- Table of contents
- Ошибка 1450 (0x5AA) Недостаточно системных ресурсов
Описание проблемы¶
При работе с большим количеством расписаний, расположенных на сетевой шаре на сервере, который обслуживает Windows server (2008 или выше), по достижении определенного количества, приложение перестает нормально работать с расписаниями, в отладочном логе появляются записи типа:
00000A58 @ 02-03-2015, 18:42:05.361 @ @ ERR_MSG @ 8 @ Error! Type=API Code=1450(0x5AA) Function=CHANGE_WISH::FindNextCh File=.\Changer.cpp Line=542
Insufficient system resources exist to complete the requested service.
ReadDirectoryChangesW failed
Path:\Server\root\PLAYLIST015-03-08 @ CHANGE_FIXER::Waiter
побочный эффект: во время работы приложения в этом состоянии, на сервер, где расположен рут, невозможно зайти по сети даже проводником. После завершения приложения все работает как обычно.
Уточнение¶
Описываемая в данной статье проблема не сопровождается появлением в системном журнале Windows записей о проблемах нехватки ресурсов на всем сервере, а касается только приложения Digispot.
Если в системном журнале Windows есть записи вида The server was unable to allocate from the system nonpaged pool because the pool was empty, совпадающие с появлением записей о 0x5AA в отладочном логе, то это проблема общей нехватки ресурсов на сервере и данная статья не поможет ее решить. Для решения необходимо найти и устранить причину исчерпания системной памяти.
Причина возникновения проблемы:¶
При работе с расписаниями, приложение для каждого отдельного расписания создает особое соединение с помощью функционала ReadDirectoryChanges, которое призвано уведомлять приложение об изменениях в соответствующем каталоге.
Каждое такое соединение для сетевого ресурса порождает асинхронную SMB команду, отправляемую на сервер, которая остается выполняться до закрытия каталога, либо завершения сессии.
В целях противодействия вредоносному ПО, Microsoft ограничила количество одновременных асинхронных SMB команд для одного соединения по умолчанию числом 512.
Соответственно, для всех попыток соединения при превышении лимита, сервер возвращает значение 0x5AA, и соединения не происходит.
Решение проблемы¶
Максимальное количество асинхронных SMB команд можно изменить, указав в реестре сервера соответствующее значение для ключа:
AsynchronousCredits (HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\(REG_DWORD)
По умолчанию этого ключа в реестре нет - его необходимо создать вручную.
После создания ключа ОС сервера лучше перезагрузить, т.к. рестарт сервиса Server может в некоторых случаях привести к ошибкам и недоступности сервера по сети.
Расчет требуемого количества асинхронных SMB-команд¶
Для расчета необходимого количества соединений, необходимо определить, прежде всего, какое количество расписаний обрабатывают все приложения запущенные из под одного пользователя на самом нагруженном рабочем месте.
Разные пользователи используют независимые подключения SBM, поэтому их суммировать не нужно. Например, сервис sch_to_db использует отдельное соединение относительно запущенной на той же машине приложения, тк.к, скорее всего, использует другую учетную запись. Разные приложения в разной конфигурации используют различное кол-во открытых расписаний. На это влияют следующие параметры настроек:
- Общие настройки\Доп\МБД\ Сколько дней расписания сохранять в БД, назовем его DbDays
- Настройки\Доп\Параметры системы подкачки\ Отслеживать расписания вперед на, назовем его OpenDays
- Общего количества настроенных в системе расписаний, назовем его N
Кроме этого, влияют настройки конкретных модулей.
Типовые примеры оценки для одного приложения
- DJin Репликатор расписаний = OpenDays х N
- сервис sch_to_db = DbDays х N
- Обычный эфирный DJin = N x (количество расписаний, настроенных в плеерах + 2)
- DDB = количество раздаваемых расписаний x DbDays
После расчета для одного приложения нужно суммировать результаты для приложений, работающих на одном рабочем месте из под одного аккаунта, определить из получившихся значений максимум и добавить запас, не менее 15-20% от получившегося количества.
Определение фактического количества асинхронных SMB¶
Самым простым способом является получение на сервере списка открытых через общий доступ файлов из которого нужно выделить только каталоги. Количество открытых каталогов и есть количество асинхронных SMB-команд.
Подверженные системы¶
Данная "проблема" характерна для семейства Windows Server 2008 и для более поздних версий Windows Server, и, скорее всего их десктопных аналогов, поскольку реализации протоколов SMB/CIFS в них весьма схожи.
Об этом, а также других параметрах тюнинга можно прочитать тут: http://blog.monitis.com/2013/05/16/tuning-windows-2012-file-system-part-1/
Похожие проблемы¶
Похожая проблема может возникнуть при работе с сетевыми каталогами, обслуживаемыми Wiindows server 2003. Она описана в статье The_network_BIOS_command_limit_(Недостаточно_ресурсов)
См. также¶