Назад | Перейти на главную страницу

w3wp.exe забирает память

При установке Small Business Server 2011 целое число процессов w3wp.exe использует непропорционально много памяти. Готовые установки SBS включают в себя 7 сайтов и 20 пулов приложений ASP.NET (Sharepoint, Exchange, WSUS и специфичные для SBS вещи, такие как Remote Web Workplace).

В результате дюжина процессов w3wp.exe со временем потребляет более 4 ГБ памяти сервера, при этом пиковым пулом приложений является пул WSUS с примерно 800 МБ в рабочем наборе. Ручная перезагрузка пулов приложений через IIS MMC помогает временно уменьшить использование памяти (процессы w3wp.exe сокращаются до 10 МБ, некоторые из них быстро восстанавливаются), но, очевидно, это не то, чем администратор хочет заниматься весь день. Мне не удалось найти никаких рекомендаций по автоматической перезагрузке пулов приложений, предустановленных SBS, поэтому я несколько неохотно «просто делаю это» в производственных системах.

Мое исследование в сети о том, как это ограничить, вызвало только ряд сообщений, в которых говорилось, что потребление памяти w3wp не повредит, но повысит производительность, поскольку память будет «освобождаться, когда это необходимо для других приложений». Беда в том, что не получается:

во-первых, SBS - это мультиролевой сервер, одна из ролей (основная) - сетевое хранилище CIFS, которое извлекает огромную пользу из кэширования файловой системы, которое опять же полагается на то, что память «свободна», как в «не используется другими процессами ни в каком путь »- пулы приложений ASP.NET, которые почти никогда не видят пользователей и съедают память, контрпродуктивны
Другое дело, что я все еще должен видеть значительное уменьшение потребления памяти экземплярами w3wp при нехватке памяти - я вижу незначительное уменьшение, значительно менее чем на 100 МБ, и вместо этого чрезмерное свопинг - снова в ущерб производительности

Я почти никогда не администрирую приложения IIS или ASP.NET, поэтому приветствуются любые идеи о том, как эффективно сократить требования к памяти для пулов приложений.

Вот что я в итоге сделал:

установка кэша серверных приложений для .NET AppPools на низкое значение (5 МБ) путем установки параметра privateBytesLimit в web.config в %WINDIR%\Microsoft.NET\Framework\<version>\Config как предложено в этот ответ:

    <configuration>
      <system.web>
         <caching>
           <cache privateBytesLimit="5242880" privateBytesPollTime="00:01:00" />
         </caching>
      </system.web>
    </configuration>

Это помогло снизить использование памяти до уровня, превышающего 1 ГБ, с настройками перезапуска пула по умолчанию.

Судя по всему, с помощью сборщика мусора "серверного" типа (<gcServer = "true">) может привести к значительному потреблению памяти тоже, но как кажется, <gcServer> по умолчанию установлено значение false.

Добро пожаловать в чудесный мир SBS. Рекомендуемые требования для ОЗУ = 10 ГБ ... и ТРЕБУЕТСЯ минимум 8 ГБ. (согласно Microsoft.) по уважительной причине. Это не отлаженная, хорошо смазанная машина ... она очень неряшливая, раздутая, и все, что находится под солнцем, связано вместе. Чем больше оперативной памяти вы загрузите в этот ящик ... тем лучше. К сожалению, вы ограничены максимумом 32 ГБ. Что имхо ... глупо.

Если вы подозреваете, что возникшее потребление памяти является проблемой из-за дефекта программного обеспечения, вы можете использовать Microsoft DebugDiag 1.2, чтобы создать полный дамп памяти и проанализировать дамп на предмет распространенных проблем. Если вы думаете, что может быть проблема с памятью, вам необходимо включить отслеживание утечек, выбрав опцию «Монитор утечек», и дать ему поработать некоторое время, прежде чем создавать / анализировать дамп.

DebugDiag 1.2 Скачать
https://www.microsoft.com/download/en/details.aspx?id=26798

Вам не нужен отдельный пул приложений для каждого приложения, только те, которые ненадежны или которым вы хотите отдать приоритет. Многие могут делиться (сохраняя разные версии .net отдельно). Затем вы можете более реалистично ограничить память, которую будет использовать пул приложений. Не должно быть необходимости повторно перерабатывать пулы более одного раза в день.

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

Проблема на самом деле в том, что SBS пытается сделать слишком много сразу, вам нужно посмотреть, что вы действительно используете, и отключить то, чего вы не делаете.

Но если честно для 11 пользователей, куда девается остальная память? Exchange и SQL для легкого использования, конечно, не необходимость более 12Гб!