Iis увеличить объем памяти под сайт

Обновлено: 24.01.2025

Веб-сервер IIS, как среда выполнения веб-приложения, имеет некоторое влияние на общую производительность. Например, чем короче конвейер обработки запросов в IIS, тем меньше кода будет выполняться и тем выше будет скорость работы. В IIS имеются механизмы, которые можно использовать для увеличения производительности приложения за счет снижения задержек и увеличения пропускной способности, а также некоторые механизмы, которые при правильной настройке могут увеличить общую производительность приложения.

Кэширование вывода

В IIS имеется два механизма кеширования: кеш в пространстве пользователя и кеш в пространстве ядра.

Кеширование в пространстве пользователя

Чтобы настроить кеширование, откройте приложение IIS Manager, выберите свое веб-приложение, откройте настройку Output Caching (Кеширование вывода), щелкните на ссылке Add (Добавить) в панели Actions (Действия), чтобы добавить новое правило кеширования, или выберите существующее правило для редактирования.

Чтобы создать новое правило кеширования в пространстве пользователя, добавьте новое правило, введите расширение имен файлов, которые требуется кешировать, и отметьте флажок User-mode caching (Кеширование в режиме пользователя) в диалоге Add Cache Rule (Добавить правило кеширования), как показано на рисунке ниже:

Кеширование в пространстве ядра

Настройка правил кеширования в пространстве ядра выполняется почти так же, как кеширование в пространстве пользователя. В диалоге настройки правила установите флажок Kernel-mode caching (Кеширование в режиме ядра) и выберите желаемый способ кеширования.

В одном правиле допускается использовать оба режима кеширования, в пространстве ядра и в пространстве пользователя. В этом случае IIS будет сначала пытаться применить кеширование в пространстве ядра. Если попытка не увенчается успехом, например, когда запрос содержит строку с параметрами, применяется кеширование в пространстве пользователя.

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

Настройка пула приложения

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

Перезапуск

Изменяя параметр настройки перезапуска можно управлять моментом, когда пул приложения будет перезапускать рабочий процесс. Например, можно организовать перезапуск рабочего процесса через каждые несколько часов или когда будет превышен некоторый предел занимаемой памяти. Если с течением времени веб-приложение начинает потреблять большие объемы памяти (например, для хранения объектов), увеличение количества перезапусков может помочь удерживать его производительность на высоком уровне. С другой стороны, если веб-приложение не проявляет никаких проблем в процессе работы, уменьшение количества перезапусков предотвратит потерю информации о состоянии.

Тайм-аут простоя

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

Привязка процессов к ядрам процессора

По умолчанию пул приложения настроен так, что может использовать все доступные ядра процессора. Если у вас имеется какой-либо специализированный фоновый процесс, использующий все процессорное время, какое ему будет выделено, можете настроить привязку пула к определенным ядрам, освободив остальные для фонового процесса. Разумеется, при этом также потребуется настроить привязку фонового процесса к другим ядрам процессора, чтобы избежать конкуренции между ним и рабочим процессом за одни и те же ядра.

Веб-сад

Другим примером, когда может пригодиться наличие нескольких процессов, выполняющих одно и то же веб-приложение - использование 64-разрядного сервера IIS, выполняющего 32-разрядное веб-приложение. 64-разрядные серверы обычно имеют большой объем памяти, а 32-разрядное приложение может использовать не более 2 Гбайт, что часто приводит к увеличению частоты сборки мусора и, вероятно, к перезапускам пула приложения. Поддерживая два или три рабочих процесса для 32-разрядного веб-приложения, можно добиться более полного использования памяти сервера, уменьшить частоту сборки мусора и перезапусков пула приложения.

В настройках IIS пула приложения можно определить максимальное количество рабочих процессов, которое можно запустить для обслуживания запросов. Если установить этот параметр в значение больше 1 (значение по умолчанию), с ростом нагрузки на веб-приложение для него будут запускаться дополнительные рабочие процессы, вплоть до указанного максимума. Пул приложения, имеющий более одного процесса, называется «веб-садом» («Web Garden»). Каждый раз, когда устанавливается соединение с клиентом, оно связывается с рабочим процессом, который будет обслуживать запросы от этого клиента, при этом соблюдается равномерное распределение запросов от пользователей между процессами и уменьшаются накладные расходы на конкуренцию.

