Огромный всплеск памяти в c # service, в чем может быть причина? - PullRequest
3 голосов
/ 27 апреля 2010

Я работаю над приложением-службой c #, и у меня есть эта проблема, где из ниоткуда и без видимой причины память для процесса вырастет с 150 МБ до почти 2 ГБ примерно за 5 секунд, а затем обратно до 150 МБ. Но ничто в нашей системе не должно использоваться где-то рядом с таким количеством памяти (так что, возможно, это где-то ошибка) Это может быть где-то жесткая, но в то время загрузка процессора была очень низкой, поэтому я подумал, что я буду искать другие идеи.

Теперь более странно то, что, когда я компилирую сервис для 64-битной системы, произойдет тот же массовый пакет, за исключением того, что он превысил 10 ГБ ОЗУ (большая часть страниц), и это просто вызвало множество проблем с компьютером и всем, что работает на нем. Через некоторое время он выключается, но похоже, что Windows все еще хочет выделить ему больше памяти.

У вас есть идеи или инструменты, которые я могу использовать, чтобы найти это? Да, в нем много журналов, но в журналах ничего не говорится о том, почему это происходит.

Я могу запустить службу в режиме консольного приложения, поэтому мой следующий тест собирался запустить ее в отладчике Visual Studio и посмотреть, смогу ли я найти что-нибудь.

Это происходит только изредка, но обычно через 10-20 минут после запуска. В 32-битном режиме он очищается и продолжается как обычно. В 64-битном режиме происходит сбой через некоторое время, и он использует глупые объемы памяти. Но я действительно озадачен тем, почему это происходит !!!

РЕДАКТИРОВАТЬ: Пожалуйста, смотрите комментарии к сообщению windbg

Ответы [ 3 ]

2 голосов
/ 27 апреля 2010

Вы можете попробовать профилировщик, например CLRProfiler, бесплатную загрузку с MS (это довольно круто). Это может профилировать услуги. Запускайте его, пока не увидите скачок памяти, затем остановите его и посмотрите на дамп кучи.

1 голос
/ 27 апреля 2010

Вы делаете много выделений, которые затем освобождаете. Ваша память накапливается до тех пор, пока GC не включится и не начнет чистку после вас. На платформах amd64 все структуры больше, так как указатели, v-таблицы и другие структуры по своей природе в два раза больше по сравнению с x86.

Самое простое решение - запустить приложение под отладчиком и дождаться выпуклости, затем заморозить его и создать дамп. Затем проанализируйте дамп:

.loadby sos mscorwks
!dumpheap -stat

Ваш просочившийся тип будет в верхней части списка с большим количеством выделений. Это тот же метод, который вы использовали бы для анализа утечки памяти, за исключением того, что память, вероятно, технически не утечка, см. Утечка памяти CLR .

0 голосов
/ 27 апреля 2010

Звучит так, как будто вы делаете конкатенацию строк вместо использования StringBuilder?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...