Когда я запускаю свое приложение, в профилировщике я вижу, что он использует около 80 МБ памяти (суммарные байт, счетчик производительности). Но когда я смотрю на размер выделенной памяти, это более 400 МБ!Почему .NET резервирует столько памяти для моего приложения?
Итак, мой вопрос: почему .NET резервирует столько памяти для моего приложения? Это нормально?
Как вы, несомненно, знаете, существует огромная разница между фактической памятью, используемой и выделенной. Выделенная память приложения не означает, что она фактически используется в любом месте; все это на самом деле означает, что ОС «маркирует» зону виртуальной памяти (которая именно такая - виртуальная) готова для использования приложением.
Память не обязательно используется или голодает другие процессы - это просто может, если приложение начнет ее заполнять.
Это выделенное количество, также, вероятно, будет масштабироваться по общей экосистеме памяти машины. Если есть много места, когда приложение запустится, тогда он, скорее всего, возьмет большее выделение, чем если будет меньше.
Этот принцип является тем же самым, что и тот, который говорит, что хорошей практикой является создание List<T>, скажем, с разумной начальной емкостью, которая будет означать, что приличное количество элементов может быть добавлено до изменения размера. ОС использует тот же подход с использованием памяти.
Это, действительно, я уже знаю, но спасибо в любом случае. Но мне все еще интересно, почему .NET хранит так много памяти. Если это было около 40 МБ или около того, хорошо, но я думаю, что 320 МБ в значительной степени! – Martijn
Это не просто .Net, ОС играет огромную роль в резервировании памяти. По сути, в окнах говорится: «У меня 16 ГБ физической памяти, я думаю, что я выделил 1 ГБ этому процессу ...» ** Для того же самого приложения *, другой машины ***, он может сказать: «У меня 4 ГБ физического ОЗУ, я выделил бы 200 МБ для этого процесса ... »Ни то, ни другое ничего не говорит о вашем приложении, инфраструктуре .net или чем-то еще. – NotMe
Вы должны прочитать Memory Mystery. Некоторое время назад у меня были подобные вопросы, и я перестала спрашивать себя, прочитав это. Я читал другие источники, но я не могу найти сейчас, использовать ключевые слова «необоснованное выделение окон ОС памяти». В двух словах, ОС дает больше, чем ваше приложение требует в зависимости от физически доступных ресурсов памяти , например. если вы используете свое приложение на двух машинах с разной оперативной памятью, можно гарантировать, что обе эти машины будут иметь разные распределения памяти.
Память «резервирования» ни в коем случае не такая же, как «выделенная» память. Читайте сообщения, с которыми связаны Стив и Кришна.
Часть вашего клиента, на которую нужно обратить внимание - это частные байты. Но даже это не так сложно, поскольку части вашего приложения могут быть заменены на виртуальный диск.
Короче говоря, если ваш раздел «Частные байты» не находится в отличном состоянии или у вас есть утечки (т. Е. Нераспределенные неуправляемые ресурсы), вы (и ваш клиент) должны игнорировать это и позволить ОС управлять выделенным, что находится в физическом ram и что выгружено на диск.
Для программного обеспечения достаточно распространять один большой запрос памяти на базовую операционную систему, а затем внутренне управлять собственным использованием выделенного блока памяти. Фактически, обычный диспетчер памяти Windows (и других операционных систем) явно поддерживает концепцию, называемую «незафиксированной памятью» - память, которую запросил процесс, но еще не использовал. Эта память действительно не существует, поскольку бит занимает место на чипах DRAM, пока процесс фактически не использует его. Предварительное распределение памяти фактически ничего не стоит.
Приложения делают это по многим причинам - хотя это в основном сделано по соображениям производительности. Приложение со знанием собственных шаблонов использования памяти может оптимизировать свой распределитель для этого шаблона; аналогичным образом, по причинам местоположения адресов, поскольку последовательные запросы памяти от ОС не всегда будут «рядом» друг с другом в памяти, что может повлиять на производительность кэша ЦП и может даже помешать вам использовать некоторые оптимизации.
.NET в частности выделяет пространство для управляемой кучи раньше времени по обеим причинам, перечисленным выше. В большинстве случаев выделение памяти в управляемой куче просто включает в себя увеличение указателя верхушки кучи, что невероятно быстро, а также не возможно с помощью стандартного распределителя памяти (который имеет более общий дизайн для приемлемого выполнения в фрагментированном куча, тогда как GC CLR использует сжатие памяти, чтобы резко ограничить фрагментацию управляемой кучи), а также невозможно, если сама управляемая куча фрагментирована через адресное пространство процесса из-за множества распределений в разные моменты времени.
сколько памяти у вашей машины? –
Это не имеет значения. У моих клиентов есть для пользователей максимальный максимум 200 МБ. Кроме того, я просто хочу знать, почему .NET делает это или почему так много :) – Martijn
[Это сообщение очень полезно] (http://www.itwriting.com/dotnetmem.php) – Steve