Имейте в виду, что использование веб-сада имеет и недостатки. Большее количество рабочих процессов занимает больший объем памяти, исключается возможность использовать механизм по умолчанию хранения информации о сеансе в памяти процесса, при выполнении нескольких рабочих на одном компьютере, между ними может возникать конкуренция за локальные ресурсы, например, за использование общего файла журнала.

Этот раздел описывает факторы, влияющие на объем памяти, необходимый для эффективной работы веб- или FTP-узла, и счетчики, которые можно использовать для оценки требуемой памяти. Включает следующие подразделы:

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

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

Объем ОЗУ, выделенный для кэша
Размер файла подкачки
Свободный объем на диске
Количество выполняющихся служб
Тип процессора
Размер файлов содержимого
Количество файлов содержимого
Число соединений, открытых в текущий момент
Наличие других активных приложений, использующих ОЗУ

Когда IIS получает запрос на статический файл, дескриптор файла хранится в кэш-памяти IIS, а файл — в кэше Windows 2000. Если последующие запросы обращаются к тому же файлу, IIS использует копии, хранящиеся в оперативной памяти, а не обращается снова к диску для извлечения этого файла. Это снижает время выполнения запросов и ускоряет доступ для посетителей. Однако время, в течение которого файл удерживается в кэше, зависит от ряда других факторов.

По мере поступления запросов на другие файлы кэш IIS очищается от наиболее «старых» из ранее запрошенных файлов, чтобы обеспечить место для новых файлов. Это означает, что если имеется много файлов, доступных через IIS, а объем ОЗУ мал, то доступ пользователей будет замедляться из-за необходимости загрузки запрошенных файлов с жесткого диска. Если на компьютере одновременно выполняются другие приложения, также использующие оперативную память, то кэшированные копии файлов также будут удаляться из ОЗУ, чтобы освободить место для новых файлов. IIS может оказаться неспособным удерживать кэшированные файлы в оперативной памяти. Результатом также будет замедление доступа к IIS за счет загрузки файлов с жесткого диска.

Файлы ASP хранятся в кэш-памяти и остаются в ней, если не установлено ограничение на число файлов, хранящихся в кэш-памяти. Дополнительные сведения об установке ограничений на число страниц ASP, удерживаемых в кэш-памяти, см. в разделе Кэширование приложений.

Поскольку для больших файлов требуется больший объем оперативной памяти, чем для маленьких, то запросы на такие файлы как файлы звукозаписи или видеозаписи при ограниченном объеме ОЗУ могут привести к более частому обновлению содержимого кэша. Если публикуются большие документы, большое число документов или на компьютере, поддерживающем IIS, выполняются другие приложения, занимающие оперативную память, то повысить быстродействие можно за счет увеличения объема ОЗУ. Если же публикуется небольшое число файлов относительно малых размеров, то увеличение ОЗУ не приведет к повышению производительности компьютера.

На быстродействие можно повлиять настройкой количества памяти, выделяемой Windows 2000 для файлов кэша. Если сервер используется в основном как веб-сервер, сконфигурируйте его как сервер приложений, а не используйте стандартные установки для сервера файлов.

На рабочем столе откройте папку Мой компьютер и выберите Сеть и удаленный доступ к сети.
Щелкните правой кнопкой мыши Подключение по локальной сети и откройте окно свойств.
Выберите Служба доступа к файлам и принтерам сетей Microsoft и нажмите кнопку Свойства.
На вкладке Оптимизация сервера выберите параметр макс. пропускная способность для сетевых приложений.

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

