Iis об управлении памятью


Содержание

Настройка IIS

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

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

Мы уже знаем, что ASP.NET поддерживает собственный механизм кеширования вывода, зачем же использовать еще один подобный механизм в IIS? Ответ на этот вопрос прост: помимо страниц ASP.NET существуют и другие виды содержимого, которое можно кешировать. Например, мы можем кешировать часто запрашиваемые статические файлы изображений или вывод собственных обработчиков HTTP-запросов. Для этой цели как раз и можно использовать механизм кеширования, поддерживаемый веб-сервером IIS.

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

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

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

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

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

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

После добавления правила кеширования, настройки сохраняются в файле web.config приложения, в разделе system.webServer caching. Например, для правила кеширования страниц .aspx на срок до 30 минут, с учетом HTTP-заголовка Accept-Language, будет сгенерирован следующий код в конфигурационном файле:

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

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

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

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

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

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

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

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

Перезапуск

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

Для проверки количества и частоты перезапусков пула приложения можно использовать счетчик производительности ASP.NET\Worker Process Restarts. Если вы увидите слишком большое количество перезапусков без явной на то причины, попробуйте сопоставить полученные значения с потреблением памяти приложением и нагрузкой на процессор, потому что перезапуски могут быть обусловлены превышением других пределов, определяемых настройками пула приложения.

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


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

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

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

Веб-сад

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

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

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

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

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

Ограничение использования CPU для Application Pool в IIS 8

Важной функцией любого веб-сервера является возможность ограничения использования процессорных ресурсов CPU определенным сайтом, в противном случае один сайт может монополизировать ресурсы CPU, что может быть неприемлемо, особенно для серверов веб-хостинга, разделяемых ресурсы между несколькими клиентами с разными сайтами. В IIS (Internet Information Services) 7.0 и более ранних версиях, присутствовала возможность мониторинга использования CPU веб приложениями и отключения на несколько минут пула приложений, превысившего заданный лимит. Полноценная возможность управления потреблением ресурсов CPU, доступных каждому пулу приложений, появилась только в IIS 8.0 (Windows Server 2012 и выше). Эта возможность называется CPU Throttling и позволяет вместо временной остановки чрезмерного агрессивного к процессору пула приложений, задать максимальное количество ресурсов CPU, доступных каждому пулу IIS.

В этой статье мы покажем, как ограничить использование CPU пулами приложений в IIS 8 (и выше) на примере веб-сервера на базе Windows Server 2012.

Откройте консоль Internet Information Services (IIS) Manager (%systemroot%\system32\inetsrv\iis.msc), разверните в дереве ваш сервер и выберите раздел Application Pools. Настройки CPU Throttling в IIS находятся в разделе параметров каждого пула.

  • Если нужно включить ограничения для конкретного пула, выберите его в списке и перейдите в раздел настроек Advanced Settings.
  • Если нужно задать настройки лимитов по-умолчанию для всех пулов, нужно выбрать секцию Set Application Pool Defaults.

В окне настроек Advanced Settings нас интересуют параметры, задаваемые в секции CPU:

  • Limit – максимальный % процессорного времени, который может использовать пул приложений. При превышении этого значения, выполняется действие, указанное в поле Limit. В IIS 8 процент задается в тысячных долях (1/ 1000 процента ). К примеру, чтобы ограничить потребление CPU в 20%, в поле Limit нужно указать 20000. В IIS 8.5 значение указывается в обычных процентах. Отключить лимит использования можно, задав 0
  • Limit Action – действие, которое выполняется с пулом при превышении лимита использования CPU
  • Limit Interval (minutes) – периодичность проверки и сброса результатов загрузки при приостановке рабочего процесса. Этот параметр не используется для CPU Throttling, и используется для совместимости с предыдущими версиями IIS.

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

  • NoAction – никаких действий не выполняется, а в журнал записывается событие о превышении CPU
  • KillW3wp (Kill worker processes) — рабочий процесс пула, превысившего лимит приостанавливается на время, указанное в поле Limit Interval. В журнал добавляется соответствующая запись.
  • Throttle – жесткое ограничение доступных ресурсов CPUзначением, заданным в поле Limit. Значение поля Limit в этом случае игнорируется, а в журнал пишется событие.
  • ThrottleUnderLimit – ограничения работают только при высокой загрузке сервера. При наличии свободных ресурсов CPU, пул может превысить заданный лимит.


Настроить CPU Throttling можно и из командной строки с помощью утилиты appcmd. Например, чтобы для пула DefaultAppPool установить ограничение в 30% использования CPU, нужно выполнить команду:

%systemroot%\system32\inetsrv\appcmd set apppool DefaultAppPool /cpu.limit:30000 /cpu.action:Throttle

Включить ограничение для всех пулов IIS можно так:

%systemroot%\system32\inetsrv\appcmd set config -section:system.applicationHost/applicationPools /applicationPoolDefaults.cpu.limit:10000 /cpu.action:Throttle /commit:apphost

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

Таким образом, в IIS 8 появилась возможность гибкого регулирования загрузки сервера запущенными веб-приложениями. Но нужно понимать, что CPU Throttling используется только для ограничения максимальной загрузки CPU, но не для резервирования процессорных мощностей для веб-приложения.

IIS 7.0: краткая инструкция для системного администратора. Часть 1 – пpoверка результатов установки.

Продолжаем говорить об процедуре установки веб сервера под управлением IIS 7.0 на Windows Server 2008, которая была рассмотрена в предыдущем посте.

Теперь перейдем к проверке результатов установки IIS 7.0. Самый простой вариант проверить, работает ли веб сервер, особенно – находясь за локальной консолью, это обратиться из любого веб-браузера по адресу http://localhost/. Далее, проверить с локальной и удаленной машины по IP-адресу.

