У нас уже довольно долгое время возникают проблемы с нехваткой памяти на нашем смешанном классическом сайте ASP / .NET. По сути, мы видим несколько разных случаев:
У сбоев есть EventID: 1009, 1011 и 1013.
В обоих случаях ASP сообщает о нехватке памяти в нашем журнале приложения.
Если нам действительно не хватает памяти, почему пользователи УЖЕ в приложении могут работать, а новым пользователям запрещено даже входить в систему? Разве это не означало бы, что НИКАКИЕ запросы не могут быть обслужены?
Очевидно, что IIS все еще может служить некоторые запросы - так что ответ, вероятно, зависит от конкретного запроса. Может быть, один «дороже» другого?
В любом случае, мой главный вопрос - в какой момент пул приложений говорит, что достаточно, я ДОЛЖЕН переработать?
Мы запустили DebugDiag и увидели несколько куч, которые были фрагментированы более чем на 90% или даже на 100%, поэтому повторяется только тогда, когда фрагментация высока И нет больше места в куче?
Это немного субъективный вопрос, но я надеюсь, что смогу получить какие-то комментарии относительно того, что это за порог!
Спасибо.
Если рабочий процесс не нарушает один из заданных вами критериев перезапуска (ограничение виртуальных байтов кажется хорошим?) Или не отвечает на эхо-запросы, он не перерабатывается.
Приложения (ISAPI) могут сообщать о себе как о неисправных, что вызывает повторный цикл, но это происходит в довольно узких условиях.
Ваше приложение в основном фрагментирует память во время работы, и OOM отражает это - никаких бесплатных смежный, нераспределенная память доступна для новых распределений; они терпят неудачу.
Ваши варианты, основанные на описании:
исправить схему распределения
разделите части приложения на отдельные пулы приложений (например, запустите .Net отдельно от ASP) - не все приложения можно разбить таким образом, но это легкая победа для тех, кто может. Два пула приложений = 2 (или более) рабочих процесса = 2 ГБ на адресное пространство рабочего процесса
реализовать ограничение виртуальных байтов для повторного использования пула приложений, когда он становится слишком большим
реализовать ежедневную перезагрузку, чтобы приложение не добралось до точки, когда все его пространство памяти фрагментировано
если ваше приложение не имеет состояния, попробуйте веб-садоводство; увеличить максимальное количество рабочих процессов, чтобы дольше предотвращать сбой
Запускать как 32-битное приложение в 64-битной системе; Рабочим процессам предоставляется 4 ГБ.
По сути, если (что бы то ни было) куча стала супер фрагментированной, в этот момент вы находитесь в смертельной спирали и вам нужен новый рабочий процесс.
IIS не имеет встроенных ремней безопасности для этого, поэтому установите лимит повторного использования для вашего процесса, прежде чем он дойдет до этой точки - или просто скажите: «Забудьте об этом, я перейду на 64-разрядную версию!» могут быть возможные решения.