Environment.WorkingSet неправильно сообщает об использовании памяти

Question

Environment.WorkingSet неправильно сообщает об использовании памяти для веб-сайта, работающего на Windows 2003 Server. (Версии ОС: Microsoft Windows NT 5.2.3790 с пакетом обновления 2, .NET Версии: 2.0.50727.3607)

Он сообщает память как рабочий набор (физическая память): 1952 МБ (2047468061).

Этот же веб-сайт работает локально в Windows Vista с рабочим набором (физическая память): 49 МБ (51924992).

У меня ограниченный доступ к серверу, и поддержка настолько ограничена :(. поэтому я вычислил общую память путем обхода с помощью VirtualQuery. Общее количество страниц с состоянием: MEM_FREE составляет 1300 МБ. (Я полагаю, что на сервере установлено 4 ГБ ОЗУ, а PAE не включен, максимальный виртуальный адрес в режиме пользователя - 0x7fff0000.)

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

Answer 1

Я думаю, что проблема связана с тем, что описано в этой статье :

4 мая 2005
Удовольствие с WorkingSet и int32
Наконец-то я нашел ошибку в добросовестности в .NET Framework.

... WorkingSet возвращает объем памяти, используемый процессом как целое число (32-разрядное целое число со знаком).Итак, максимальное значение целого числа равно 2 147 483 647 - что очень близко к общему объему памяти, который процесс может иметь в своем рабочем наборе.

... На самом деле в Windows есть переключатель, которыйпозволит процессу использовать 3 гигабайта памяти вместо 2 гигабайт.Этот переключатель часто включается при работе со службами Analysis Services - это может быть проблема с памятью.Итак, теперь происходит то, что когда я опрашиваю WorkingSet, я получаю отрицательное число, действительно большое отрицательное число.Обычно в области -2,147,482,342.

... Проблема заключалась в том, что бит переполнения.

Рабочий набор возвращается в платформу .NET в виде двоичного значения.Первый бит целого числа - бит знака.0 положительно, 1 отрицательно.Таким образом, когда значение изменено с (двоичного) 1111111111111111111111111111111 на (двоичное) 10000000000000000000000000000000, значение переходит с 2147483647 на -2147483647.

ОК, поэтому мне все еще нужно это исправить.Вот что я придумал (в C #):

long lWorkingSet = 0;
if (process.WorkingSet >= 0)
 lWorkingSet = processWorkingSet;
else
 lWorkingSet = ((long)int.MaxValue*2)+process.WorkingSet;

Надеюсь, это решит проблему на данный момент.

Реальный вопрос возникнет в будущем.Microsoft знает об этой проблеме.Я все еще должен выяснить, как они собираются это исправить для Win64 ... где этот трюк больше не будет работать.

---

http://msdn2.microsoft.com/library/0aayt1d0(en-us,vs.80).aspx:
Там будетПеременная Process.WorkingSet64, и они устарели WorkingSet.

На касательной, однако, я думал, что для управляемого процесса невозможно приблизиться к пределу в 3 ГБ, потому что среда выполнения разделяет память на несколько куч.Разве это не правда?

Answer 2

По предположению, Environment.WorkingSet, вероятно, возвращает значение из GetProcessWorkingSetSize, что в основном соответствует значению SetProcessWorkingSetSize. Это в основном то, что система выбрала как самый большой размер рабочего набора, который , как , чтобы увидеть для этого процесса, не обязательно связано с тем, сколько памяти она фактически использует. Основной эффект состоит в том, что когда / если процесс использует больше памяти, чем это, триммер рабочего набора системы начинает работать, чтобы увидеть, сможет ли он вывести часть своей памяти на диск.