rigorMortisДело не в объёме, а в динамике.
И какова динамика? Пока вижу "несколько суток" и 10 Мб. Это не динамика, это конечный результат измерения. Причем, очень даже приемлемый.

a_voronin

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

МСУнужно искать утечку

rigorMortisА с чего ты решил что нет?
А с чего ты решил, что да? Ты документацию когда последний раз открывал?

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

a_voroninУтечку на .NET? Вы батенька что-то попутали. Это не C++.
Нет, батенька, это вы что-то попутали.

https://msdn.microsoft.com/ru-ru/magazine/cc163491.aspx Обнаружение и предотвращение утечек памяти в управляемом коде

Понятие об утечках памяти в управляемых приложениях.

Использование неуправляемой памяти в приложениях .NET.

Помощь сборщику мусора .NET в его работе.



После прочтения материала продолжим разговор. А пока - учить матчасть. Твой уровень школьника мне не интересен :)

a_voroninМне кажется вам надо перечитать, как работает распределение памяти в .NET, и вот это решит проблемы.

a_voronin, а вот тут (для таких как ты) я запилил рецепт http://codearticles.ru/articles/1448 в котором говорится, что "никогда не вызывайте сборщик мусора и не вмешивайтесь в его работу". Ну только если ты не решил запилить свой коллектор и составить конкуренцию MS

Самое ценное в статье Ковача - это заключение.

https://msdn.microsoft.com/ru-ru/magazine/cc163491.aspx Заключение: В настоящей статье рассматриваются различные проблемы, которые возникают в приложениях .NET и могут стать причиной утечек памяти или чрезмерного потребления памяти. Конечно, .NET в большой мере избавляет от забот о памяти, но чтобы быть уверенными, что приложение работает правильно и эффективно, нужно внимательно следить за тем, как оно использует память. Тот факт, что приложение является управляемым, не означает, что нужно выбросить и забыть профессиональные навыки и накопленный опыт разработки и отладки программных систем, полностью положиться на сборщик мусора и ждать, что он сотворит чудеса . Разрабатывая и отлаживая приложение, нужно постоянно следить за значениями счетчиков, которые характеризуют эффективность использования памяти.


Так что, a_voronin, самое время для изучения .NET :)

ИзопропилМСУ, никогда не говори никогда
На своей памяти помню только одно применение с подзним связыванием на офисном интеропе (которому место на помойке), ну ты понял, о чем я :) Больше в жизни не встречал ситуации, когда нужно это явно делать.

a_voroninБоюсь, что на .NET я программировал уже слишком долго с первой версии ещё. GC.Collect использовал в боевом коде, использовал не раз, знаю результат. То, что кто-то написал, что сборщик мусора не надо вызывать, это его личное мнение, которое я лично проигнорирую.
Боюсь, что ты просто облажался и тебе откровенно стыдно это признать. Остальные сопли по поводу твоего "долголетнего опыта" оставлю без комментариев.

a_voroninБоюсь, что я написал хороший качественный код, который уже 8 лет используется на американском сайте международного уровня с высоким доступом и он бы до сих пор валился без GC.Collect.
Я не могу судить о качестве твоего кода, который уже 8 лет используется на американском сайте международного уровня с высоким доступом. Потому что у меня нет этого кода. Но я могу судить о твоих знаниях, особенно когда вижу удивление о том, что в .NET якобы не могут быть утечек. Твой перформанс про

a_voroninУтечку на .NET? Вы батенька что-то попутали. Это не C++

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

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

a_voroninА ты можешь дальше носиться с идеей о том, что сборку мусора принудительно вызывать не надо. До свиданья. Я таких как ты на собеседованиях сразу заворачиваю.
Я носиться никуда не буду. Я буду помнить о том, что не перевелись еще неофиты, которые думают, что в .NET утечек не бывает.

a_voroninЯ таких как ты на собеседованиях сразу заворачиваю.
Мне страшного представить проф пригодность компании, где человека с нулевыми знаниями по .NET допустили собеседовать разработчиков. Заверни лучше голову свою в ковёр, клоун

a_voroninЭто оскорбление. С хамом больше общаться не буду.
Ты лучше бы не строил из себя девственницу, а честно признал, что был не прав. Профессионалы тоже иногда ошибаются, ничего тут страшного нет. Но ты продолжаешь включать дурака и лить крокодильи слёзы. Будь мужиком уже, в самом-то деле.

a_voroninСначала ты придумал, что я что-то имел ввиду, потом сделал какие-то выводу о моём уровне, на основе того, что сам сообразил, теперь на основе этой своей выдумки хамишь. до свиданье господин воображалкин.
Я придумал, что в .NET не бывает утечек? Я придумал, что .NET это не C++? Я начал хамски поучать перечитать, как работает распределение памяти в .NET? Я тебе дал ссылку и аргументировал твою неправоту. О каких выдумках ты тут вещаешь?

a_voroninНу то, что распределение памяти на C++ и NET отличается ты, я надеюсь, отрицать не будешь. То, что память не подлежит сборке на .NET, пока на неё есть ссылка, ты тоже отрицать не будешь. То, что в MSDN есть пример использования GC.Collect ты тоже отрицать не будешь? https://msdn.microsoft.com/en-us/library/xe0c2357(v=vs.110).aspx
Речь не в отличиях распределения памяти. Есть такое понятие, как очистка неуправляемых ресурсов. Используй безопасный дескриптор в качестве оболочки для неуправляемого ресурса. Это рекомендуемая методика. Безопасные дескрипторы это наследники SafeHandle. GC.Collect не панацея, тебе выше уже сказали. Никто никаких гарантий не даст в управлении черным ящиком. Почему это так, я тебе дал ссылку на рецепт с подробным описанием.

a_voroninТеперь скажи мне, уважаемый разработчик, архитектор или кто ты. Вот ты лопатишь какие-то данные в цикле. Лопатишь долго. Читаешь файл, например, делаешь кучу операций со строками и записываешь в другой файл. Что будет происходить с памятью. Вот пройдёт 100000 витков этого цикла, а память накапливается. Тебе уже не нужны все эти строки и промежуточные значения, ты их записал в выходной файл. Но они висят в памяти. Как действовать? Какой тут сценарий без GC.Collect -- я внимательно послушаю?
Во-первых, откуда в цикле взялось накапливание? Ведь я могу читать ридером прямо из источника (соединение с БД, xml, http, порты, сокеты и так далее) мимо памяти. И сразу же свопить куда-то в базу. В результате, никакого оверхеда в виде накапливания. Память не засирается, процесс происходит чисто и без шума. Какой нахрен GC.Collect? С твоими архитектурами только кур смешить. И да, почитай, что такое no tracking фетч. Поможет.

a_voroninОпять на личности переходишь и опять придумываешь то, чего нет.
Что именно я придумываю? Ты сгенерил какой-то упоротый пример для ламеров и предлагаешь его по-ламерски решать. Ты из какого курятника вылез, начальник?

a_voroninРассмотрим задачу, где данные не сохраняются как есть. Понятно, что из одного потока в другой направить, это не вопрос. Допустим надо не как есть сохранять, а что-то делать ещё с теми данными, которые иду по потоку. Считать, трансформировать. Но не накапливать.
Ну считывай последовательно и трансформируй. Курсоры могут не только однонаправленные, если что. Память засирать вовсе не обязательно. А ты предлагаешь засрать всю память, а потом сделать чудо с помощью GC.Collect и радоваться? Уверяю, это удел кодирующих обезьян (code monkey), а не профессионала. Десятый раз повторяю, GC.Collect в 99.9% прикладных задач не нужен. Вообще не нужен.

a_voroninМожет быть сейчас .NET оптимизировали, но некоторое число лет назад это наблюдалось. Поэтому и требовался принудительный GC.Collect.
Никогда он не требовался, не фантазируй. Грамотный код и корректные алгоритмы всегда справлялись без этого magic подхода.

a_voroninВот и всё, что я хотел сказать.
Ты научись сначала с дотнетом работать прямыми руками, а там, глядишь, и GC.Collect не понадобится. Вообще не понадобится.

ЕвгенийВТот редкий случай, когда МСУ полностью прав. Видимо затмение сказывается :)
А судьи-то кто? Школота и обезьянки? Спасибо, повеселил

ЕвгенийВЭкс-глава Минсельхоза Елена Скрынник.
Ну хоть не Андрей Киска.

a_voroninДля начала надо не быть столь откровенным хамом.
Это ты про свой ответ 17402256 на счет того, что я попутал и что мне надо перечитать, как работает распределение памяти? Забавно.

a_voroninТакой человек может и знает многое, но в коллективе он опасен, поскольку от его демонстрации превосходства начнут уходить те, кто делает работу, а будет ли он делать работу еще большой вопрос.
Тебя понесло не в ту степь, начальник. Какое превосходство, какой коллектив? Если ты не умеешь общаться с людьми, не надо переваливать с больной головы на здоровую. Если бы ты уважительно задал вопрос, а не стал выё..ться, я бы тебе уважительно ответил, как нормальному мужику. А когда ты по-хамски начал ерничать, а потом женские обиды кидать, а потом еще и идиотские кейсы приводить с переполнением памяти в цикле, так это вообще цирк. Вместо того, чтобы остановиться и осознать свою ошибку, ты начал дальше и глубже себя закапывать в яму. И где тут моя вина, начальничек?

a_voroninИ я не надо быть столь наивным, чтобы считать, что он всегда прав. Вот это тоже считаете бредом, например? 9372672
Давай по теме, начальник. Прав или не прав, какая разница. Будь проще.

a_voroninДа я-то попроще.
Как-то незаметно.

a_voroninПоражает твоя мания "читать между строк", то есть вкладывать в слова смысл, которого в них нет.
Поражает твоя мания защищаться, когда не прав. Сначала пыль в глаза пустил по поводу женских обид и крокодильих слёз, потом начал заднюю включать какими-то жалкими примерчиками с циклами, теперь вот меня обвиняешь во всех смертных. Виноват кто угодно, но только не я - вот твой подход.

a_voroninВот интересно, где я сказал, что являюсь или был начальником?
Я где-то сказал, что ты большой? Опять ты генеришь несуществующие кейсы.

a_voroninМСУкакими-то жалкими примерчиками с циклами
Я попытался тебе показать, что есть особые ситуации, а ты говоришь нет и не может быть.
А я тебе ответил, что твои ситуации - это откровенная дурость. Нормальный разработчик никогда не будет писать во всю доступную память, просаживая все мыслимые и не мыслимые перформансы. Нормальный разработчик будет работать с такими данными только через ридеры и прочие no tracking алгоритмы, без оверхеда в память. Оверхед еще приемлем порциями от 0.2 - 0.5 Гб занимаемой памяти, но полностью всё засвопить в RAM и файл подкачки - это удел упоротых оленеводов.

a_voroninТы воспринимаешь всё так, как будто я предлагаю всегда GC.Colltcy дергать. А я этого не предлагаю. Говорю, что есть лишь редкие ситуации, где это моет понадобиться.
Я утверждаю, что GC.Collect вообще не нужно дергать. Кроме случаев, когда ты реализуешь свой коллектор. Использование GC.Collect говорит о том, что ты малопригодный программист, не понимающий как оно работает и почему так происходит. Таким недопрограммистам и приходится рассчитывать на магию черного ящика GC.Collect. Особенно забавит факт, что эти недопрограммисты уверяют других в том, что последние ничерта не понимают в распределении памяти Это вообще цирк!

a_voroninА вот если тебе надо использовать код, который ты не писал и который не знаешь как написан, или еще хуже если есть приказ от очень тупого начальника -- там ничего не менять, потому что "нам за это не платили". Прочитал из потока, передал в плагин по интерфейсу, забрал результат, записал в поток. И вот у тебя память начинает выжираться. Вот как ты поступишь?
Никак не поступлю. Не буду использовать стороннее гавно, которое положит набок наш продакшен сервер. И, слава Богу, я еще ни разу в жизни не встречал таких упоротых руководителей, которые "приказывали" использовать малонадёжное гавно, способное убить наши системы. Таким "начальникам" не место в IT. Им место где-нибудь в курятнике. Я так понимаю ты из таких начальников? Тогда всё ясно, дальше можешь не продолжать.