Чрезвычайно высокий уровень активности активной памяти поискового вызова на диск, но низкий уровень использования постоянной памяти

Как указано в заголовке, у меня есть проблема с высокой работой файла с файлами.

Я разрабатываю программу, которая обрабатывает много изображений, которые она загружает с жесткого диска. На каждом изображении он генерирует некоторые данные, которые я сохраняю в списке. Для каждых 3600 изображений я сохраняю список на жестком диске, его размер составляет от 5 до 10 МБ. Он работает так быстро, как может, поэтому он максимизирует один поток процессора.

Приобретение памяти в программе, согласно диспетчеру задач, составляет около 50 МБ и кажется стабильным. Когда я запускал программу, у меня было около 2 ГБ, оставшихся без 4 ГБ, поэтому я думаю, что у меня не хватает ОЗУ.

http://i.stack.imgur.com/TDAB0.png

В описании правила DA0014 указано: "Количество страниц/количество страниц часто намного больше, чем число страниц Writes/sec, например, так как Pages Output/sec также включает в себя измененные страницы данных из кеша системного файла. Однако, не всегда легко определить, какой процесс несет прямую ответственность за пейджинг или почему.

Означает ли это, что я получаю это предупреждение просто потому, что читаю много изображений с жесткого диска, или это что-то еще? Не совсем уверен, какую ошибку я ищу.

РЕДАКТИРОВАТЬ: Ссылка на вставленный образ.

EDIT1: размер изображений составляет около 300 КБ каждый. Я сдачу каждого из них перед загрузкой следующего.

UPDATE: Выглядит из экспериментов, таких как пейджинг, просто загружая большое количество файлов. Поскольку я не являюсь экспертом в С# или базовом GDI + API, я не знаю, какой из ответов является наиболее правильным. Я выбрал Andras Zoltans, потому что это было хорошо объяснено, и потому что, похоже, он много работал, чтобы объяснить причину новичка вроде меня:)

Ответы

Ответ 1

Обновлено после более подробной информации

Рабочий набор вашего приложения может быть не очень большим - но как насчет размера виртуальной памяти? Пейджинг может произойти из-за этого, а не только из-за его физического размера. Смотрите этот снимок экрана из Process Explorer из VS2012, работающего в Windows 8:

А на диспетчере задач? По-видимому, частный рабочий набор для того же процесса - 305,376Kb.

Мы можем взять из этого: а) что диспетчер задач не может быть доверенным, и б) размер приложения в памяти, насколько это касается ОС, намного сложнее, чем мы хотели бы думать.

Вы можете взглянуть на это.

Подкачка почти наверняка связана с тем, что вы делаете с файлами и высокими конечными цифрами, почти наверняка, из-за количества файлов, с которыми вы работаете. Простым испытанием этого было бы экспериментировать с разным количеством файлов и генерировать набор данных окончательных персональных персонажей вместе с ними. Если количество файлов вызывает пейджинг, то вы увидите четкую корреляцию.

Затем выньте любую обработку (но сохраните загрузку изображений) и сравните ее снова - обратите внимание на разницу.

Затем полностью завершите код загрузки изображения - обратите внимание на разницу.

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

Теперь, глядя на код изображения Emgu.CV, он использует класс Image внутри, чтобы получить биты изображения, так что запуск GDI + с помощью функции GdipLoadImageFromFile (вторая запись этого индекса)) для декодирования изображения (используя системные ресурсы, а также потенциально большие массивы байтов) - и затем он копирует данные в несжатый массив байтов, содержащий фактические значения RGB.

Этот массив байтов выделяется с помощью GCHandle.Alloc (также окруженный GC.AddMemoryPressure и GC.RemoveMemoryPressure) для создания закрепленного байтового массива для хранения данных изображения (несжатого). Теперь я не специалист по управлению памятью .Net, но мне кажется, что у нас есть потенциал для фрагментации кучи здесь, даже если каждый файл загружается последовательно, а не параллельно.

Я не знаю, что вызывает жесткий пейджинг. Но это кажется вероятным.

В частности, представление изображения в памяти может быть специально ориентировано на отображение, а не на исходные байты файла. Так, если мы говорим о JPEG, например, тогда 300Kb JPEG может быть значительно больше в физической памяти, в зависимости от его размера. Например. 32-битное изображение размером 1027x768 составляет 3 МБ, и оно было выделено дважды для каждого изображения с момента его загрузки (первое выделение), а затем скопировано (второе выделение) в объект изображения EMGU до его размещения.

Но вы должны спросить себя, нужно ли искать способ решения проблемы. Если ваше приложение не потребляет огромное количество физической памяти, это будет иметь гораздо меньшее влияние на другие приложения; один процесс, поражающий многостраничный файл страницы, не будет сильно влиять на другой процесс, который этого не сделает, если имеется достаточная физическая память.

Ответ 2

Однако не всегда легко определить, какой процесс несет прямую ответственность за пейджинг или почему.

Дьявол находится в этой записке. Растровые изображения отображаются в память из файла, который содержит данные пикселя, используя файл с отображением памяти. Это эффективный способ избежать чтения и записи данных непосредственно в/из ОЗУ, вы платите только за то, что используете. Механизм, поддерживающий синхронизацию файла с ОЗУ, представляет собой пейджинг. Поэтому неизбежно, что если вы обработаете много изображений, вы увидите много ошибок страницы. Инструмент, который вы используете, недостаточно умен, чтобы знать, что это по дизайну.

Функция, а не ошибка.