При установке IIS 7.0 создается веб сайт по умолчанию, сконфигурированный на ответ при любом URL-запросе, поступившем на порт 80 любого сетевого интерфейса сервера, на котором установлен IIS 7.0. Т.е. запрос браузера типа http://localhost/ должен быть обработан как запрос к веб сайту по умолчанию. Содержимое сайта по умолчанию представляет собой 2 файла – iisstart.htm и welcome.png (который отображается в iisstart.htm), которые и будут открыты клиентом. Поэтому результат обращения к localhost будет иметь следующий вид:

Теперь, если все хорошо (если «плохо» – поиск неисправностей и ошибок мы рассмотрим позже, в отдельном разделе), убедимся, что все модули, которые должны быть установлены по умолчанию – подключены и работают, а базовая конфигурация – отвечает нашим требованиям.

Илон Маск рекомендует:  Работаем с файлами на perl

1. Основным инструментом управления IIS 7.0 является консоль Internet Information Services (IIS) Manager, которая устанавливается по умолчанию, вместе с ролью Web Server в Windows Server 2008 (IIS Management Console, раздел Management Tools при установки модулей). После соответствующей установки консоль управления IIS 7.0 можно найти, как дочернюю запись внутри раздела Web Server (IIS) в разделе ролей Server Manager, либо как пункт в разделе Administrative Tools меню Start, либо выполнив команду inetmgr (в командной строке или через пункт Run того же меню Start).

2. При старте консоль Internet Information Services (IIS) Manager открывается с «домашней страницей», на которой в виде панелей находится информация о том, к каким веб серверам и веб сайтам подключался пользователь консоли до этого (если консоль только установлена вместе с ролью Web Server (IIS), то в консоле присутствует запись только о локальном веб сервере), также присутствуют ссылки для выбора подключения к другим серверам, веб сайтам, веб приложениям и папкам, а также ссылки на внешние ресурсы, посвященные IIS.

3. Кроме того, на домашней странице присутствует панель новостей, которые подгружаются как новостная RSS-лента с сайта www.iis.net, если администратор нажимает на ссылку Enable IIS News. Новости, кстати, очень полезные, рекомендуется включать и использовать эту информацию в повседневной работе.

4. При подключении к какому либо веб серверу IIS 7.0 консоль Internet Information Services (IIS) Manager представляет его конфигурацию, как логическую структуру – уровень самого веб сервера, чьи настройки являются глобальными и распространяются по умолчанию на все веб сайты, пулы приложений и, сообственно, веб сайты со своими настройками. Эта конфигурационная иерархия, в виде разворачивающегося дерева, начинающегося с узла с именем (или IP) веб сервера, отображается в левой панели консоли Internet Information Services (IIS) Manager.

5. Если выбрать какой-то узел в дереве конфигурации, то в центральной панель консоли Internet Information Services (IIS) Manager будут отображены в виде отдельных иконок все параметры (а также – модули или списки), соответствующие конфигурации выбранного узла, а в правой панели – набор контекстных задач и операций, которые администратор (или пользователь) может выполнить над данным узлом.

6. Выбираем верхний узел, узел веб сервера, в котором представлены иконки, отвечающие за параметры работы модулей всего веб сервера, эти параметры наследуются по умолчанию для всех веб сайтов. Убеждаемся, что все необходимые модули установлены и отображены. Снимок экрана при установке конфигурации по умолчанию приведен ниже.

7. В правой панели при выборе узла веб сайта отображаются все операции, возможные для выполнения непосредственно с веб сервером (службами IIS в целом) в данном конексте – перезапуск, останов, запуск, переход к пулам приложений и сайтам.

8. Убеждаемся, что пулы приложений (Application Pools) сконфигурированы. Пулы приложений будут рассмотрены позже. Пулы являются дочерним узлом в дереве конфигурации для узла веб сайта. При установке по умолчанию создается только один пул – DefaultAppPool, в котором регистрируется одно приложение – сконфигурированный по умолчанию веб сайт, работу которого мы уже проверили. См. снимок экрана.

9. Ниже узла пулов приложений в дереве конфигурации находится узел веб сайтов (Sites), при выборе которого отображается список работающих на данном веб сервере веб сайтов. По умолчанию создается один веб сайт под названием Default Web Site с внутренним номером (ID) равным 1, «привязанный» на 80 порт всех IP-адресах всех сетевых интерфейсов к любому URL в запросе, и использующий в качестве домашнего каталога своего контента каталог с путем %SystemDrive%\inetpub\wwwroot (что при установленном Windows Server 2008 на диск C: соответствует C: \inetpub\wwwroot).

10. При выборе в левой панели консоли узла веб сайта (Default Web Site), также, как и в случае с выбором узла веб сервера, в центральной панели отображаются иконки для доступа к параметрам конфигурации различных модулей, на этот раз – конкретного веб сайта. Убеждаемся, что также, как и в случае со всем веб сервером, все необходимые модули представлены в центральной панели.

11. В правой панели консоли, аналогично панели для всего веб сервера, отображаются контекстные команды, правда, на этот раз их список серьезно расширен – старт/стоп/перезапуск процесса веб сайта, просмотр его базовых и расширенных настроек (а не параметров модулей), настройки привязки (адрес, порт, доменное имя – по сочетанию которых будет отвечать на запросы данный веб сайт) и т.п.


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

12. Выберите узел веб сервера в дереве конфигурации в левой панели консоли Internet Information Services (IIS) Manager. В центральной панели кликните на иконку Modules. В центральной панели откроется следующий полный список установленных по умолчанию модулей, представляющий из себя перечень .dll файлов.