Всего кэшированных блоков BLOB
Всего кэшированных блоков URI
Всего удаленных блоков BLOB
Всего удаленных блоков URI
Всего файлов в кэше
Попаданий в кэш BLOB
Попаданий в кэш URI
Попаданий в кэш файлов
Предельное использование памяти кэша файлов
Промахов в кэше BLOB
Промахов в кэше URI
Промахов в кэше файлов
Процент попаданий в кэш BLOB
Процент попаданий в кэш URI
Процент попаданий в кэш файлов
Текущее использование памяти кэша файлов
Текущее число кэшированных блоков BLOB
Текущее число кэшированных блоков URI
Число удалений кэша BLOB
Число удалений кэша URI
Число удалений кэша файлов

Процент попаданий в кэш должен быть как можно более высоким. Малое значение, особенно сопровождающееся большим значением счетчика «% активности диска» объекта «Физический диск», свидетельствует о том, что сервер не в состоянии извлекать достаточное количество файлов из кэша. Это может вызываться или тем, что запрашивается большое число разных файлов, или тем, что размер кэша мал и нуждается в увеличении. Дополнительные сведения о кэшировании приложений см. в разделе Настройка приложений.

Балансировка использования памяти и скорости ответа

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

IIS предлагает установить ориентировочное число запросов за 24-часовой период и затем автоматически поддерживает баланс использования памяти и времени отклика. Если изменяется это оценочное значение, IIS изменяет число соединителей, выделенных для «прослушивания» новых запросов. Если задать число, слегка превышающее фактическое число обращений, то подключения будут выполняться быстрее. Если задать число, существенно превышающее фактическое число обращений, то будет выделена избыточная память. Инструкции по заданию ожидаемого числа подключений см. в разделе Оценка интенсивности передачи данных.

В IIS 5.0 узлы, имеющие разные IP-адреса, но один номер порта, используют один набор соединителей. Таким образом, создание нескольких узлов с разными IP-адресами, но использующих порт 80, не увеличит существенно использование IIS невыгружаемой памяти. IIS гибко использует эти соединители для всех узлов, уменьшая использование их ресурсов. Группировка соединителей дает IIS 5.0 возможность размещать намного больше узлов на том же аппаратном обеспечении, чем это было возможно в IIS 4.0.

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

По умолчанию IIS разрешает группировку соединителей. В большинстве случаев эту установку не следует изменять. Однако для критически важных узлов и узлов, которым будет выделена группа соединителей, запись в метабазе (MD_DISABLE_SOCKET_POOLING) может быть установлена в /LM/W3SVC/X (где X — это номер узла) для возвращения к порядку, установленному в IIS 4.0. Группировку соединителей следует отключить только на уровне узлов, поэтому другие, некритичные узлы могут продолжать использовать преимущества этой новой возможности. Это свойство может быть установлено только с помощью сценариев и недоступно из оснастки IIS. Дополнительные сведения см. в разделе Изменения ADSI в IIS 5.0.

Введение

Приходилось ли вам когда-нибудь самим настраивать производственные веб-сервера (production servers) под управлением ОС Windows Server 2008 R2/IIS 7.5 и выше? Для системных администраторов, имеющих большой опыт работы с IIS, скорее всего, это тривиальная задача, но вот для веб-разработчиков, которым по различным причинам порой приходится самим участвовать в настройке «боевых» серверов, данная информация может оказаться весьма полезной.

Предыстория

1. Параметры конфигурации IIS

Схема конфигурационных файлов для IIS 7.x и выше выглядит так:

Рис. 1. Схема конфигурационных файлов

для 32-битной — %WINDIR%\System32\inetsrv\config\
для 64-битной — %WINDIR%\SysWOW64\inetsrv\config\

При конфигурации IIS можно выделить два основных параметра, влияющих на доступность приложения и его производительность.

1. Параметр appConcurrentRequestLimit — максимальное количество одновременных запросов в приложении. Увеличение числа одновременных запросов IIS расширит доступные ресурсы веб-сервера для обслуживания запросов. Значение по умолчанию — 5000.

Наиболее быстро изменить параметр appConcurrentRequestLimit можно утилитой appcmd.exe через командную строку. Сделать это можно как глобально для всех сайтов IIS через файл ApplicationHost.config, так и для отдельного сайта (приложения).

