Как ограничить память, которая может быть выделена определенным классом?

Я загружаю несколько внешних сборок в свое приложение во время выполнения. И мне нужно ограничить количество памяти, которое может использовать конкретный класс, который определен в каждой из внешних сборок, например, 10 мб на инстанс, иначе мы получим OutOfMemory.

Я погуглил, как это сделать лучше всего, и нашел некоторую информацию о среде выполнения CLR. Хостинг. Вроде бы то, что мне нужно, но хороших примеров найти не могу.

Может ли кто-нибудь поделиться примерами кода или, может быть, некоторыми ссылками об управлении памятью с помощью CLR Runtime Hosting? Или, может быть, есть какие-то лучшие решения для ограничения объема памяти на класс?

Заранее спасибо.


.net memory-management clr clr-hosting
person Andrey    schedule 30.01.2011    source источник
comment
Это интересная тема. Однако, не могли бы вы подробнее объяснить почему для каждого класса? Может быть, есть какое-то другое очевидное решение, если вы разблокируете свое мышление от экземпляров класса.   -  person Ondrej Tucny    schedule 30.01.2011
comment
На самом деле не так важно ограничивать по классам. Класс точного типа - единственное, что я собираюсь создать, поэтому мои мысли были "заперты" с экземплярами класса :). Я могу сделать это, например, в домене приложения (создать каждый экземпляр в домене приложения), но я не могу найти способ ограничить память для каждого домена приложения :(. Моя цель - как-то ограничить память, которая доступна для «внешнего разработчик».   -  person Andrey    schedule 30.01.2011

Ответы (2)


arrow_upward
4
arrow_downward

Это не то, что вы сможете сделать через CLR Hosting. Если вы размещаете CLR, вы можете выполнить требования по распределению от GC до Windows, например. так что вместо VirtualAlloc он использует какой-то другой аллокатор. Однако хост не вызывается каждый раз при выделении объекта (это было бы слишком дорого).

Теоретически это можно сделать с помощью CLR Profiling API. Это позволяет вам получать обратный вызов всякий раз, когда объект выделяется.

Боюсь, однако, что вы пытаетесь посмотреть на это с неправильной точки зрения. Вместо того, чтобы ограничивать объем памяти, используемый экземплярами класса, который является очень гранулированным, не могли бы вы вместо этого попытаться изолировать эти внешние сборки в отдельные процессы, возможно, даже ограничив их с помощью API Win32 Job Object?

person Sasha Goldshtein    schedule 30.01.2011
comment
Теоретически таких сборок может быть сотни и они находятся в каком-то взаимодействии. Вот почему я боюсь выделять каждый из них в отдельный процесс. Но, конечно, если нет больше вариантов ограничения памяти, кроме как для каждого процесса, у меня нет выбора :) Спасибо за ответ. - person Andrey; 30.01.2011
comment
По моему опыту, стандартной процедурой в таких случаях будет запуск нескольких сборок плагинов в отдельном процессе, возможно, каждая в отдельном AppDomain. В общем, у вас, вероятно, есть свой код, которому вы доверяете, и другой код, которому вы не доверяете, поэтому уровней изоляции не так много. - person Sasha Goldshtein; 30.01.2011

arrow_upward
0
arrow_downward

Если вы стремитесь ограничить потребление памяти отдельным процессом, я думаю, вам следует использовать свойство MaxWorkingSet класса Process. См. http://msdn.microsoft.com/en-us/library/system.diagnostics.process.maxworkingset.aspx для получения подробной информации

person Anton Semenov    schedule 30.01.2011
comment
Моя цель - ограничить объем памяти для каждого конкретного экземпляра класса в 1 процессе. - person Andrey; 30.01.2011
comment
Проверьте этот поток stackoverflow.com/ вопросы/4752439/ - person Anton Semenov; 30.01.2011
comment
Я нашел только способ определить, сколько памяти уже используется. Но мой вопрос заключается в том, как запретить внешнему «разработчику» использовать больше, чем, например, 10 мб. Я не могу позволить выделить все, а затем проверить, сколько памяти выделено. - person Andrey; 30.01.2011
comment
Вы можете попробовать API профилирования как вариант msdn.microsoft.com/en-us/magazine /cc300553.aspx - person Anton Semenov; 31.01.2011