Кэш CQ5 IIS модуля диспетчера, возвращаясь 000003E9 и пустая страница
Сначала, как общее предложение, если для Вашего приложения определенно не нужно 64-разрядное обращение, выполняет его в 32-разрядном пуле приложений. Это естественно ограничивает использование памяти к 4 ГБ для каждого процесса.
Почему это могло бы быть важно? Ну, потому что 4 ГБ к 64-разрядному приложению являются погрешностью округления! Если платформа .NET не чувствует, что испытывает давление памяти, она не могла бы потрудиться выполнять сборку "мусора". Это не большой ответ, и я не знаю, почему это имело бы место под R2 и не R1, за исключением возможного ответа емкости памяти.
На Переработке: Переработка должна создать новый рабочий процесс по следующему запросу и по умолчанию дает старому до 90 секунд для завершения - переработка действительно перезапускает рабочий процесс (или по крайней мере, говорит WAS запускать новый WP в следующий раз, когда запрос прибывает и вежливо сообщает последнему WP, что это перерабатывается). Если Наложение Переработки не отключено, необходимо видеть новый w3wp с новым PID, как только следующий запрос на тот сайт получен.
Если Вы будете все еще видеть утечку в 32-разрядном пуле приложений, то необходимо будет диагностировать ее, поскольку утечка памяти - рассматривает взятие дампа памяти процесса, когда это находится в состоянии верхней памяти, и затем посмотрите на отладку ее с sos.dll или psscor2.dll для нахождения основного потребителя памяти.
Мне удалось найти ответ на форуме Adobe:
Мне не хватало этих шагов:
Вернитесь на сайт. И дважды щелкните Редактор конфигурации. В раскрывающемся списке Раздел выберите system.webServer / handlers. В поле «От» выберите сайт. Щелкните поле Count = и нажмите кнопку… Выберите CQ и измените requireAccess на None. Закройте и нажмите кнопку Применить (верхний / правый угол).
У меня похожая проблема, и я исправил ее, установив "требуемый путь" как * вместо *.* в окне "Edit Script Map" в Handler Mappings.