Выполняем команду, затем открываем в IIS раздел «Configuration Editor» для корневого каталога и проверяем новое значение установленного параметра appConcurrentRequestLimit. Причём здесь же можно вручную изменить это значение.

Рис. 2. Установка параметра appConcurrentRequestLimit

Для установки данного параметра наиболее часто используется формула:
<usersCount * 1.5>, где usersCount — количество одновременно работающих пользователей.

Выполняем команду, затем открываем в IIS раздел «Application Pools», выбираем в списке пул «DefaultAppPool », заходим в меню «Advanced Settings» и проверяем.

Рис. 3. Установка параметра queueLength

На заметку: Просмотр текущих запросов в работающем пуле через “IIS ->Worker Processes”

В диспетчере IIS выберите узел сервера в дереве, затем нажмите на иконку «Worker Processes»:

Рис. 4. Меню Worker Processes в диспетчере IIS

В появившемся списке вы можете видеть загрузку всех запущенных в текущий момент пулов.

Рис. 5. Просмотр работающих пулов через Worker Processes

При нажатии “View Current Request” появляется таблица со списком адресов обрабатываемых страниц и другими полезными параметрами. Для обновления списка можно нажимать F5 на экране. Таким образом, вы сможете найти «подвисшие» запросы:

Рис. 6. Список текущих запросов в пуле

Для просмотра показателей производительности, конечно, лучше использовать счётчики Performance Monitor, но они не покажут вам, как Requests Monitor, URL-адреса текущих запросов.

Работа пулов приложений в интегрированном режиме имеет несколько преимуществ по сравнению с работой в классическом режиме. Рекомедуется запускать пулы приложений в integrated mode.

Для оптимальной работы веб-приложений по умолчанию включен режим автоконфигурации настроек пула. В этом случае, cвойство autoConfig равно "true" для секции <processModel> в файле machine.config, а другие ключевые параметры не заданы вообще.

maxConnection
maxWorkerThreads / minWorkerThreads
maxIoThreads / minIoThreads
minFreeThreads
minLocalRequestFreeThreads

Таким образом, на сервере с 4-х ядерным процессором максимальное кол-во одновременных подключений к конечному IP-адресу равно 48=12*4 (по умолчанию).

Важно: Схема для адреса параметра maxconnection должна быть такой:

Увеличение maxconnection позволяет делать больше одновременных вызовов к удаленным сервисам. Этот атрибут не влияет на локальные вызовы веб-служб! Необходимо понимать, что недостаточно только обойти ограничение на количество одновременных подключений к сервису. Так как увеличение числа одновременных вызовов приводит к увеличению использования потоков CLR, которые используются для создания удаленных и обработки обратных вызовов.

Аттрибуты, заданные в секции <processModel>:
1. Параметр maxWorkerThreads — указывает максимальное количество рабочих потоков для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.

2. Параметр maxIoThreads — указывает максимальное количество потоков ввода/вывода для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.

3. Параметр minWorkerThreads — указывает минимальное количество рабочих потоков для каждого процессора, которые могут быть предоставлены немедленно для обслуживания удаленного запроса. Значение по умолчанию — 1.

4. Параметр minIoThreads — указывает минимальное количество потоков ввода/вывода для каждого процессора, которые могут быть предоставлены немедленно для обработки обратного вызова. Значение по умолчанию — 1.

Обратите внимание, параметры maxWorkerThreads, minWorkerThreads, maxIoThreads, minIoThreads неявно умножаются на число процессоров, а параметры minFreeThreads и minLocalRequestFreeThreads — нет.

Обратите внимание: на весь пул приложения, то есть на каждый рабочий процесс w3wp.exe, обслуживающий пул, имеется один пул потоков CLR ThreadPool. Для всех доменов приложений (сайтов), настроенных на один пул, используется общий набор потоков. Следовательно, для требовательных к ресурсам приложений лучше использовать отдельные пулы.

