foreach загадочно зависает на первом элементе ResourceSet

Question

Иногда наш сайт замедляется, а использование ОЗУ растет очень высоко. Затем пул приложений останавливается, и я должен перезапустить его. Тогда это нормально в течение нескольких дней, прежде чем ОЗУ внезапно всплескивает снова, и пул приложений скоро остановится. Процессор невелик.

Перед остановкой в ​​приложении, я заметил, что одна из наших страниц всегда зависает. Линия она висит на это Еогеасп на ResourceSet:

var englishLocations = Lang.Countries.ResourceManager.GetResourceSet(new CultureInfo("en-GB"),true,true); 
foreach(DictionaryEntry entry2 in englishLocations) // THIS LINE HANGS 

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

Плохой коробки

• Окно Server 2008 R2 Стандартный SP 1
• IIS 7.5.7600.16385
• .NET 4.5
• 24 ГБ RAM

Хорошо поле

• Window Server SP 2008 Сервер 2
• IIS 7.0.6000.16386 SP 2
• .NET 4.0
• 24ГБ RAM

Я пытался добавить UploadReadAheadSize = "0" в web.config, как описано здесь:

http://rionscode.wordpress.com/2013/03/11/resolving-controller-blocking-within-net-4-5-and-asp-net-mvc/

Что не сработало.

Зачем нужно было искать? Он висит на самом первом предмете, фактически на foreach.

Спасибо.

Answer 1

На основании другого ответа, чтобы дать вам некоторое представление о том, как использовать модель try catch? Возможно, он висит, потому что ресурс разве доступные/заблокированные /..permissions т.д.

var englishLocations = Lang.Countries.ResourceManager.GetResourceSet(new CultureInfo("en-GB"),true,true); 
foreach(DictionaryEntry entry2 in englishLocations) // THIS LINE HANGS 



ResourceManager CultureResourceManager = new ResourceManager("My.Language.Assembly", System.Reflection.Assembly.GetExecutingAssembly()); 
ResourceSet resourceSet = CultureResourceManager.GetResourceSet("sv-SE", true, true); 
try { resourceSet.GetString("my_language_resource");} 
catch (exception ex) { // from here log your error ex to wherever you like with some code } 

Answer 2

я испытал очень подобную проблему.

Время от времени IIS зависает, и я вижу, что количество запросов просто сидит там. Все они находились в состоянии ExecuteRequestHandler и с именем модуля ManagedPipelineHandler.

После исследования с помощью проводника процессов я мог видеть, что все они сидели в mscorlib.dll!ResourceEnumerator.get_Entry, дополнительная трассировка стека предложила некоторое действие NGen, а затем ntdll.dll!WaitForMultipleObjects.

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

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

private static readonly object ResourceLock = new object(); 

public static MvcHtmlString SerializeGlobalResources(this HtmlHelper helper) 
{ 
    lock (ResourceLock) 
    { 
     // Existing code goes here .... 
    } 
} 

Answer 3

Я знаю, что это старый пост, но тем не менее ... Существует потенциал тупика при переборе по ResourceSet и в то же время получения какой-либо другой объект через из одних и тех же ресурсов.

Проблема заключается в том, что при использовании ResourceSet итератор вынимает замки на внутреннем кэше ресурсного ResourceReader http://referencesource.microsoft.com/#mscorlib/system/resources/resourcereader.cs,1389, а затем в методе AllocateStringNameForIndex вынимает замок на самом читателе: http://referencesource.microsoft.com/#mscorlib/system/resources/resourcereader.cs,447

lock (_reader._resCache) { 
    key = _reader.AllocateStringForNameIndex(_currentName, out _dataPosition); // locks the reader 

Getting объект вынимает те же замки Int обратного порядка:

http://referencesource.microsoft.com/#mscorlib/system/resources/runtimeresourceset.cs,300 и http://referencesource.microsoft.com/#mscorlib/system/resources/runtimeresourceset.cs,335

lock(Reader) { 
    .... 
    lock(_resCache) { 
     _resCache[key] = resLocation; 
    } 
} 

Это может привести к тупику. Недавно у нас был этот точный вопрос.