13. Чтобы убедиться, что веб сервер будет работать только со статическими файлами (по умолчанию) или только с нужными вам расширениями – выберите снова узел веб сервера и в центральной панели кликните на иконку Handler Mappings. Откроется список «привязки» расширений вызываемых на веб сайте пользователем файлов и привязанных к данным расширениям модулям, выполняющим обработку данного вызова. Обратите внимание, что по умолчанию все файлы привязаны к модулю обработки статических файлов (т.е. запрос какого либо скриптового или исполнимого файла из домашнего каталога веб сайта не будет приводить к его исполнению на сервере, а лишь к передаче данного файла пользователю), а также к модулям документа по умолчанию и просмотра каталога. С этими модулями мы познакомимся позже.

14. И, наконец, для того, чтобы убедиться в безопасности веб сайта – проверьте параметры его аутентификации. Для этого выбираем иконку Authentication в той же центральной панели. По умолчанию никаких модулей аутентификации веб сервер (и веб сайты) не поддерживает. Т.е. все подключения для него анонимны. В чем безопасность? Это значит, что пользователям будет доступен только то содержимое домашних каталогов сайтов – файлы и подкаталоги – которые имеют NTFS разрешения для чтения «всем» (Everyone). В случае, если таких разрешений файл не имеет, пользователю будет отказано в доступе с соответствующей ошибкой 401. Если же пользователь попробует каким-то образом аутентифицироваться в процессе HTTP запроса на сервере – то поскольку никаких модулей аутентификации, кроме анонимного, на веб сервере не установлено – он снова получит соответствующую ошибку 401.

Такие настройки безопасности по умолчанию – только анонимные пользователи – позволяют гарантировать защиту данных на сервере, для которых требуются соответствующие разрешения, а также – что механизм аутентификации веб сервера (которого в данном случае просто нет) не будет использован для перебора паролей и прочих попыток «взлома» через учетные записи.

Итак, сервер установлен и его работоспособность проверена. Теперь достаточно поместить какой либо статический контент (файлы HTML, изображения, документы и файлы для выгрузки пользователями) в домашний каталог его сайта по умолчанию (напоминаю, что это в большинстве случаев C:\inetpub\wwwroot) – и веб сайт под управлением IIS 7.0 начнет работать. Ну, и конечно, для внешних сайтов – не забыть прописать их A-record в вашей доменной зоне на публичном DNS сервере.

В следующей части – установка IIS 7.0 в режиме командной строки, особенности работы IIS 7.0 на Server Core.

Ограничения IIS?

На локальном сервере поднят IIS, на нем несколько сайтов. Когда на одном из сайтов подключается порядка 140-160 пользователей, подключение нового становится невозможным. т.е. отправляется http запрос, но ответ не доходит, типа страница грузится… При этом нагрузка на процессор не более 15% и свободной памяти более 50%. Причем остальные сайты на сервере грузятся без проблем. Такое ощущение что в настройках пула стоит ограничение на число сессий…

Подскажите в чем может быть проблема…

  • Вопрос задан более трёх лет назад
  • 6969 просмотров

Performance Monitor, или, если есть — Resource Monitor (запускается из TaskManager).
Если при большой нагрузке средние дисковые очереди больше чем 2 * (суммарное количество шпинделей у дисков) — это проблема.

Web-сервер, на который можно положиться

Повышенная надежность

Как сделать так, чтобы Web-серверы Microsoft IIS работали стабильно и надежно? Как добиться, чтобы приложения объявляли о своей неспособности продолжать работу и автоматически перезапускались без вмешательства администратора? Могут ли клиенты загружать на сервер большое количество файлов, не занимая при этом всей полосы пропускания канала связи, а после сбоя возобновлять работу с прежнего места? Существуют ли Web-приложения, которые отвечают всем перечисленным требованиям и при этом занимают не более 50% ресурсов процессора? Администраторов, знакомых с IIS 5.0 и IIS 4.0, возможно, удивит, что IIS 6.0 приближается к этому идеалу.

Результаты Microsoft.com

В июне 2003 г. на конференции Microsoft TechEd в Далласе вместе с менеджером группы Microsoft.com Кейси Джейкобс мы проводили презентацию. Кейси представил ряд статистических данных о Microsoft.com, в настоящее время самом крупном сайте на базе IIS 6.0:

  • период работоспособности 99,8 % (по данным организации Keynote Systems, которая занимается испытаниями производительности Web-сайтов);
  • 950 серверов и три центра обработки данных;
  • 80 Internet-сайтов, обслуживающих 1000 баз данных Microsoft SQL Server и тысячи Web-приложений;
  • 25,5 млн. обращений к домашней странице в марте 2003 г.;
  • более 75 000 запросов в секунду;
  • более 300 000 одновременных пользователей;
  • 20 системных инженеров, 12 администраторов баз данных и 16 техников, обеспечивающих круглосуточное обслуживание без выходных.


Время безотказной работы, превышающее 99% на 950 серверах, обслуживаемых 20 системными инженерами, — впечатляющий результат, особенно если учесть, что эта информация исходит непосредственно от технических специалистов, а не из отдела маркетинга. Сотрудники Microsoft достигли таких показателей, работая со смешанным набором серверов IIS 6.0 и IIS 5.0.

Каким образом переход с Windows 2000 Server на Windows Server 2003 отразился на надежности Microsoft.com? Время непрерывной работы сети Microsoft Developer Network (MSDN) увеличилось на 100% (табл. 1). Некоторые случаи перезагрузки операционной системы были вызваны применением исправлений и пакетов обновлений, и компания Microsoft стремится еще больше сократить их число.

Надежность удалось повысить благодаря новым мощным функциям семейства серверов Windows 2003 и IIS 6.0.

Изоляция WWW Service Administration and Monitoring