3. Рекомендации по оптимизации базовой конфигурации

Прежде всего, необходимо точно определить количество процессоров на веб-сервере. Как вариант, можно посмотреть TaskManager -> вкладка «Performance». Если процессор поддерживает режим HyperThreadingTechnology (HTT), значит половина ядер логические (Logical processors), а не физические (Cores). Например, при включенном режиме HTT процессор с 4-мя физическими ядрами будет работать как 8 логических ядер:

Рис. 8. Окно загрузки процессоров в TaskManager

Также можно попробовать воспользоваться следующими командами в командной строке:

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

maxWorkerThreads = 100 | minWorkerThreads = maxWorkerThreads / 2 = 50
maxIoThreads = 100
maxConnection = 12 * N
minFreeThreads = 88 * N
minLocalRequestFreeThreads = 76 * N, где N — количество процессоров.

Изменения в секцию <processModel> разрешено вносить только в файле machine.config из-за установленного там же атрибута allowDefinition при добавлении секции processModel.

Чтобы иметь возможность устанавливать значения секции processModel для каждого приложения в отдельности через web.config, необходимо установить свойство allowDefinition .

Приведу настройки конфигурации с нашего веб-сервера

Важно: после внесения изменений требуется обновить Application pools.

Помните, что увеличивать данные параметры нужно только в случае необходимости при наличии достаточного количества ресурсов ЦП.

Возможно, что после проверки счётчиков вам придётся внести корректировки в конфигурацию вашей системы.

Дополнительно

Если вы используете IIS8 — не будет лишним обратить внимание на «Полноценное регулирование нагрузки CPU (CPU Throttling)».

Заключение

Для сайтов, которые не совершают частые сетевые запросы на стороне сервера, стандартных настроек пула должно хватать (processModel/autoConfig=“true”). При этом IIS выставит ограничение в 20 рабочих потоков и 12 удаленных соединений на ядро. При превышении этих значений запросы начнут становиться в очередь и производительность веб-приложения упадёт.

Приглашаю всех поделиться вашим опытом настройки и оптимизации работы производственных веб-серверов на платформе Windows Server.

Лимит составляет 96 Мб.
Можно ли как-то проверить что приложение действительно превышает 96 Мб?
Причем превышает сразу же.
У меня в этом большие сомнения.
Примеры кода, которые позволяют посмотреть параметры процессов IIS , не работают с IIS7.

Код сайта , конечно, далек от иделал, но я все-таки старался элементарные действия
предотвращающие утечки памяти соблюдать. Закрывать подключения к БД, readerы,
использовать Command.ExecuteReader(CommandBehavior.CloseConnection) и т.п.

Посмотрел в ANTS memory profiler, результат в скриншоте.
Единственное, меня смущает, результат Virtual Bytes, выше 200 Мб, но такой же результат
показывается и для простой странички типа Hello World, без всяких компонентов, сторонних dll и тому подобного.

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

ну например Агава берет деньги за номинальную мощность блока питания (за наклейку!) - хоть сервер даже 10% от наклейки потребляет

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

ну например ты по договору платишь за трафик - а денег им хочется - админ запускает nmap и дергает сервер - пока не докрутит до суммы, которую хочет получить начальство с этого клиента
не хочу называть эту хостинг-площадку (у меня там много-много серверов стоит - не хочется ругаться) но наверное все видели такие тонкие клиенты, развешанные прямо тупо в приемной - на которых идет nmap и докручивает трафик (ну типо досят сервера неизвестные) - на хостинге возле курского вокзала
особо даже никто не стестняется - чтобы докрутить сумму с клиента до желаемой - тонкие клиенты на которых идет nmap висят даже в комнате, куда выносят сервера для ремонта клиентам
на мой вопрос - почему так все нагло - мне ответили что это мониторинг работоспособности сайта и ведут они его строго по договору

нах такие хостинг-площадки - просто ищи нормальных

Ситуация на самом деле неприятная, я вот в некой растерянности нахожусь и не знаю с какой стороны
подступиться.

Читайте также: