Система. Время выполнения. InteropServices. COMException (0x80070008): Недостаточно устройства хранения данных доступно для обработки этой команды
Я пытаюсь диагностировать это исключение:
System.Runtime.InteropServices.COMException (0x80070008): Not enough storage is available to process this command. (Exception from HRESULT: 0x80070008)
at System.Runtime.Remoting.RemotingServices.AllocateUninitializedObject(RuntimeType objectType)
at System.Runtime.Remoting.RemotingServices.AllocateUninitializedObject(Type objectType)
at System.Runtime.Remoting.Activation.ActivationServices.CreateInstance(Type serverType)
at System.Runtime.Remoting.Activation.ActivationServices.IsCurrentContextOK(Type serverType, Object[] props, Boolean bNewObj)
at Oracle.DataAccess.Client.CThreadPool..ctor()
at Oracle.DataAccess.Client.OracleCommand.set_CommandTimeout(Int32 value)
...
Не похоже, что любой из нормальных типов "устройства хранения данных" поразил любые пределы. Приложение использует приблизительно 400 МБ памяти, 70 потоков, 2 000 дескрипторов и жесткий диск имеет многих свободный ГБ. Машина запускает Windows 2003 Enterprise Server 32bit с 16 ГБ RAM, таким образом, память не должна быть проблемой.
Приложение работает как сервис окон, таким образом, нет никаких используемых объектов GDI. Исчерпывание дескрипторов GDI является частой причиной этого исключения.
Соединения с базой данных, команды и читатели все все перенесены с использованием блоков, таким образом, они должны становиться очищенными правильно.
ОБНОВЛЕНИЕ: Сокращение количества потоков, которые мы использовали от 12 до 4, кажется, устранило проблему. Нам удалось работать без ошибок больше 24 часов, прежде чем мы продержались между 4 и 8 часами. UPDATE2: Я никогда не выяснял, какой ресурс мы заканчивались, но сокращали количество потоков, кажется, решил проблему. Или по крайней мере скрытый это.
3 ответа
Похоже, что-то зацикливается и создает экземпляры слишком большого количества объектов в куче, поэтому у вас заканчивается память в куче. Ищите любые петли в вызывающем коде.
Еще один фактор, который необходимо учитывать, - это фрагментация памяти.
Максимальное единичное выделение, которое вы можете выполнить, равно самому большому смежному блоку памяти, доступному процессу. Почти всегда этот блок меньше общего объема памяти, доступного процессу, из-за фрагментации. То есть выделенные блоки памяти, находящиеся между двумя свободными блоками памяти, "фрагментируют" пространство.
Чем больше фрагментация в процессе, тем меньше самый большой непрерывный блок памяти, который будет доступен. Я видел ситуации, когда было почти 1 ГБ свободной памяти, но самый большой непрерывный блок был около 10 МБ.
Проверяли ли вы фрагментацию памяти в этом процессе?
Вы устранили все очевидные источники этой ошибки для своего процесса. Вероятно, это проблема операционной системы. Единственный ресурс, который всегда находится под нагрузкой на сервер, - это пул памяти ядра. Несложно увидеть, TaskMgr.exe отображает его на вкладке «Производительность».
Это несколько соответствует вашему стеку вызовов, похоже, что провайдер Oracle создает потоки для пула потоков. Поток занимает мегабайт в вашем процессе и 24 КБ в пуле памяти ядра, который используется в качестве стека, когда поток переключается в режим ядра.
Справочная информация доступна здесь .