Exception of type system outofmemoryexception was thrown что за ошибка
Out OfMemory Exception Класс
Определение
Некоторые сведения относятся к предварительной версии продукта, в которую до выпуска могут быть внесены существенные изменения. Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, относительно приведенных здесь сведений.
Исключение, которое выбрасывается при недостаточном объеме памяти для выполнения программы.
Комментарии
OutOfMemoryException использует HRESULT со COR_E_OUTOFMEMORY значением 0x8007000E.
Список начальных значений свойств для экземпляра OutOfMemoryException, см. в разделе OutOfMemoryException конструкторы.
OutOfMemoryExceptionИсключение имеет две основные причины.
Предпринимается попытка расширения StringBuilder объекта, длина которого превышает длину, определенную его StringBuilder.MaxCapacity свойством.
Среда CLR не может выделить достаточно непрерывной памяти для успешного выполнения операции. Это исключение может быть создано любым назначением свойства или вызовом метода, требующего выделения памяти. Дополнительные сведения о причине OutOfMemoryException исключения см. в записи блога «недостаточно памяти» не относится к физической памяти.
Этот тип OutOfMemoryException исключения представляет разрушительный сбой. Если решено решить эту ошибку, следует включить catch блок, вызывающий Environment.FailFast метод, чтобы завершить работу приложения и добавить запись в журнал системных событий, как показано в следующем примере.
Некоторые условия, при которых создается исключение, и действия, которые можно предпринять для исключения, включают следующее:
Вызывается StringBuilder.Insert метод.
Предпринимается попытка увеличить длину StringBuilder объекта, превышающего размер, указанный в его StringBuilder.MaxCapacity свойстве. В следующем примере показано исключение, вызываемое OutOfMemoryException вызовом StringBuilder.Insert(Int32, String, Int32) метода, когда в примере предпринимается попытка вставить строку, которая приведет к Length превышению максимального объема свойства объекта.
Для устранения ошибки можно выполнить одно из следующих действий.
Вызовите StringBuilder.StringBuilder(Int32, Int32) конструктор со maxCapacity значением, которое достаточно велико для размещения всех расширений StringBuilder объекта.
Приложение выполняется как 32-разрядный процесс.
32-разрядные процессы могут выделять максимум 2 ГБ памяти виртуального режима пользователя на 32-разрядных системах и 4 ГБ виртуальной памяти в режиме пользователя на 64-разрядных системах. Это может усложнить для среды CLR выделение достаточного непрерывного объема памяти, если требуется большое выделение. В отличие от этого, 64-разрядные процессы могут выделить до 8 ТБ виртуальной памяти. Чтобы устранить это исключение, перекомпилируйте приложение, предназначенное для 64-разрядной платформы. сведения о настройке конкретных платформ в Visual Studio см. в разделе как настроить проекты для целевых платформ.
В приложении происходит утечка неуправляемых ресурсов
Вы пытаетесь создать большой массив в 64-разрядном процессе
Вы работаете с очень большими наборами данных (например, массивами, коллекциями или наборами данных базы данных) в памяти.
Если структуры данных или наборы данных, находящиеся в памяти, становятся настолько большими, что среда CLR не может выделить для них достаточно непрерывной памяти, то OutOfMemoryException результаты исключения.
Чтобы предотвратить OutOfMemoryException исключения, необходимо изменить приложение таким образом, чтобы меньше данных наделено в памяти, или данные разделены на сегменты, требующие меньшего выделения памяти. Пример:
Если вы получаете все данные из базы данных и затем фильтруете их в приложении, чтобы сократить количество обращений к серверу, следует изменить запросы, чтобы возвращалось только подмножество данных, необходимых приложению. При работе с большими таблицами несколько запросов практически всегда более эффективны, чем извлечение всех данных в одной таблице и последующее управление им.
При выполнении запросов, создаваемых пользователями динамически, следует убедиться, что число записей, возвращаемых запросом, ограничено.
Если вы используете большие массивы или другие объекты коллекции, размер которых приводит к OutOfMemoryException исключению, следует изменить приложение для работы с данными в подмножествах, а не для совместной работы с ним.
В следующем примере возвращается массив, состоящий из 200 000 000 значений с плавающей запятой, а затем вычисляется их среднее значение. В выходных данных примера показано, что, поскольку в примере сохраняется весь массив в памяти перед вычислением среднего, OutOfMemoryException создается исключение.
В следующем примере исключение устраняется OutOfMemoryException путем обработки входящих данных без сохранения всего набора данных в памяти, сериализации данных в файл при необходимости для дальнейшей обработки (в данном примере эти строки заносятся в комментарий, так как в данном случае они создают файл, размер которого больше 1 ГБ) и возвращают вычисленное среднее и число вариантов в вызывающую подпрограммы.
Вы постоянно объединяете большие строки.
Так как строки являются неизменяемыми, каждая операция сцепления строк создает новую строку. Влияние на небольшие строки или небольшое количество операций объединения незначительно. Но для больших строк или очень большого числа операций сцепления объединение строк может привести к большому количеству выделений памяти и фрагментации памяти, низкой производительности и, возможно, OutOfMemoryException исключений.
При объединении больших строк или выполнении большого числа операций объединения следует использовать StringBuilder класс вместо String класса. Завершив обработку строки, преобразуйте StringBuilder экземпляр в строку, вызвав StringBuilder.ToString метод.
Закрепление большого количества объектов в памяти.
Оцените, нужно ли закреплять каждый объект,
Убедитесь, что каждый объект отменяется закреплением как можно скорее.
Убедитесь, что каждый вызов GCHandle.Alloc(Object, GCHandleType) метода для крепления памяти имеет соответствующий вызов GCHandle.Free метода для открепления этой памяти.
Следующие инструкции промежуточных инструкций (MSIL) Microsoft вызовут OutOfMemoryException исключение:
Конструкторы
Инициализирует новый экземпляр класса OutOfMemoryException.
Инициализирует новый экземпляр класса OutOfMemoryException с сериализованными данными.
Инициализирует новый экземпляр класса OutOfMemoryException с указанным сообщением об ошибке.
Инициализирует новый экземпляр класса OutOfMemoryException указанным сообщением об ошибке и ссылкой на внутреннее исключение, вызвавшее данное исключение.
Свойства
Возвращает коллекцию пар «ключ-значение», предоставляющую дополнительные сведения об исключении.
Получает или задает ссылку на файл справки, связанный с этим исключением.
Возвращает или задает HRESULT — кодированное числовое значение, присвоенное определенному исключению.
Возвращает экземпляр класса Exception, который вызвал текущее исключение.
Возвращает сообщение, описывающее текущее исключение.
Возвращает или задает имя приложения или объекта, вызывавшего ошибку.
Получает строковое представление непосредственных кадров в стеке вызова.
Возвращает метод, создавший текущее исключение.
Методы
Определяет, равен ли указанный объект текущему объекту.
При переопределении в производном классе возвращает исключение Exception, которое является первопричиной одного или нескольких последующих исключений.
Служит хэш-функцией по умолчанию.
При переопределении в производном классе задает объект SerializationInfo со сведениями об исключении.
Возвращает тип среды выполнения текущего экземпляра.
Создает неполную копию текущего объекта Object.
Создает и возвращает строковое представление текущего исключения.
События
Возникает, когда исключение сериализовано для создания объекта состояния исключения, содержащего сериализованные данные об исключении.
Out OfMemory Exception Class
Definition
Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
The exception that is thrown when there is not enough memory to continue the execution of a program.
Remarks
For a list of initial property values for an instance of OutOfMemoryException, see the OutOfMemoryException constructors.
An OutOfMemoryException exception has two major causes:
You are attempting to expand a StringBuilder object beyond the length defined by its StringBuilder.MaxCapacity property.
The common language runtime cannot allocate enough contiguous memory to successfully perform an operation. This exception can be thrown by any property assignment or method call that requires a memory allocation. For more information on the cause of the OutOfMemoryException exception, see the blog post «Out of Memory» Does Not Refer to Physical Memory.
This type of OutOfMemoryException exception represents a catastrophic failure. If you choose to handle the exception, you should include a catch block that calls the Environment.FailFast method to terminate your app and add an entry to the system event log, as the following example does.
Some of the conditions under which the exception is thrown and the actions you can take to eliminate it include the following:
You are calling the StringBuilder.Insert method.
You are attempting to increase the length of a StringBuilder object beyond the size specified by its StringBuilder.MaxCapacity property. The following example illustrates the OutOfMemoryException exception thrown by a call to the StringBuilder.Insert(Int32, String, Int32) method when the example tries to insert a string that would cause the object’s Length property to exceed its maximum capacity.
You can do either of the following to address the error:
Replace the call to the StringBuilder.StringBuilder(Int32, Int32) constructor with a call any other StringBuilder constructor overload. The maximum capacity of your StringBuilder object will be set to its default value, which is Int32.MaxValue.
Call the StringBuilder.StringBuilder(Int32, Int32) constructor with a maxCapacity value that is large enough to accommodate any expansions to the StringBuilder object.
Your app runs as a 32-bit process.
32-bit processes can allocate a maximum of 2GB of virtual user-mode memory on 32-bit systems, and 4GB of virtual user-mode memory on 64-bit systems. This can make it more difficult for the common language runtime to allocate sufficient contiguous memory when a large allocation is needed. In contrast, 64-bit processes can allocate up to 8TB of virtual memory. To address this exception, recompile your app to target a 64-bit platform. For information on targeting specific platforms in Visual Studio, see How to: Configure Projects to Target Platforms.
Your app is leaking unmanaged resources
If you are consuming a type that uses unmanaged resources, you should be sure to call its IDisposable.Dispose method when you have finished using it. (Some types also implement a Close method that is identical in function to a Dispose method.) For more information, see the Using Objects That Implement IDisposable topic.
If you have created a type that uses unmanaged resources, make sure that you have implemented the Dispose pattern and, if necessary, supplied a finalizer. For more information, see Implementing a Dispose method and Object.Finalize.
You are attempting to create a large array in a 64-bit process
You are working with very large sets of data (such as arrays, collections, or database data sets) in memory.
When data structures or data sets that reside in memory become so large that the common language runtime is unable to allocate enough contiguous memory for them, an OutOfMemoryException exception results.
To prevent the OutOfMemoryException exceptions, you must modify your application so that less data is resident in memory, or the data is divided into segments that require smaller memory allocations. For example:
If you are retrieving all of the data from a database and then filtering it in your app to minimize trips to the server, you should modify your queries to return only the subset of data that your app needs. When working with large tables, multiple queries are almost always more efficient than retrieving all of the data in a single table and then manipulating it.
If you are executing queries that users create dynamically, you should ensure that the number of records returned by the query is limited.
If you are using large arrays or other collection objects whose size results in an OutOfMemoryException exception, you should modify your application to work the data in subsets rather than to work with it all at once.
The following example gets a array that consists of 200 million floating-point values and then calculates their mean. The output from the example shows that, because the example stores the entire array in memory before it calculates the mean, an OutOfMemoryException is thrown.
The following example eliminates the OutOfMemoryException exception by processing the incoming data without storing the entire data set in memory, serializing the data to a file if necessary to permit further processing (these lines are commented out in the example, since in this case they produce a file whose size is greater than 1GB), and returning the calculated mean and the number of cases to the calling routine.
You are repeatedly concatenating large strings.
Because strings are immutable, each string concatenation operation creates a new string. The impact for small strings, or for a small number of concatenation operations, is negligible. But for large strings or a very large number of concatenation operations, string concatenation can lead to a large number of memory allocations and memory fragmentation, poor performance, and possibly OutOfMemoryException exceptions.
When concatenating large strings or performing a large number of concatenation operations, you should use the StringBuilder class instead of the String class. When you have finished manipulating the string, convert the StringBuilder instance to a string by calling the StringBuilder.ToString method.
You pin a large number of objects in memory.
Pinning a large number of objects in memory for long periods can make it difficult for the garbage collector to allocate contiguous blocks of memory. If you’ve pinned a large number of objects in memory, for example by using the fixed statement in C# or by calling the GCHandle.Alloc(Object, GCHandleType) method with a handle type of GCHandleType.Pinned, you can do the following to address the OutOfMemoryException exception.
Evaluate whether each object really needs to be pinned,
Ensure that each object is unpinned as soon as possible.
Make sure that each call to the GCHandle.Alloc(Object, GCHandleType) method to pin memory has a corresponding call to the GCHandle.Free method to unpin that memory.
The following Microsoft intermediate (MSIL) instructions throw an OutOfMemoryException exception:
Constructors
Initializes a new instance of the OutOfMemoryException class.
Initializes a new instance of the OutOfMemoryException class with serialized data.
Initializes a new instance of the OutOfMemoryException class with a specified error message.
Initializes a new instance of the OutOfMemoryException class with a specified error message and a reference to the inner exception that is the cause of this exception.
Properties
Gets a collection of key/value pairs that provide additional user-defined information about the exception.
Gets or sets a link to the help file associated with this exception.
Gets or sets HRESULT, a coded numerical value that is assigned to a specific exception.
Gets the Exception instance that caused the current exception.
Gets a message that describes the current exception.
Gets or sets the name of the application or the object that causes the error.
Gets a string representation of the immediate frames on the call stack.
Gets the method that throws the current exception.
Methods
Determines whether the specified object is equal to the current object.
When overridden in a derived class, returns the Exception that is the root cause of one or more subsequent exceptions.
Serves as the default hash function.
When overridden in a derived class, sets the SerializationInfo with information about the exception.
Gets the runtime type of the current instance.
Creates a shallow copy of the current Object.
Creates and returns a string representation of the current exception.
Events
Occurs when an exception is serialized to create an exception state object that contains serialized data about the exception.
Исправление: Возникает исключение System.OutOfMemoryException или IDE отвечает медленно после построения решения, содержит несколько раз во многих проектах WPF с помощью платформа.NET Framework 3.5 SP1
Симптомы
Создавать сложные решения, содержащего много проектов Windows Presentation Foundation (WPF), основанных на Microsoft платформа.NET Framework 3.5 Пакет обновления 1 (SP1). При каждом построении решения, увеличивается использование памяти процесса devenv.exe. После построения решения несколько раз появиться одно или несколько из следующих проблем:
Исключение типа «System.OutOfMemoryException».
При нажатии любой кнопки в Интегрированной среде разработки IDE медленно реагирует и даже сбоям.
Примечание. Данная проблема возникает даже в том случае, когда XAML-файлы не открыть.
Причина
Эта проблема возникает из-за фрагментации памяти между библиотекой классов платформа.NET Framework и средства синтаксического анализа XAML.
Решение
Сведения об исправлении
Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.
Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этот раздел не отображается, обратитесь в службу поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Чтобы получить полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание, посетите следующий веб-сайт корпорации Майкрософт:
http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Платформа.NET Framework 3.5 с пакетом обновления 1 для установки этого исправления необходимо иметь.
Необходимость перезагрузки
Необходимо перезагрузить компьютер после установки исправления, если используется не экземпляр платформа.NET Framework.
Сведения о замене исправлений
Это исправление не заменяет других исправлений.
Сведения о файлах
Английская версия данного исправления содержит атрибуты файла (или более поздние атрибуты файлов), приведенные в следующей таблице. Дата и время для этих файлов указаны в формате общего скоординированного времени (UTC). При просмотре сведений о файле, он преобразуется в локальное время. Чтобы узнать разницу между временем по Гринвичу и местным временем, откройте вкладку Часовой пояс элемента Дата и время в панели управления.
Windraw dot Net
Победа OutOfMemoryException
Довольно долго мы боролись за производительность программы WinDraw, а именно за взаимодействие между WinDraw и MS SQL Server.
За время этой борьбы мы сделали несколько серьезных выводов:
1. Использование метода dbo.ZipUnPack в запросах(то есть на стороне SQL Server) построителя отчетов Stimulsoft Reports.Net приводил к тому, что ошибка System.OutOfMemoryException появлялась гораздо чаще. Переведя выполнение этого метода на сторону сервера приложений (т.е. используя Atechnology.Components.ZipArchiver.UnZip2 (byte[] classnative) ) мы значительно увеличили время работы SQLServer без перезагрузки.
2. Железный апгрейд не решает проблему System.OutOfMemoryException, доказано опытным путем. А именно, с момента первого описания проблемы (Проблема производительности WinDraw. ) мы приобрели новый сервер — Hewlett Packard Proliant DL380G6 (2xXeonQC, 32Gb оперативной памяти), на котором установили Microsoft Windows Server 2003 Ent, Microsoft SQL Server 2008 Ent. В настройках Microsoft SQL Server включили опцию Address Windowing Extensions (AWE). Уже на следующий день мы получили ошибку System.OutOfMemoryException, причем судя по Task Manager оперативная память была использована всего НАПОЛОВИНУ.
Исходя из всего этого, и множества советов в интернете(правда большинство советов относилось к работе программы 1С с SQL Server, но проблема была очень похожа на нашу) — решено было попробовать использовать x64 платформу и ПО.
На Этот же самый сервер (Hewlett Packard Proliant DL380G6 (2xXeonQC, 32Gb оперативной памяти)) была установлена операционная система Microsoft Windows Server 2008 R2 Enterprise x64, Microsoft SQL Server 2008 R2 x64, опция Address Windowing Extensions (AWE) выключена (кстати пришла идея попробовать включить и ее. ). Итог потрясающий.
Уже больше месяца мы не получали ошибки System.OutOfMemoryException, хотя оперативная память используется практически полностью!
Исходя из этого данный набор ПО считаем необходимым при одновременном доступе к SQL Server более 30 пользователей.
З.Ы. В ближайшее время попробуем включить опцию Address Windowing Extensions (AWE) и опишем результат!
Немного технической информации!
Механизм Address Windowing Extensions (AWE), используемый в SQL Server, состоит из двух частей, распределяющих физическую память и отображающую её на Virtual Address Space (VAS) данного процесса. Если физическая память распределена, то операционная система уже не сможет её затребовать, пока использующий её процесс не будет завершён или этот процесс освободит память, вернув её операционной системе. Приложение может управлять и даже полностью предотвращать листание. Преимущество механизма mapping/unmapping в том, что одна и та же физическая страница может быть отображена на разные участки VAS. На 64-х битных платформах в unmapping нет необходимости, поскольку VAS мы имеем достаточно, чтобы вместить всю имеющуюся физическую память.
Из теории операционных систем, для описания отображения страницы VAS на физические страницы, система оперирует записями таблицы страниц — Page Table Entry (PTE). Внутри физическая страница описывается номером блока страниц — Page Frame Number (PFN). Из PFN можно получить всю информацию о физической странице, которую он представляет. Например, PFN показывает, какому Non-Uniform Memory Access (NUMA) — узлу принадлежит эта страница. В операционной системе есть база данных, хранящая совокупность PFN, которыми система управляет. Если страница в VAS является закреплённой, существует PTE, который может указывать или не указывать на задействованные PFN. Концептуально, страница, которую представляет PTE, может быть в памяти или нет, например, если она выгружена на диск. В первом случае она привязана к задействованному PFN, а в последнем — нет. В свою очередь, как только физическая страница привязывается к странице в VAS, её PFN возвращаются PTE.
Когда операционная система закрепляет, освобождает, получает/отдаёт страницы задействованного PTE, или должна получить немного информации об этом (например аллокация NUMA), она должно задействовать блокировку рабочего множества процесса — чтобы обеспечить стабильность привязки PTE к PFN. Эта блокировка обходиться довольно дорого и может испортить масштабируемость процесса.
При распределении физических страниц, использование AWE механизма предоставляет нам набор записей PFN непосредственно из базы данных PFN. Операционная система обязана устанавливать блокировку на базу данных PFN во время распределения записей PFN. Используя механизм отображения AWE, Вы можете отобразить аллоцируемые записи PFN на VAS процесса. Когда происходит такое отображение, PTE аллоцируются, привязываются к PFN и отмечаются как блокированые. В этом случае операционная система должна разово установить блокировку рабочего множество процесса. При отображении обычных страниц, операционная система делает это по требованию и, следовательно, должна будет заполучить рабочее множество и установить блокировку в базе данных PFN для каждой страницы. Так как страницы в памяти блокированы, в момент листания эти PTE системой будет игнорироваться.
На 64-х битных платформах лучше называть такие страницы блокированными страницами (locked pages), и, пожалуйста, не путайте их со страницами, блокированными средствами VirtualLock API. Как было описано выше, у блокированных страниц есть два важных свойства — они не участвуют в листании, проводимом операционной системой, и во время распределения они захватывают рабочее множество и устанавливают разовую блокировку в базе данных для PFN.
Первое свойство имеет не очевидное влияние на высокопроизводительные системы, такие, как системы с архитектурой NUMA. Оно приводит к явной резидентности в памяти. Помните, что система закрепляет страницы по требованию. Для распределения физической памяти будет использоваться узел, на котором выполняется обращающийся к памяти поток. Только после этого страница может быть выгружена операционной системой во время свопинга. Далее, она может снова попасть в память, операционная система снова распределит физическую страницу узлу, на котором поток продолжает работать с этой памятью. В этом случае узел может оказаться уже совсем другим. Такое поведение приведет к дополнительной нагрузке на приложения, которые используют для страниц резидентность NUMA. Блокировка страницы позволяет разрешить эту проблему, полностью защищая их от листания.
Второе свойство — захват рабочего множества и блокировка в базе данных только PFN, дает возможность приложениям работать быстрее и повышает масштабируемость пилообразной нагрузки.
В NUMA архитектуре, SQL Server Buffer Pool фиксирует каждую распределенную страницу с выделенным для неё узлом. Достигается этого за счёт использования QueryWorkingSetEx. Как только страница распределена, вызывается этот API, который позволяет узнать детали резидентности страницы. Делается это только один раз. Поэтому включение locked pages для SQL Server на 64-х битной платформе улучшает работу с пилообразной нагрузкой и повышает производительность и масштабируемость на более длительных отрезках времени. При работе SQL Server в режиме locked pages, Вам не нужно больше волноваться о производительности системы в целом, зависимости от изъятия памяти у SQL Server, когда он участвует в механизме листания операционной системы, прослушивая оповещения отвечающего в системе за память API, и сокращая своё рабочее множество, когда это от него требуют.