Одним из важнейших изменений, оказавших непосредственное влияние на надежность, стало совершенствование внутренних механизмов IIS 6.0. Краткий обзор архитектуры IIS 5.0 может послужить материалом для сравнения. Первичный процесс IIS 5.0, который обеспечивает основные функции IIS — inetinfo.exe. Кроме того, в Inetinfo размещаются Web-приложения, запущенные в режиме Low (In Process) Application Protection из консоли Microsoft Management Console (MMC) Internet Information Services. Web-приложения можно запускать «вне процесса» (out of process), в среднем — объединенном (Medium-Pooled) или высоком — изолированном (High-Isolated) режиме; в этом случае они выполняются в процессе с именем dllhost.exe. На Inetinfo возлагаются и другие важные функции, в частности маршрутизация входящих запросов из Winsock в соответствующие внепроцессные Web-приложения и хостинг службы IIS Admin Service, которая обеспечивает связь с метабазой (хранилищем параметров настройки для Web-узлов IIS и каталогов). В результате задачи, связанные с настройкой конфигурации и внутренним администрированием Web-сервера, работают в одном процессе с Web-приложениями. Поэтому неудачно составленная программа может вызвать исключительную ситуацию (то есть сбой) или иным способом остановить Inetinfo и прервать работу всего Web-сервера, в том числе и внепроцессных приложений.

В IIS 6.0 компонент WWW Service Administration and Monitoring и Web-приложения работают в отдельных процессах, и вызывающее сбой или зависшее Web-приложение не приведет к краху WWW Service Administration and Monitoring. Такое разделение позволяет службе WWW Service Administration and Monitoring контролировать Web-сервер, поддерживать его в рабочем состоянии и даже перезапускать приложения, которые не отвечают на исходящие от компонента запросы «Are you live?».

Пулы приложений

Web-приложения IIS 6.0 работают в исполнительном процессе (worker process) с именем w3wp.exe, который заменяет Dllhost IIS 5.0 (и wam.exe IIS 4.0). Однако в IIS 6.0 можно дать исполнительному процессу имя и управлять им как элементом, называемым «пулом приложений» (application pool). Любому пулу приложений нетрудно сопоставить Web-узел, каталог или виртуальный каталог в диалоговом окне Properties данного элемента (экран 1).

Экран 1. Назначение Web-сайта пулу приложений

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

WWW Service Administration and Monitoring автоматически проверяет, реагирует ли пул приложений на запросы, через каждые 30 секунд (по умолчанию) или через интервал, задаваемый на вкладке Health диалогового окна Properties пула приложений. Если пул не отвечает, то WWW Service Administration and Monitoring перезапускает его без вмешательства администратора, что существенно повышает надежность. Кроме того, время цикла (останова и нового запуска) пула можно задать с помощью параметров на вкладке Recycling (экран 2). Например, по умолчанию время цикла пула приложений составляет 1740 минут (29 часов). На мой взгляд, не имеет никакого смысла принимать данное значение в качестве стандартного, поэтому я назначил рециркуляцию на определенное время суток, 3.00 утра по местному времени. Рециркуляция по графику удобна для приложений, требующих периодического перезапуска.

Илон Маск рекомендует:  Селектор атрибута
Экран 2. Настройка рециркуляции пула приложений

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

Формируя цикл пулов приложений, следует настроить IIS 6.0 на запись событий рециркуляции в Event Viewer. По умолчанию записываются только события рециркуляции, связанные с памятью и временем. В help-файлах IIS 6.0 приведены сведения о свойстве метабазы LogEventOnRecycle. Это свойство представляет собой битовую маску, в которой каждый разряд активизирует или блокирует запись определенного события. С помощью следующей команды можно активизировать запись всех событий:

cscript SystemDriveInetpubAdminScriptsadsutil.vbs
set W3SVC/AppPools/LogEventOnRecycle

Приложения с самоконтролем

Возможность настроить пулы приложений на перезапуск по определенным событиям полезна, но лучше всего встроить проверки состояния непосредственно в приложение, чтобы при необходимости оно могло запросить рециркуляцию. В любом расширении IIS 6.0 Internet Server API (ISAPI), в том числе и составленном администратором, можно инициировать рециркуляцию приложения с помощью новой функции HSE_REQ_REPORT_UNHEALTHY. Проверки состояния можно вставлять непосредственно в расширения ISAPI, не полагаясь исключительно на сервер. Более подробная информация об этой функции приведена по адресу http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/iis/extensions_ssf_hse_req_report_unhealthy.asp.

В IIS 6.0 приложения Active Server Pages (ASP) и ASP.NET — самоконтролируемые; при определенных обстоятельствах они вызывают HSE_REQ_REPORT UNHEALTHY. Например, ASP отслеживает время, необходимое механизму сценариев ASP, чтобы обработать запрос. Если это время превышает величину ASP Script Timeout, заданную в консоли Internet Information Services, то IIS дает механизму команду прекратить выполнение сценария. Если механизм сценариев на эту команду не реагирует, то ASP оставляет поток. Внутренний счетчик ASP отслеживает число оставленных потоков. Когда оно достигает определенного значения, asp.dll запрашивает рециркуляцию.

Аффинность процессоров

Следует обратить внимание еще на одно свойство пулов приложений в многопроцессорных системах: аффинность процессоров (CPU affinity). Свойство аффинности позволяет назначить процессоры для Web-приложений и пригодится, если администратору нужно выделить процессор для определенного клиентского приложения. Чтобы установить аффинные отношения между пулом приложений и процессором, необходимо задать два свойства метабазы: SMPAffinitized и SMPProcessorAffinityMask.

С помощью свойства SMPAffinitized активизируется аффинность для пула приложений. В Adsutil это свойство можно установить следующей командой:

cscript SystemDriveInetpubAdminScriptsadsutil.vbs
set W3SVC/AppPools/
ApplicationPoolName/
SMPAffinitized TRUE


