Использование памяти в пуле приложений в IIS 6

Question

У меня есть сайт с простой страницей. При щелчке по кнопке мы выполняем запрос MDX, который возвращает около 200 000 строк с 20 столбцами. Я использую следующий код для выполнения MDX запроса с использованием библиотеки Microsoft.AnalysisServices.AdomdClient (версия 10.0.0.0 выполнения версия v2.0.50727)

 var connection = new AdomdConnection(connectionString); 
     var command = new AdomdCommand(query, connection) 
     { 
      CommandTimeout = 900 
     }; 

     connection.ShowHiddenObjects = true; 
     connection.Open(); 
     var cellSet = command.ExecuteCellSet(); 
     connection.Close(); 

Хотя запрос выполнения usgae памяти пула приложений идет очень высоко.

Это начальное состояние использования памяти на сервере:

После выполнения запроса:

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

Какие варианты я должен выяснить, что держит память?

Есть ли явный способ снять эту память?

Разве библиотека ADOMD всегда потребляет много памяти? Есть ли у нас альтернативные варианты выполнения запросов MDX с использованием C#?

Когда память usgae достигает этого максимума, IIS прекращает обработку других запросов, и приложение, размещенное на том же сервере IIS (с использованием другого пула приложений), также подвергается воздействию, и запрос занимает больше времени для выполнения.

Answer 1

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

Ваши варианты, чтобы выяснить, Что держит памяти являются:

1. Скачать профайлер памяти, таких как Муравьи профилировщика RedGate, и что позволит вам увидеть, что происходит в App бассейне. Однако это всего лишь двухнедельный пробный период, но позволит вам увидеть, что происходит на начальном этапе.

2. Получите доступ к CLR Profiler, этот инструмент можно загрузить и просмотреть моментальные снимки памяти, чтобы вы могли узнать, что находится в памяти в CLR.

Одна вещь, чтобы быть в курсе является большой объект кучи, по конструкции CLR не компактное пространство в LOH и поэтому, если объекты ставятся там то, что может привести к фрагментации памяти. Там размещаются объекты размером более 85000 байт. Одним из примеров являются большие списки объектов.

Одна вещь, которую я пробовал сделать, чтобы обойти ее, - создать специализированную коллекцию, такую ​​как составной список, который в основном представляет собой список списков, а затем, когда каждый список компонентов находится под 85000 байт, он останется в нормальной куче и весь объект промахивается в LOH. Другие тоже упомянули об этом.

Это говорит, что у меня все еще есть проблемы, так как составной список на самом деле не разобрался с проблемой, поэтому в игре все еще есть другие факторы, которые необходимо решить. Я озадачен этим и думаю, что дамп памяти пула приложений и анализ с помощью winDbg могут дать дополнительные ответы.

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