Здравствуйте, Igor Trofimov, Вы писали:
M>>А с чего ты так решил?
iT>А в TaskManager посмотрели.
В TaskManager посмотрели ты видишь не выделенную а зарезервированную память. Сам не пробовал но читал, что если сложить всю выделеннум память под процессы видимую в
TaskManager то ее будет намного больше. Просто резервируются адреса для дальнейшего использования. Кстати эффект уменьшения памяти в TaskManager можно замечать при сворачивании приложения или воспользоваться SetProcessWorkingSetSize например в http://www.gotdotnet.ru/DotNet/FAQ/CommonForum/524.aspx
А вот если данные манипуляции не помогут то тогда уже рыть ....
и солнце б утром не вставало, когда бы не было меня
зависает на второй строке... отчего это может быть?
2. Выяснилось (спасибо хорошей утильке под названием .net memory profiler), что основной объем памяти отжирает некий System.DirectoryServices.Interop.AdsValueHelper. действительно, прога регулярно обращается к AD, но при этом я делаю using для всего, что шевелится.. тьфу.. для всего, что IDisposable..
Тем не менее этих самых AdsValueHelper накапливается сотни тысяч, они не умирают, и судя по stack trace'ам (которые показывает та же утилька) их создают внутренние механизмы классов DirectoryServices при работе обычных (не IDiposable) SearchResultCollection, .
Что посоветуете? Сталкивался ли кто-то с такой проблемой при работе с AD?
iT>зависает на второй строке... отчего это может быть?
Кстати в этом же номере Джеффри Рихтер http://www.microsoft.com/rus/msdn/magazine/archive/2003-01/dotnet.asp
Как раз рассматривал GC.WaitForPendingFinalizers; при взаимной блокировке.
Скорей всего, чтото в финализаторе блокируется.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Igor Trofimov, Вы писали:
iT>2. Выяснилось (спасибо хорошей утильке под названием .net memory profiler), что основной объем памяти отжирает некий System.DirectoryServices.Interop.AdsValueHelper. действительно, прога регулярно обращается к AD, но при этом я делаю using для всего, что шевелится.. тьфу.. для всего, что IDisposable..
Самое интнресное, что у этого System.DirectoryServices.Interop.AdsValueHelper нет
IDisposable, но есть Finalize который должен перекрываться в наследниках.
S> Самое интнресное, что у этого System.DirectoryServices.Interop.AdsValueHelper нет S>IDisposable, но есть Finalize который должен перекрываться в наследниках.
В каком смысле — "должен перекрываться в наследниках"? Он вроде и так все, что нужно — делает..
Вот только почему-то не умирают эти самые AdsValueHelper'ы ;(
Здравствуйте, Igor Trofimov, Вы писали:
S>> Самое интнресное, что у этого System.DirectoryServices.Interop.AdsValueHelper нет S>>IDisposable, но есть Finalize который должен перекрываться в наследниках.
iT>В каком смысле — "должен перекрываться в наследниках"? Он вроде и так все, что нужно — делает.. iT>Вот только почему-то не умирают эти самые AdsValueHelper'ы ;(
Тогда откуда должен вызываться Finalize, т.к. он протектед.
А вообще он сборочный, а ссылки на него из сборкин нет ни их одного класса.
Надо смотреть откуда он создается.
и солнце б утром не вставало, когда бы не было меня
Finalize вообще-то всегда protected. CLR это не мешает
S> А вообще он сборочный, а ссылки на него из сборкин нет ни их одного класса. S>Надо смотреть откуда он создается.
profiler говорит, что создается он в SearchResultCollection.ResultsEnumerator.GetCurrentResult()
а еще в DirectorySearcher.SetSearchPreferences(...).
Смотрю Reflector'ом — и там и там действительно создается экземпляр этого типа (не потомка), (так что Reflector зря не показывает ссылку на этот тип).
Здравствуйте, Igor Trofimov, Вы писали:
iT>Блин, что же делать? iT>неужели никто не работал массировано с AD и не наталкивался на эти траблы?
Ради подддержания двнного топика...
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Igor Trofimov, Вы писали:
iT>Finalize вообще-то всегда protected. CLR это не мешает
Прошу прощения. Пить мне надо меньше. Конечно же это деструктор, а Finalize формируемый автоматом.
И самое противное, что без IDisposable вызывается только при сборке мусора, и никакие using не помогут.
И здесь интересно
GC.Collect;
GC.WaitForPendingFinalizers;
GC.Collect;
зависает на второй строке... отчего это может быть?
Зависает бог с ним. А после него память высвобождается???
и солнце б утром не вставало, когда бы не было меня
Нужно повключать побольше колонок в Task Manager'е и прикинуть, что вообще каждая из них означает.
Увеличение какого-то показателя не обязательно говорит об утечках и т.п. Это разве что повод задуматься, но не разворачивать бурную деятельность по оптимизации "под TaskManager".
Вообще, трудно диагностируемые утечки бывают к примеру в таких случаях:
Неадекватная работа с COM.
Работа с БД Access.
Непродуманное использование Reflection.Emit, CodeDom и подключаемых сборок-плугинов.
Слишком широкое использование компилируемых регекспов.
Здравствуйте, Igor Trofimov, Вы писали:
S>>И здесь интересно S>> GC.Collect; S>> GC.WaitForPendingFinalizers; S>> GC.Collect; S>> Зависает бог с ним. А после него память высвобождается???
iT>Не-а.
То есть профайлер показывает то же количество этих долбанных объектов????
А если несколько раз коллектнуть???
И в чем могут быть проблемы???
if (this.pinnedHandle.IsAllocated)
{
this.pinnedHandle.Free();
}
или base.Finalize();
и солнце б утром не вставало, когда бы не было меня
iT>зависает на второй строке... отчего это может быть?
Например, в каком-нибудь финализере или Dispose стоит lock. Или что-нибудь похожее на более низком уровне.
Постарайся не разбрасываться объектами по разным потокам, может поможет. На крайний случай можно вообще отдельный AppDomain для продолжительных гнусностей создавать. Оно и ссылки подчистит.
Ага, может они память пинуют и не сразу распинуют?!
Я тут недавно кидал ссылку на похожую проблему в System.Net.Socket, которая будет исправлена в Widbey.
Пока память запинована, GC не может освободить всё, что следует перед этим пинованым указателем в куче. Поэтому не рекомендуется пиноваться слишком часто. Возможно, мелкософтовцы это прохлопали.
В общем, если кому интересно, вынес я работу с AD в отдельный AppDomain и все стало шоколадно. Поработал — грохнул. Поработал — грохнул.
На досуге надо будет еще проверить на маленьком тесте — действительно ли любое использование AD блокирует сборку мусора или это у меня какое-то особо неприятное стечение обстоятельств было.