где ApplicationPoolName — имя пула, с которым требуется установить аффинность. Если SMPAffinitized присвоено значение 0 (FALSE, с использованием Adsutil), то пул приложений может работать на любом процессоре.

Свойство SMPProcessorAffinityMask — битовая маска, представленная шестнадцатеричным числом, которая указывает процессор, выделяемый для пула. Если в машине имеется несколько процессоров, то пул может выполняться на нескольких из них. Следующая команда настраивает пул для работы на процессорах 0 и 2:

cscript SystemDriveInetpubAdminScriptsadsutil.vbs
set W3SVC/AppPools/
ApplicationPoolName/
SMPProcessorAffinityMask 0x5

В главе 4 «Running IIS 6.0 as an Application Server» комплекта ресурсов Internet Information Services (IIS) 6.0 Resource Kit (http://www.microsoft.com/downloads/details.aspx?family >

Web-сады

В IIS 6.0 предусмотрен еще один способ взаимодействия с пулами приложений — в Web-садах (Web garden) можно определить пулы приложений, содержащие более одного исполнительного процесса. В такой конфигурации IIS 6.0 создает экземпляр w3wp.exe для каждого запроса (вплоть до числа исполнительных процессов в пуле). Например, если в пуле приложений имеется три исполнительных процесса, то на сервере будет работать три экземпляра w3wp, доставляющих одинаковый контент. Последующие соединения с исполнительными процессами в Web-саду устанавливаются по круговой системе. В Web-садах нет явной сеансовой привязки, но IIS 6.0 направляет весь трафик одного соединения в один исполнительный процесс. Исполнительный процесс хранит сеансовую информацию, секретный ключ Secure Sockets Layer (SSL) и данные для аутентификации до тех пор, пока соединение не будет разорвано или не будет перезапущен исполнительный процесс.

Web-сады не нашли широкого применения отчасти потому, что и без них производительность и надежность IIS 6.0 в целом хорошие или отличные, а отчасти потому, что администраторы не знают, какие приложения выгодно запускать в Web-садах. Я не смог найти реальных примеров применения Web-садов, которые принесли бы явную пользу приложениям. Тем не менее я приведу два теоретических примера.

Web-сад может быть полезен, если приложение использует компонент со встроенными ограничениями. Например, если объект связи с базой данных устанавливает лишь десять соединений, можно организовать n исполнительных процессов, которые обеспечат 10 * n-соединений.

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

ASP.NET также располагает Web-садом и свойством аффинности процессоров, которые заметно отличаются от реализации IIS 6.0. Параметры для этих функций можно найти в элементе processModel XML-файла machine.config, основного файла настройки приложений ASP.NET. Сервер IIS 6.0 полностью игнорирует параметры machine.config для Web-сада и аффинности процессоров; они используются лишь в IIS 5.x. Более подробную информацию об ASP.NET и IIS 6.0 можно найти в статье «How ASP.NET Works with IIS 6.0» (http://www.microsoft.com/technet/ treeview/default.asp?url=/technet/prodtechnol/iis/iis6/proddocs/ resguide/iisrg_arc_dkvi.asp).

Диспетчер системных ресурсов Windows

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

Для решения этой проблемы разработчики Microsoft выпустили новую службу Windows System Resource Manager (WSRM — диспетчер системных ресурсов). WSRM работает только с Windows 2003, Enterprise Edition и Windows 2003, Datacenter Edition, но управлять ею можно с любого сервера Windows 2003. После развертывания WSRM можно настроить процесс (вместе со службами), установив верхний предел потребляемой им памяти или ресурсов процессора. Кроме того, можно выделить приложения, имеющие высокий уровень доступа к определенным процессорам, и предоставить ресурсы оставшихся процессоров другим процессам и службам — не используя функцию процессорной аффинности IIS 6.0. Среди прочих встроенных функций WSRM следует назвать протоколирование, мониторинг производительности, возможность вводить ограничения по дате и времени, исключать и добавлять пользователей. WSRM — лучшее средство для надежного распределения ресурсов памяти и процессоров на сервере. Более подробная информация о WSRM приведена по адресу http://www.microsoft.com/windowsserver2003/ downloads/wsrm.msp.

Очень мало известна новая функция Background Intelligent Transfer Service (BITS — служба фоновой интеллектуальной пересылки); я называю ее службой «сбора по капле». BITS позволит не только повеселиться, наблюдая за недоумением на лицах коллег, когда они услышат выражение dribble service, но и поможет сэкономить ресурсы канала связи, повысив отказоустойчивость при работе с высокими нагрузками.

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

Экран 3. Настройка BITS

Служба BITS не устанавливается по умолчанию вместе с IIS. Чтобы развернуть BITS на серверах Windows 2003, нужно открыть панель управления и выбрать функцию Add/Remove Programs, Windows Components, Application Server, Internet Information Services (IIS), Background Intelligent Transfer Service Server Extensions. Загрузить версию BITS, которая работает с Windows 2000 Server и IIS 5.0, можно по адресу http://www.microsoft.com/downloads/details.aspx?family >

В help-файлах содержатся важные сведения о безопасности и BITS-совместимых виртуальных каталогах. BITS обходит параметры безопасности IIS 6.0 и позволяет загружать файлы в папку с отключенным в IIS разрешением Write. Обычные разрешения безопасности NTFS соблюдаются. В качестве приложения к BITS можно получить комплекс инструментальных средств для разработки программ (SDK), который находится по адресу http://www.microsoft.com/downloads/details.aspx?family >

Новый уровень надежности

Таким образом, IIS 6.0 обеспечивает:

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

Благодаря этим и другим возможностям, о которых не было рассказано в данной статье из-за недостатка места (например, политиках качества обслуживания — QoS, накладывающих ограничения на ресурсы канала связи, выделяемые IIS), сервер IIS 6.0 гораздо надежнее любой предшествующей версии IIS. А если учесть повышенную производительность и безопасность IIS 6.0 и единодушно положительные отзывы всех знакомых мне специалистов, которые развертывали IIS 6.0, то у предприятий есть веские причины для перехода на новейшую версию Web-сервера.


Как происходит рециркуляция

Для рециркуляции исполнительных процессов в IIS 6.0 используется метод, называемый перекрывающимся циклом (overlapping recycling). Коротко всю процедуру можно представить следующим образом.

  • Исполнительный процесс отмечается как предназначенный для рециркуляции службой WWW Service Administration and Monitoring или по запросу приложения.
  • IIS 6.0 создает другой исполнительный процесс для замены избранного для рециркуляции. В этот момент оба исполнительных процесса находятся в памяти и могут быть активными одновременно.
  • Новые запросы посылаются в новый исполнительный процесс, а отмеченный для уничтожения процесс продолжает (если может) обслуживать запросы в своей очереди.
  • После того как очередь запросов старого процесса иссякнет или наступит тайм-аут (если исполнительный процесс не отвечает), IIS 6.0 уничтожает исполнительный процесс. IIS 6.0 сохраняет исполнительный процесс для диагностики лишь в тех случаях, когда установлен параметр метабазы OrphanWorkerProcess.

Параметр OrphanWorkerProcess очень полезен для отладки исполнительных процессов в производственных условиях. Более подробную информацию об этом параметре можно найти в help-файлах IIS 6.0.

Бретт Хилл — организатор узла http://www.iistraining.com, консультант по Microsoft IIS, IIS MVP; автор и преподаватель курсов IIS. С ним можно связаться по адресу: brett@iisanswers.com

Поделитесь материалом с коллегами и друзьями

Увеличение лимита на размер загружаемых на сервер файлов в IIS7

По умолчанию лимит на файл, который можно загрузить на сервер по HTTP составляет 30000000 байт, что несколько меньше, чем 30Мб. В случаях, когда необходимо загружать большие файлы, например, видео, такое лимит недостаточен и его нужно увеличить. Сделать это можно одним из приведенных ниже способов.

В примерах ниже увеличиваем лимит до 100Мб. Кстати, для загрузки больших файлов рекомендую использовать контрол на Silverlight, например тот, который разработали в Mail.ru.

Способ 1. В II7 Manager выбрать сайт, для которого нужно увеличить лимиты, затем открыть Request Filtering, на правой панели выбреть Edit Features… и затем изменить максимально допустимый размер принимаемого контента.

Способ 2. Добавить в web.config файл в корневой директории веб-сайта следующие строки (секция system.webServer):

Способ 3. Выполнить из командной строки следующую команды:

appcmd set config «Default Web Site» -section:requestFiltering -requestLimits.maxAllowedContentLength:104857600 -commitpath:apphost

Кстати, уже несколько дней меня волнует вопрос, можно ли на .NET изобразить модуль для IIS, который бы обрабатывал RAW-данные, поступающие от клиента, на ранней стадии? Чтобы все эти лимиты ему не мешались?

IIS Управление памятью и пороги с потенциальными утечками

Мы запускаем веб-серверы X64 Win Server 2012 (So IIS 8).

Мы замечаем, что свободная память на коробках постоянно сидит на 5-10% бесплатно. На самом деле мы запускаем довольно много приложений на этих ящиках (13 сайтов, 80 приложений на 13 пулов приложений). Большая часть кода дублируется для каждого сайта, так как они соответствуют другой базе данных и физическому сайту, но приложение одинаково.

Мы уверены, что у нас есть утечка памяти в приложении, так как память просто продолжает расти, поэтому мы смотрим на это прямо сейчас, но кое-что меня смущает, так это распределение памяти и управление IIS. Мне интересно, не отличается ли это для серверов IIS 8 или x64 (мы недавно перешли на x64).

Таким образом, в основном у каждого нашего веб-сервера было 6 ГБ памяти, и он сидел бы на 5-10% свободной памяти. Верхнее приложение, которое, как мы уверены, протекает, использует колоссальную 1,2 гб памяти. Следующий был около 800 МБ, а остальные составляли примерно 400-500 МБ (все эти значения являются частной памятью, как видно из диспетчера задач). Как я уже сказал, код дублируется, поэтому, если есть утечка на одном сайте, он будет во всех Их просто разные физические объекты могут включать или отключать некоторые функции, что объясняет большое несоответствие.

Хотя мы решаем проблему, мы решили просто сохранить память, чтобы мы не столкнулись с проблемами. Поэтому вчера вечером я сбил каждый сервер и удвоил память до 12 ГБ. Сегодня утром 3 сервера сидят на 77%, 80% и 82% используют память. Все процессы увеличили использование памяти в 1,5-2 раза.

Илон Маск рекомендует:  Asp использование объектов iis admin

Так что теперь я смущен. Это действительно утечка памяти? Или есть какое-то предопределение памяти? Или он никогда не выпускает память, если другой процесс не запрашивает ее на сервере SQL Server?


Что удерживало уровни памяти под контролем в 6 ГБ, если они внезапно растут настолько огромными, когда память удваивается? Есть ли пороги, которые установлены? Является ли IIS / ASP просто не сборкой мусора до тех пор, пока память не будет низкой или что?

Любые ответы приветствуются.

One Solution collect form web for “IIS Управление памятью и пороги с потенциальными утечками”

Не волнуйся! Вы можете просто перекрыть кеширование!

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

Кэширование в режиме ядра управляется собственным HTTP-драйвером (также известный как http.sys) и является молниеносно, но может обслуживать только контент, который является «общедоступным», так как он должен иметь возможность реагировать на попадание в кэш до того, как запрос достигнет веб приложение.
К сожалению, это означает, что количество типов запросов не может быть кэшировано в режиме ядра, включая авторизованные сеансы (например, посещение веб-сайтов, требующих проверки подлинности).

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

С другой стороны, кэширование пользовательского режима управляется на уровне приложения, а кешированные объекты хранятся в наборе памяти обслуживающего рабочего процесса. Общий размер кеша определяется атрибутом maxCacheSize в system.webServer/Caching конфигурации system.webServer/Caching .

По умолчанию атрибут maxCacheSize устанавливается maxCacheSize 0 который грубо переводит на Let IIS, выделяя столько памяти, сколько в настоящее время допустимо .

Если у вас много последовательных небольших (

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

Если вы все еще уверены, что у вас есть проблема с памятью в вашем приложении, запустите Performance Monitor и посмотрите на объект счетчика производительности ASP.NET приложений.
Выберите счетчики GC и посмотрите, как рассеивается сбор мусора.

Коллекции Gen0 должны представлять почти все выбытия, тогда как большое количество коллекций Gen1 и Gen2 может указывать на проблему с более длительным сроком жизни объекта, что является общим симптомом отказавшего управления памятью

Iis об управлении памятью

��� ������ ����, ������� ��� �������.
Sep 10 00:01:53 WAS: 5077: A worker process with process id of ‘307388’
serving application pool ‘second-hand66.ru(domain)(2.0)(pool)’ has
requested a recycle because it reached its virtual memory limit.
Sep 10 00:05:53 WAS: 5077: A worker process with process id of ‘312520’
serving application pool ‘second-hand66.ru(domain)(2.0)(pool)’ has
requested a recycle because it reached its virtual memory limit.

IIS Worker Process on Windows Server 2012 Memory Limit

I have an ASP.NET 4.0 application running on IIS hosted under a Windows Server 2012 with 8 GB total physical memory.

I noticed that the IIS Worker Process size is considerably increasing as users are logging into the application and performing their tasks.

I’m really lost on how to setup this application in order to avoid memory outage or application crash.

My question is, what is the maximum size the IIS Worker Process can reach on a Windows Server 2012 with 8GB RAM?

Do you advise me to run the Application Pool in 32-bit mode or 64-bit mode?

Do you advise me to use Web Gardening (Increase the number of IIS Worker Processes) ? What are the side-effects of using this option?


1 Answer 1

The question is quite broad, but I think it can be partially answered.

Possible memory leaks — if the w3wp process memory (Commit Size or Memory) continues to rise, even if the number of users does not increase anymore, than you may leak memory. Check this question for more details

Application pool memory limit — maximum allowed memory for a worker process can be configured per application pool -> Recycle conditions -> Memory Based Maximums. When this memory limit is reached, the application pool is recycled (a shutdown event is sent and the actual shutdown is performed after Shutdown Limit (90 seconds by default))

No application pool memory limit — in this case, I think the limit will depending on how much memory a .NET process can allocate on your specific architecture. Using information from here, in your particular case, the memory limit should be 70% of RAM + Pagefile.

However, if memory usage is high, you should also take into consideration the following:

IIS 7.0: краткая инструкция для системного администратора. Часть 1 – пpoверка результатов установки.

Продолжаем говорить об процедуре установки веб сервера под управлением IIS 7.0 на Windows Server 2008, которая была рассмотрена в предыдущем посте.

Теперь перейдем к проверке результатов установки IIS 7.0. Самый простой вариант проверить, работает ли веб сервер, особенно – находясь за локальной консолью, это обратиться из любого веб-браузера по адресу http://localhost/. Далее, проверить с локальной и удаленной машины по IP-адресу.

При установке IIS 7.0 создается веб сайт по умолчанию, сконфигурированный на ответ при любом URL-запросе, поступившем на порт 80 любого сетевого интерфейса сервера, на котором установлен IIS 7.0. Т.е. запрос браузера типа http://localhost/ должен быть обработан как запрос к веб сайту по умолчанию. Содержимое сайта по умолчанию представляет собой 2 файла – iisstart.htm и welcome.png (который отображается в iisstart.htm), которые и будут открыты клиентом. Поэтому результат обращения к localhost будет иметь следующий вид:

Теперь, если все хорошо (если «плохо» – поиск неисправностей и ошибок мы рассмотрим позже, в отдельном разделе), убедимся, что все модули, которые должны быть установлены по умолчанию – подключены и работают, а базовая конфигурация – отвечает нашим требованиям.

1. Основным инструментом управления IIS 7.0 является консоль Internet Information Services (IIS) Manager, которая устанавливается по умолчанию, вместе с ролью Web Server в Windows Server 2008 (IIS Management Console, раздел Management Tools при установки модулей). После соответствующей установки консоль управления IIS 7.0 можно найти, как дочернюю запись внутри раздела Web Server (IIS) в разделе ролей Server Manager, либо как пункт в разделе Administrative Tools меню Start, либо выполнив команду inetmgr (в командной строке или через пункт Run того же меню Start).

2. При старте консоль Internet Information Services (IIS) Manager открывается с «домашней страницей», на которой в виде панелей находится информация о том, к каким веб серверам и веб сайтам подключался пользователь консоли до этого (если консоль только установлена вместе с ролью Web Server (IIS), то в консоле присутствует запись только о локальном веб сервере), также присутствуют ссылки для выбора подключения к другим серверам, веб сайтам, веб приложениям и папкам, а также ссылки на внешние ресурсы, посвященные IIS.

3. Кроме того, на домашней странице присутствует панель новостей, которые подгружаются как новостная RSS-лента с сайта www.iis.net, если администратор нажимает на ссылку Enable IIS News. Новости, кстати, очень полезные, рекомендуется включать и использовать эту информацию в повседневной работе.

4. При подключении к какому либо веб серверу IIS 7.0 консоль Internet Information Services (IIS) Manager представляет его конфигурацию, как логическую структуру – уровень самого веб сервера, чьи настройки являются глобальными и распространяются по умолчанию на все веб сайты, пулы приложений и, сообственно, веб сайты со своими настройками. Эта конфигурационная иерархия, в виде разворачивающегося дерева, начинающегося с узла с именем (или IP) веб сервера, отображается в левой панели консоли Internet Information Services (IIS) Manager.

5. Если выбрать какой-то узел в дереве конфигурации, то в центральной панель консоли Internet Information Services (IIS) Manager будут отображены в виде отдельных иконок все параметры (а также – модули или списки), соответствующие конфигурации выбранного узла, а в правой панели – набор контекстных задач и операций, которые администратор (или пользователь) может выполнить над данным узлом.

6. Выбираем верхний узел, узел веб сервера, в котором представлены иконки, отвечающие за параметры работы модулей всего веб сервера, эти параметры наследуются по умолчанию для всех веб сайтов. Убеждаемся, что все необходимые модули установлены и отображены. Снимок экрана при установке конфигурации по умолчанию приведен ниже.

7. В правой панели при выборе узла веб сайта отображаются все операции, возможные для выполнения непосредственно с веб сервером (службами IIS в целом) в данном конексте – перезапуск, останов, запуск, переход к пулам приложений и сайтам.

8. Убеждаемся, что пулы приложений (Application Pools) сконфигурированы. Пулы приложений будут рассмотрены позже. Пулы являются дочерним узлом в дереве конфигурации для узла веб сайта. При установке по умолчанию создается только один пул – DefaultAppPool, в котором регистрируется одно приложение – сконфигурированный по умолчанию веб сайт, работу которого мы уже проверили. См. снимок экрана.

9. Ниже узла пулов приложений в дереве конфигурации находится узел веб сайтов (Sites), при выборе которого отображается список работающих на данном веб сервере веб сайтов. По умолчанию создается один веб сайт под названием Default Web Site с внутренним номером (ID) равным 1, «привязанный» на 80 порт всех IP-адресах всех сетевых интерфейсов к любому URL в запросе, и использующий в качестве домашнего каталога своего контента каталог с путем %SystemDrive%\inetpub\wwwroot (что при установленном Windows Server 2008 на диск C: соответствует C: \inetpub\wwwroot).

10. При выборе в левой панели консоли узла веб сайта (Default Web Site), также, как и в случае с выбором узла веб сервера, в центральной панели отображаются иконки для доступа к параметрам конфигурации различных модулей, на этот раз – конкретного веб сайта. Убеждаемся, что также, как и в случае со всем веб сервером, все необходимые модули представлены в центральной панели.

11. В правой панели консоли, аналогично панели для всего веб сервера, отображаются контекстные команды, правда, на этот раз их список серьезно расширен – старт/стоп/перезапуск процесса веб сайта, просмотр его базовых и расширенных настроек (а не параметров модулей), настройки привязки (адрес, порт, доменное имя – по сочетанию которых будет отвечать на запросы данный веб сайт) и т.п.

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

12. Выберите узел веб сервера в дереве конфигурации в левой панели консоли Internet Information Services (IIS) Manager. В центральной панели кликните на иконку Modules. В центральной панели откроется следующий полный список установленных по умолчанию модулей, представляющий из себя перечень .dll файлов.

13. Чтобы убедиться, что веб сервер будет работать только со статическими файлами (по умолчанию) или только с нужными вам расширениями – выберите снова узел веб сервера и в центральной панели кликните на иконку Handler Mappings. Откроется список «привязки» расширений вызываемых на веб сайте пользователем файлов и привязанных к данным расширениям модулям, выполняющим обработку данного вызова. Обратите внимание, что по умолчанию все файлы привязаны к модулю обработки статических файлов (т.е. запрос какого либо скриптового или исполнимого файла из домашнего каталога веб сайта не будет приводить к его исполнению на сервере, а лишь к передаче данного файла пользователю), а также к модулям документа по умолчанию и просмотра каталога. С этими модулями мы познакомимся позже.

14. И, наконец, для того, чтобы убедиться в безопасности веб сайта – проверьте параметры его аутентификации. Для этого выбираем иконку Authentication в той же центральной панели. По умолчанию никаких модулей аутентификации веб сервер (и веб сайты) не поддерживает. Т.е. все подключения для него анонимны. В чем безопасность? Это значит, что пользователям будет доступен только то содержимое домашних каталогов сайтов – файлы и подкаталоги – которые имеют NTFS разрешения для чтения «всем» (Everyone). В случае, если таких разрешений файл не имеет, пользователю будет отказано в доступе с соответствующей ошибкой 401. Если же пользователь попробует каким-то образом аутентифицироваться в процессе HTTP запроса на сервере – то поскольку никаких модулей аутентификации, кроме анонимного, на веб сервере не установлено – он снова получит соответствующую ошибку 401.

Такие настройки безопасности по умолчанию – только анонимные пользователи – позволяют гарантировать защиту данных на сервере, для которых требуются соответствующие разрешения, а также – что механизм аутентификации веб сервера (которого в данном случае просто нет) не будет использован для перебора паролей и прочих попыток «взлома» через учетные записи.

Итак, сервер установлен и его работоспособность проверена. Теперь достаточно поместить какой либо статический контент (файлы HTML, изображения, документы и файлы для выгрузки пользователями) в домашний каталог его сайта по умолчанию (напоминаю, что это в большинстве случаев C:\inetpub\wwwroot) – и веб сайт под управлением IIS 7.0 начнет работать. Ну, и конечно, для внешних сайтов – не забыть прописать их A-record в вашей доменной зоне на публичном DNS сервере.

В следующей части – установка IIS 7.0 в режиме командной строки, особенности работы IIS 7.0 на Server Core.

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL