Iis о загрузке процессора


Содержание

Iis о загрузке процессора

Группа: Главные администраторы
Сообщений: 14349
Регистрация: 12.10.2007
Из: Twilight Zone
Пользователь №: 1

IIS*,
Серверная оптимизация*,
ASP*,
.NET*,
Веб-разработка*
В данной публикации речь пойдёт о настройке важных параметров пула ASP.NET-приложений при вызове удалённых веб-сервисов и активной работе с сетью на стороне сервера через стандартные классы .NET.

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

Итак, приступаем. Ускоряем сайт на ASP.NET — экономим деньги предприятия и нервы администратора.

В конце прошлого года в одной крупной организации мы столкнулись с проблемами производительности веб-серверов при резко увеличившейся пользовательской нагрузке. В веб-приложении на тот момент было зарегистрировано более 200 000 клиентов. В обычном режиме одновременно работает около 1000 пользователей, за день примерно 10-15% уникальных посетителей от общего числа зарегистрированных, поэтому нагрузка относительно невысокая. Однако существуют пиковые нагрузки, при которых система оказывается практически неработоспособной.

Веб-администаторы проверили всё, что можно, и никак не могли понять, в чём дело. Ведь несмотря на то, что по всем основным параметрам системы на физическом уровне с производительностью было всё хорошо, возникали сбои с доступностью сервисов, а в пуле собиралась огромная очередь запросов. В организации используется NLB-кластер на 4 узла (Windows Server 2008 R2 + IIS 7.5 + .NET 4.5), есть запас по загрузке ЦП и памяти, сетевые каналы большие, количество используемых портов достаточное. Все проверки указывали на то, что проблемы кроются в недрах IIS и настройке пула ASP.NET. Живой пример, когда администраторам не помешала бы помощь опытных веб-разработчиков…

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

Общее описание конфигурации .NETНачиная с IIS 7, все настройки конфигурации ASP.NET хранятся в XML-файлах (*.config). Они заменили метабазу, которая использовалась в IIS 6.0 и более ранних версиях.

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

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

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

Здесь же находится файл machine.config.comments, который позволяет узнать, какие параметры используются по умолчанию. С помощью этих данных в machine.config можно добавить параметры с переопределенными значениями.

Корнем иерархии конфигурации ASP.NET является файл web.config, расположенный в том же каталоге, что и machine.config. Этот файл включает в себя параметры, которые используются для всех приложений ASP.NET.

ApplicationHost.config — корневой файл конфигурации IIS, включает в себя описание всех сайтов, приложений, виртуальных каталогов и пулов приложений, а также глобальные установки по умолчанию для параметров веб-сервера. Он находится в следующих папках в зависимости от версии ОС:

  • для 32-битной — %WINDIR%System32inetsrvconfig
  • для 64-битной — %WINDIR%SysWOW64inetsrvconfig

Каждый локальный файл web.config применяет параметры конфигурации для каталога, в котором он расположен, а также для всех дочерних каталогов. Настройки вложенных каталогов могут быть переопределены собственными “конфигами”.

Прежде чем начинать настройку конфигурации IIS, обратите внимание на счетчики производительности ASP.NET, оцените текущую и пиковую загрузки системы, зафиксируйте имеющиеся показатели. Проверьте логи на наличие ошибки “HTTP Error 503.2 — Service Unavailable”. Постарайтесь определить, не блокируется ли часть запросов в очереди.

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

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

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

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

cd %windir%system32inetsrv
appcmd.exe set config /section:system.webserver/serverRuntime /appConcurrentRequestLimit:20000

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

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

Для установки данного параметра наиболее часто используется формула:

, где usersCount — количество одновременно работающих пользователей.

2. Параметр QueueLength — максимальное количество запросов, которые драйвер Http.sys размещает в очереди пула приложений. Когда очередь заполнена, новые запросы получают ошибку «503.2 — Service Unavailable». Значение по умолчанию — 5000.

Данный параметр можно настроить несколькими способами:

  • глобально для .NET на уровне сервера через machine.config, секция processModel/requestQueueLimit;
  • на уровне IIS через ApplicationHost.config: system.web/httpRuntime -> appRequestQueueLimit;
  • задать значение параметра queueLength для конкретного пула.

В качестве примера изменим данный параметр для пула «DefaultAppPool» через командную строку:

appcmd.exe set apppool «DefaultAppPool» /queueLength:20000

Выполняем команду, затем открываем в 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-адреса текущих запросов.

2. Настройка ASP.NET

ASP.NET ограничивает число рабочих потоков и потоков портов завершения вызова, используемых для выполнения запросов. Если веб-приложение на стороне сервера активно использует вызовы внешних веб-сервисов, стандартные классы из пространства имён System.NET для организации запросов по сети, то могут возникнуть конфликты низкой производительности и взаимоблокировок. Вначале часть запросов может просто “подвисать”, время выполнения будет значительно возрастать. В худшем случае, если используется классический режим настройки пула (classic pipeline), это вообще может привести к перезагрузке пула (recycle). Обнаружение взаимоблокировки ASP.NET не выполняется для пула, запущенного в integrated mode (по умолчанию в IIS 7 и выше).

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

На рисунке ниже наглядно видно, как происходит обработка запросов в ASP.NET и какие параметры имеют наиболее важное значение:

Рис. 7. Процесс обработки запросов в ASP.NET

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

Хорошенько “покопавшись” в MSDN и файле machine.config.comments, я нашёл описание базовой конфигурации пула. Есть 7 основных параметров, влиящих на работу ASP.NET с сервисами и сетью:

  • maxConnection
  • maxWorkerThreads / minWorkerThreads
  • maxIoThreads / minIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads

Параметр maxconnection определяет максимальное количество одновременных запросов с одного IP-адреса. При включенной по умолчанию автоконфигурации пула этот параметр определяется по формуле:

maxConnection = 12 * cpuNum, где cpuNum — это количество ядер процессора

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

Самый простой способ обойти данное ограничение — это прямо в коде своего ASP.NET приложения в методе Application_Start в файле global.asax указать следующее:

// maximum number of concurrent connections allowed by a ServicePoint object
System.Net.ServicePointManager.DefaultConnectionLimit = Int16.MaxValue;

Более гибко настраивать maxconnection лучше через конфигурационные файлы на уровне домена приложения (web.config) или веб-сервера (applicationHost.config). Секция содержит параметры, которые определяют, как .NET Framework подключается к сети.

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

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

ASP.NET через параметр maxWorkerThreads устанавливает ограничения потоков на рабочем процессе w3wp.exe (начиная с IIS 7). В связи с тем, что ASP.NET встроена в IIS, процессы ASP.NET формируют запросы на рабочих потоках. Из-за недостаточного количества потоков в CLR ThreadPool запросы будут становиться в очередь и “подвисать”.

Аттрибуты, заданные в секции :

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

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

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

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

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

Аттрибуты, заданные в секции :

1. Параметр minFreeThreads — определяет количество потоков, которые могут быть использованы для работы, кроме обработки входящих запросов к рабочему процессу. Этот параметр не дает процессу ASP.NET использовать потоки из пула для обработки нового HTTP-запроса, если общее число потоков в пуле опустится ниже этого предела. Значение по умолчанию — 8.

2. Параметр minLocalRequestFreeThreads — определяет минимальное количество свободных потоков, которые ASP.NET держит доступными для выполнения новых локальных запросов. Значение по умолчанию — 4.

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

ASP.NET не будет выполнять более, чем следующее количество одновременных запросов:

(maxWorkerThreads * число ЦП) — minFreeThreads

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

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

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

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

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

WMIC CPU Get DeviceID,NumberOfCores,NumberOfLogicalProcessors
илиecho %NUMBER_OF_PROCESSORS%

Например, на сервере с 4-мя процессорами и свойством autoConfigtrue» ASP.NET будет иметь следующие параметры по умолчанию:

maxConnection – 48; maxWorkerThreads – 80; maxIoThreads – 80, minFreeThreads – 8, minLocalRequestFreeThreads – 4.

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

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

В этом разделе приведены только рекомендации, а не правила. Причём дата публикации этих данных довольно давняя. Для нашей “боевой” системы мы используем немного другие параметры конфигурации. Данные формулы — хорошая отправная точка для старта оптимизации, они хорошо показывают зависимость параметров друг от друга. Например, увеличив значение параметра maxConnection в несколько раз, вы легко можете “прикинуть” базовые значения для остальных параметров.

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

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

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

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

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

Для анализа производительности веб-серверов рекомендую настроить счётчики ASP.NET через Performance Monitor:

  • ASP.NET ApplicationsRequests/Sec
  • Web ServiceISAPI Extension Requests/sec
  • ASP.NETRequests Current
  • ASP.NETRequests Queued
  • ASP.NET Requests Rejected
  • ASP.NET ApplicationsRequests Executing
  • ASP.NET ApplicationsRequests Timed Out
  • ASP.NET Request Execution Time

Для более глубокого анализа процесса w3wp.exe, обслуживающего пул приложений IIS, можно попробовать отладчик WinDbg из Windows Software Development Kit.

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

Для лучшего понимания работы IIS рекомендую ознакомиться, как происходит процесс обработки запроса от браузера пользователя до конечного пула приложения ASP.NET в этой полезной статье «Основы архитектуры IIS, или запросопровод для ASP.NET».

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

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

Если ваш сайт работает хорошо и вы можете оценить предполагаемую нагрузку на систему, то не стоит ничего менять. Если же у вас начинаются “зависания” при обработке запросов к различным сервисам — не следует сразу винить во всем железо! Лучше внести изменения в базовую конфигурацию ASP.NET. Имейте в виду, что изменение базовых параметров пула приложений непременно приведёт к увеличению загрузки процессора. Оптимальная балансировка всех параметров системы — ключ к стабильной и производительной работе оборудования. Как говорится, “предупрежден — значит вооружен”.

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

Отладка высокой загрузки процессора в процессе IIS

Высокое использование ЦП в процессе IIS

В настоящее время я изучаю использование большого количества процессоров на одном из наших производственных серверов, я застрял и надеюсь, что кто-то здесь сможет помочь. Сравнение использования ЦП с количеством входящих вызовов веб-сервиса (WCF и REST) ​​говорит мне, что они не связаны, использование ЦП, похоже, растет, когда вызовы увеличиваются или снижаются.

Настройка

  • Сервер Windows® R2 R2 x64
  • IIS 8.5
  • .NET 4.5
  • Один пул приложений, запускающий наше приложение
  • Автозагрузка приложения в 00:00

Проблема

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

Данные

Анализируя taskmanager и используя счетчики perfmon, я смог подтвердить, что это действительно наш W3WP-процесс, который потребляет процессор.

Я сконфигурировал DebugDiag 2.1, чтобы взять 3 отвала памяти на 10 секунд, когда потребление ЦП повысилось на 50% более чем на 10 секунд. (обычное использование ЦП до того, как эта проблема была 5-10%)

Заглядывая в файлы дампа с помощью ntsd, я вижу, что несколько потоков потребляют много CPU:

(Здесь показаны только некоторые из потоков) Поэтому я пытаюсь понять, что происходит в этих потоках, поскольку это не ожидаемое поведение. Кажется, что все потоки с длинными задачами управляются, НО когда когда-либо я пытаюсь! Clrstack на любом из них я получаю:

Что меня смущает, поскольку я ожидал управляемый стек. Когда я смотрю на собственный стек, я получаю что-то другое:

Это заставляет меня поверить, что поток ждет какой-то ресурс (это правильно?), и именно здесь я действительно теряюсь! Что происходит в этих строках в середине трассы:


Я предполагаю, что некоторые управляемые вещи здесь, но почему? clrstack не работает? Посмотрев на первый кадр, он смотрит на меня, поскольку он ждет некоторого дескриптора ресурса. Я выгляжу как ручка 0xa, но я далек от этого. Глядя на дескриптор с! Handle 0xa ff, я получаю следующее:

Рассказывая мне, что это указывает на файл, но WHAT файл, как я могу перейти отсюда? Глядя на другие верхние потоки ВПП дает мне ту же картину.

Крик о помощи

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

Новости

После создания нашего отдела. зарегистрируйте набор данных perfMon для меня с некоторыми счетчиками, которые я нашел интересными, я пришел к выводу: 1) Мы протекаем потоки 2) GC сходит с ума (вероятно, из-за утечки). Любые идеи о том, как определить, что вызывает утечку потока? Смотрите счетчики здесь: 2

После обнаружения того, что мы протекаем потоки, я изучал наш код и нашел код интереса:

Как устранить проблему того, что приложение ASP.NET web forms сильно грузит сервер и тупит?

Добрый день всем!

Есть два ресурса (веб-сайта), которые написаны с использованием C#, ASP.NET Web Forms, одно более ранее, другое попозже.
Есть два веб-сервера, вычислительные мощности которых, положим, равны.

Проблема в следующем:
Более старый ресурс периодически начинает очень долго открываться и виснуть, иногда после долгого ожидания все такие открывается, бывает, что времени ожидания ответа от сервера не хватает, чтобы дождаться ответа.
Тех. поддержкой серверов занимается другой отдел, после звонка им выяснилось, что на сервере, при доступе к ресурсу запускается 3 процесса IIS, они грузят процессор сервера на 100%. Но, никаких скриптов особо тяжелых при загрузке портала не запускается. После перезагрузки сервера ресурс открывается.
Проблема в том, что никакой периодичности подвисания нет, обычно портал работает шустро и никаких зависов не наблюдается.

В общем вопрос такой, так как опыта пока не особо хватает, хотелось бы понять в каком направлении копать? Есть подозрение, что остальные два IIS процесса, которые грузят сервер — это два еще более старых ресурса, которые лежат физически на этом же сервере, но которые не используются (по крайней мере явно, но, возможно на них есть ссылки из более нового ресурса, который виснет, проблема в том, что удалить эти ресурсы безболезненно не выйдет, так как про внедрение зависимостей и слабую связность в те времена, когда писали те ресурсы, еще никто не слыхал)

WordPress на IIS: высокая загрузка процессора

мы используем WP 4.0 на IIS 7 и интенсивно используем процессор: регулярно добавляем до 25% для одного процесса (php-cgi.exe) в пул (w3wp.exe), который иногда суммируется за 3 или больше процессов до> 60% (как видно из sysinternals Process Explorer).
Я уже проверил, что FastCgi активен и даже установил wincache для php — что помогло немного. А также я деактивировал все плагины — что также принесло лишь незначительное улучшение.

  • 3 процессора Intel Xeon 3,7 ГГц
  • 12 ГБ оперативной памяти
  • WP 4.0
  • Microsoft IIS 7
  • Версия PHP: 5.3.23 / 32-битная ОС
  • Ограничение памяти: 128 МБ
  • Использование памяти: 21,65 МБ
Илон Маск рекомендует:  Как добавить пространство вокруг текста ячеек

Есть идеи, что можно сделать по этому поводу? Изменить некоторые настройки для FastCgi или Wincache? Нужно ли нам лучшее оборудование?

Решение

Это рабочий сервер? Я мог только догадываться … Требуется больше информации, чем просто указание ресурсов, которые у вас есть. Я дам вам несколько очков, чтобы начать.

Похоже, у вас много памяти и ресурсов процессора. Ваше оборудование СКАЛА и вам не нужно лучшее оборудование! Но! Одна большая проблема, которую я вижу, — это ОС (на мой взгляд). Есть ли что-нибудь еще на этой машине?

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

Попробуйте установить для параметра Макс. Экземпляров в разделе IIS Server -> FastCGI Settings значение 1.

Попробуйте отследить, какие именно запросы вызывают php-cgi.exe и используют процессор.

И в конце концов, я бы порекомендовал запустить WordPress на Linux-машине с NGINX и, если возможно, Lighttpd для обслуживания статического контента, если вы не удовлетворены обоими, попробуйте запустить Apache 2.4 с MySQL 5.5. Например, установите Oracle VM Virtualbox и запустите ОС Debian или любую другую удобную для вас систему и посмотрите, есть ли у вас такая же проблема.
Если ОС Windows не нужна ни для чего другого (чего мы еще не знаем), по возможности, переключитесь на благоприятный Linux.

How prevent CPU usage 100% because of worker process in iis

My CPU usage is 100% most of the the time in Windows Server 2008-R2 with my own vps, vmware, quad core, and 4GB Ram. When I open windows Task Manager and go to the resource monitor I see that 100% usage is because of workerprocess.exe . I have 3 websites in my IIS.

  • How can I figure out which web site causes that usage
  • How can I limit it to 80% usage of CPU?
  • Could it be a DDOS attack?
  • Is there any way to prevent DDOS?

I installed eset-nod32 on my vps, but it doesn’t show any attack in the logs. I’ve tried searching about IIS and preventing DDOS, and just found an extension for banning IP addresses, but how can I find which IP address are generating traffic?

The web site is written in ASP.NET and C# . How can I determine what is happening on that web site and which lines of codes are causing that cpu usage?

Also, one of my web sites should access administrator’s desktop and read and write some files. So because of that I changed its application pool -> identity (Process Model) to local system, and I don’t know if it is related with the CPU usage or not.

8 Answers 8

Well, this can take long time to figure out. Few points to narrow it down:

  • Identify what is killing the CPU. I recommend Process Explorer http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
  • Identify what AppPool is causing this
  • Fix your code

Diagnosing

In terms of diagnosing what App Pool is causing trouble, you can:

  1. Select the server
  2. Go to IIS > Worker Processes

This should bring up a menu like this so you can determine which App Pool is running amok.

From there you can simply restart the the app pool and 9 times out of 10 that will fix any immediate issues you’re having.

Treating

Unless you run some sort of controversial business, this is probably not a DDOS attack. It’s likely that some code is just hanging because it couldn’t get through to another server or got stuck in a loop or mis-allocated resources or your app pool just hasn’t been recycled in a while.

You can deal with this problem programmatically without having to manually identify, log in, and recycle the app pool. Just configure the CPU property on your App Pool. You can have it kill (and automatically restart) your process anytime you reach a CPU threshold for a certain amount of time.

In your case, if you want it to restart at 80%, you can right click on the app pool and go to Advanced Settings and apply the following configurations:

NOTE: As kraken101 pointed out, different IIS GUIs have treated this differently over time. While the config value is always in 1/1000 of a %, sometimes the GUI takes the whole percent.

You can add this to your config section like this:

Preventing

The steps above will help fix some things once they’ve broken, but won’t really solve any underlying issues you have.

Here are some resources on doing performance monitoring:

Use PerfMon to collect data and DebugDiag to analyse.

Found this link while searching for similar issue.

I was facing the same issues recently and found a solution which worked for me and reduced the memory consumption level upto a great extent.

Solution:

First of all find the application which is causing heavy memory usage.

You can find this in the Details section of the Task Manager.

  1. Open the IIS manager.
  2. Click on Application Pools. You’ll find many application pools which your system is using.
  3. Now from the task manager you’ve found which application is causing the heavy memory consumption. There would be multiple options for that and you need to select the one which is having ‘1’ in it’s Application column of your web application.
  4. When you click on the application pool on the right hand side you’ll see an option Advance settings under Edit Application pools. Go to Advanced Settings. 5.Now under General category set the Enable 32-bit Applications to True
  5. Restart the IIS server or you can see the consumption goes down in performance section of your Task Manager.

If this solution works for you please add a comment so that I can know.

Ограничиваем пропускную способность IIS на сервере SCCM с ролью SUP (WSUS).

В процессе централизованной раздачи клиентам System Center 2012 R2 Configuration Manager (SCCM) очередной порции обновлений с сервера с ролью Software Update Point (SUP)столкнулись с ситуацией пиковой загрузки на канале передачи данных — участка с низкой пропускной способностью на канале между структурными подразделениями и площадкой, на которой был расположен сервер SCCM. По графику отдачи трафика на сервере SCCM было хорошо видно, что исходящий трафик “упёрся” в границу того самого “узкого места на канале. Разумеется таких ситуаций чаще всего можно избежать заранее настраивая приоритизацию трафика на разных уровнях, начиная с сетевого оборудования. Но что делать, если по какой-то причине проблема возникла прямо здесь и прямо сейчас, а доступа к сетевому оборудованию нет. То есть фактически нужно как-то оперативно “задушить” трафик отдачи обновлений Windows Update на определённый момент времени средствами Windows. Простое и эффективное решение подсказал автор заметки Ограничиваем аппетиты WSUS-а .

В качестве решения предлагается ограничение общей пропускной способности (в байтах) веб-сервера IIS. За это отвечает параметр maxGlobalBandwidth в разделе конфигурации IIS — system.applicationHost/webLimits .

Чтобы запросить текущие значения параметров в указанном разделе конфигурации IIS с помощью утилиты командной строки appcmd.exe выполним:

В полученном ответе мы увидим, что значение по умолчанию для интересующего нас параметра параметра – 4294967295:

Предположим, нам нужно уменьшить полосу пропускания трафика IIS до 20 Mbit/s. Рассчитаем необходимое значение параметра в байтах: (20 * 1024 * 1024)/8 = 2 621 440 байт.

Выполним команду установки рассчитанного значения:

В ответ получим сообщение об успешном применении параметра конфигурации:

Туже самую настройку можно выполнить и через консоль IIS Manager, перейдя на уровне веб-сервера в раздел Management > Configuration Editor

В поле Section из выпадающего дерева элементов конфигурации выберем system.applicationHost/webLimits , зададим значение интересующего нас параметра maxGlobalBandwidth и нажмём в правом меню действий Apply, чтобы изменения вступили в силу.

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

Сразу после применения рассчитанного нами параметра ситуация изменилась на глазах…

Таким образом критическая ситуация загрузки канала была ликвидирована.

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

Десять лучших способов улучшения производительности IIS 7.0

Посетителей: 11846 | Просмотров: 14496 (сегодня 2) Шрифт:

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

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

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

Скорее всего, просто переход на IIS 7.0 не выявит всех преимуществ нового веб-сервера, хотя в некоторых случаях и этого будет достаточно. Например, на узле Microsoft.com было отмечено 10-процентное улучшение эффективности использования ЦП (полный анализ доступен в блоге группы разработки Microsoft.com наgo.microsoft.com/fwlink/?Link >® (оба процесса теперь выполняются на уровне ядра), а также улучшение вертикальной масштабируемости на многопроцессорных и многоядерных машинах.

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

Экономичные веб-серверы

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

Полный набор функций веб-сервера IIS 7.0 состоит из 44 модулей, включая собственные модули IIS и ASP.NET, предоставляющие службы для интегрированного конвейера. В модулях реализованы такие функции, как проверка подлинности (модули проверки подлинности Windows и дайджест-проверки подлинности), поддержка инфраструктуры приложения (модуль FastCGI), службы приложений (модуль состояния сеанса), обеспечение безопасности (модуль фильтрации запросов) и производительности (модуль кэширования выходных данных). Однако минимальному веб-серверу, обслуживающему статические страницы, для работы требуется всего 2 модуля!

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

На рис. 1 показаны результаты простых тестов пропускной способности для HTML-файла (статическая нагрузка) и страницы «Здравствуй, мир», написанной на ASP.NET (нагрузка ASP.NET). Использовались три конфигурации веб-сервера: с полным набором функций, с предлагаемым по умолчанию набором функций для каждого типа нагрузки и с минимальным набором необходимых для каждого типа нагрузки функций. Можно заметить, что, хотя большинство необязательных функций отключены даже в полной конфигурации сервера, пропускную способность можно существенно увеличить как в случае статической нагрузки, так и при работе ASP.NET, если полностью удалить ненужные функции.

Рис. 1. Пропускная способность сервера при статической нагрузке и работе с ASP.NET в трех разных конфигурациях со 100 параллельно подключенными клиентами

Кроме того, может снизиться объем занимаемой памяти и повыситься плотность веб-узлов, особенно в случае сред совместного размещения или при использования большого количества рабочих процессов. Это происходит за счет уменьшения количества библиотек DLL, загружаемых каждым процессом, а также количества запросов на выделение памяти, происходящих при инициализации модуля и обработке запроса. На рис. 2 изображено использование памяти (в байтах исключительного использования рабочими процессами IIS) в тестах пропускной способности, о которых говорилось выше. И, хотя приведенные в этом примере изменения не так заметны, они, тем не менее, соответствуют всем ожиданиям. Дело в том, что поддержка приложений ASP.NET требует больше служебных данных, чем можно высвободить удалением модулей.

Рис. 2 Использование памяти (в байтах исключительного использования рабочими процессами IIS) сервером при статической нагрузке и работе с ASP.NET в трех разных конфигурациях со 100 параллельно подключенными клиентами

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

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

Использование экономичной операционной системы

В Windows Server ® 2008 реализовано выделение компонентов на уровне операционной системы, посредством чего можно дополнительно сократить контактную зону веб-сервера. Минимальным режимом установки Windows Server 2008 является режим «Server Core», который содержит минимальный набор основных подсистем операционной системы. Для экономичных веб-серверов на базе IIS 7.0 лучшим вариантом установки является именно Server Core.

Однако, рассматривая возможности Server Core, необходимо учитывать, какие его ограничения могут отразиться на работе вашего приложения. В Server Core отсуствует поддержка платформы Microsoft ® .NET Framework, то есть нет ASP.NET, расширений.NET для IIS и диспетчера служб IIS. Кроме того, решение задач местного управления потребует использования средств командной строки, поскольку консоль управления (MMC) также отсутствует. Между приложениями, работающими под управлением Server Core и полной версией Windows Server, не будет особых отличий в объеме занимаемой памяти и пропускной способности приложений, если уже были использованы преимущества компонентной структуры IIS. Работа, выполняемая IIS и вашими приложениями, одинакова на обеих платформах. Однако есть характеристика, где разница будет заметна: место, занимаемое сервером, как на жестком диске, так и в оперативной памяти.

В качестве примера на рис. 3 показана разница в занимаемом объеме после одинаковой статической рабочей нагрузки на серверы, работающие под управлением Windows Server 2008 в полной конфигурации и Server Core. Хотя IIS занимает в обоих случаях почти одинаковое место, общий объем места, занимаемого операционной системой Server Core меньше, что позволяет поддерживать ту же рабочую нагрузку, используя существенно меньший объем памяти. Из-за меньшего размер установки может появиться возможность использовать менее мощное аппаратное обеспечение для работы приложения. При этом основная мощность процессора будет тратиться на обработку запросов приложения, а не операционной системы, что делает Server Core отличным вариантом для виртуализированных сред.

Рис. 3. Память, занимаемая Windows Server 2008 в полной конфигурации и Server Core после выполнения теста на статическую нагрузку

Применение топологий, адаптированных для нужд приложения

Оптимизируя нагрузку на приложение, в ней можно выделить отдельные части. Например, вместо 30 одинаковых веб-серверов можно обойтись 10 веб-серверами, 3 серверами приложений и 3 прокси-серверами, последние из которых будут выполняли бы кэширование и сжатие данных.

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

Во-вторых, специализация может привести к тому, что приложение будет лучше размещено в кэше, что увеличит его производительность. Это относится к кэшам низкого уровня, таким как аппаратный буфер TLB виртуальной памяти, кэш файловой системы, а также другие средства кэширования, реализуемые как операционной системой, так и приложением. Другим источником хорошего местоположения является ЦП. Уменьшение числа одновременно выполняемых операций путем уделения основного внимания только определенной части приложения позволяет уменьшить количество переключений контекста максимально увеличить объем работы, выполняемой ЦП.

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

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

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

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

Улучшенная поддержка приложения

Службы IIS 7.0 включают в себя расширенную поддержку платформ приложений с помощью FastCGI, открытого протокола, поддерживаемого множеством платформ приложений с открытым исходным кодом, которые в противном случае могут не поддерживать надежную и высокопроизводительную собственную интеграцию с IIS. В отличие от протокола CGI, который в течение длительного времени поддерживался IIS, FastCGI обеспечивает значительно улучшенную производительность на платформе Windows. В основном это обусловлено архитектурой многократно используемых процессов FastCGI, уменьшающей значительные затраты на создание процессов для отдельных запросов, что позволяет клиентам использовать преимущества постоянных открытых соединений.

Илон Маск рекомендует:  Арендуем виртуальную ИТ-инфраструктуру и облачные ИТ-сервисы

При поддержке платформ приложений в IIS с помощью CGI или другого механизма можно улучшить производительность (а в некоторых случаях и стабильность) путем перехода на протокол FastCGI.

Первой платформой приложений, использующей преимущества этой поддержки, является PHP. Группа разработчиков IIS фактически напрямую работала с компанией Zend Technologies для обеспечения успешной работы реализации FastCGI IIS с PHP и улучшения производительности платформы PHP в Windows. (Более подробные сведения об этом проекте см. в моем блоге по адресу go.microsoft.com/fwlink/?Link >

Перенос PHP и других платформ приложений на IIS 7.0 и FastCGI позволит использовать преимущества различных функций IIS 7.0, в том числе интегрированный контейнер ASP.NET. Это предоставляет очень удобный способ улучшения платформ приложений при помощи служб ASP.NET без их преобразования в ASP.NET. Это также позволяет совместно работать приложениям, использующим различные платформы. Пример использования этого для улучшения существующих приложений при помощи функций и повышения производительности без изменения кода см. в моей статье «Улучшите приложения при помощи интегрированного конвейера ASP.NET» в журнале MSDN ® Magazine (доступна по адресу msdn.microsoft.com/magazine/cc135973.aspx).

Увеличенная плотность приложений

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

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

Обратите внимание на то, что службы IIS 7.0 теперь позволяют подготавливать на каждом сервере больше приложений, чем раньше — в нескольких внутренних тестах достигалась цифра в 100 000 узлов на одном сервере. Это обеспечивает возможность создания и настройки большого числа узлов и приложений.

В качестве предупреждения: для достижения высокоскоростной подготовки необходимо перейти на новые API настройки, поскольку старые API настройки не позволяют этого. Кроме того, не все API настройки IIS предоставляют одинаковые характеристики производительности, поэтому для обеспечения максимальной производительности необходим тщательный выбор API. При возникновении сомнений используйте параметры конфигурации, которые напрямую используют новые объекты настройки IIS, включая пространство имен Microsoft.Web.Administration, служебную программу командной строки AppCmd.exe и объекты настройки IIS COM, которые можно вызвать из сценария, кода .NET или C++.

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

Поскольку для каждого активного приложения необходим определенный объем памяти и рабочий процесс (при использовании рекомендуемой модели изоляции приложений), количество активных приложений сильно зависит от объема памяти приложения. Поэтому хотя для рабочего процесса одного приложения, выполняющего только обслуживание статического содержимого, требуется всего 3 МБ (подобные приложения часто могут использовать рабочий процесс совместно с другими приложениями, работающими со статическим содержим), для некоторых динамических приложений может требоваться 100 МБ ОЗУ или больше даже при низкой загрузке. Это обуславливает незначительную загрузку памяти самим рабочим процессом IIS по сравнению с местом, которое занимает приложение, при определении максимальной возможной плотности.

В типичном сценарии совместного размещения часто можно увидеть так называемое распределение 80/20, когда 80 процентов запросов выполняются к 20 процентам узлов. Результат – небольшой процент активных узлов в любой определенный момент времени. Для обеспечения большего количества активных узлов службы IIS 7.0 предоставляют активное управление временем существования. Это помогает высвободить память неактивных приложений, чтобы можно было разместить большее количество активных приложений.

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

Для обеспечения возможности размещения множества активных приложений также следует использовать преимущества 64-разрядной операционной системы, заключающиеся в возможности использования более 4 ГБ ОЗУ. На основе этого можно настроить рабочие процессы IIS для работы в 32-разрядном режиме (SysWoW64), в котором они используют меньше памяти, одновременно позволяя операционной системе работать с большим объемом памяти, чем возможно в 32-разрядной среде.

Сокращение занимаемой полосы пропускания за счет сжатия данных


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

Одним из наиболее эффективных способов уменьшения полосы пропускания, необходимой для доставки ответов приложения, является использование сжатия HTTP. Оно позволяет значительно уменьшить размер ответа, часто даже в 10 раз, для просто сжимаемого содержимого, такого как HTML. Лучше всего то, что сжатие HTTP поддерживают практически все обозреватели для настольных систем, а затраты на распаковку на оборудовании настольных систем минимальны по сравнению с неявной экономией отправки меньшего количества данных. А поскольку сжатие основано на согласовании кодировки содержимого, определенном в протоколе HTTP 1.1, включение этой функции безопасно для клиентов, не поддерживающих сжатие — эти клиенты просто получают несжатую версию содержимого.

Службы IIS 7.0 предоставляет две функции сжатия, представленные в их предшественнике: статическое сжатие и динамическое сжатие. Статическое сжатие выполняет предварительное сжатие статического содержимого и сохраняет его на диск, таким образом, позволяя будущим запросам работать напрямую со сжатым содержимым без затрат на сжатие. Динамическое сжатие выполняет сжатие ответов в реальном времени, и позволяет сжимать созданные приложениями ответы. Все платформы приложений на IIS 7.0 могут использовать преимущества динамического сжатия, включая ASP, ASP.NET и PHP.

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

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

Регулировка полосы пропускания для мультимедийных файлов

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

Вспомните, когда вы последний раз смотрели интерактивное видео или видели видеорекламу при просмотре веб-узлов. Вы досмотрели видео до конца? Чаще всего пользователи, посещающие узлы с видео, просматривают только часть видео до того, как перейти к следующему или уйти с веб-страницы. Однако веб-сервер, использующий прогрессивную загрузку для предоставления видео, обычно отправляет гораздо больше данных, чем необходимо для этих нескольких секунд воспроизведения. Большая часть данных никогда не используется.

Если среднее время просмотра ваших видео составляет всего 5 секунд, но за это время предоставляются (буферизируются) видеоданные длительностью 30 секунд, скорее всего, вы теряете более 80 процентов полосы пропускания!

Год назад для разрешения этой проблемы для клиента, переходящего на бета-выпуск IIS 7.0, я написал модуль регулировки полосы пропускания, автоматически определяющий скорость видео и обеспечивающий предоставление сервером видео клиенту приблизительно с этой же скоростью. Группа мультимедиа IIS использовала этот модуль, называющийся модулем регулировки скорости (см. рис. 4 ) и доступный в центре загрузок iis.net (iis.net/downloads/?tab >

Рис. 4. Регулировки скорости уменьшает использование полосы пропускания

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

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

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

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

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

Кроме того, кэш ядра IIS 7.0 также предоставляет высокопроизводительную альтернативу кэшу вывода ASP.NET для содержимого ASP.NET, не требующего дополнительных функций кэширования (таких как зависимости кэша и недействительность данных в кэше), которые доступны только в кэше вывода ASP.NET.

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

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

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

Преобразование кода ISAPI в модули IIS 7.0

В IIS 7.0 появился новый серверный интерфейс API, на котором основаны все модули IIS 7.0. Он заменяет устаревшие интерфейсы API ISAPI Filter и ISAPI Extension, использовавшиеся в предыдущих версиях IIS. Для новых модулей, которым не требуется поддержка предыдущих версий, новые API более просты в использовании, позволяют улучшить надежность серверного кода и гораздо более эффективны.

Однако IIS 7.0 предоставляет возможность поддержки существующих фильтров и расширений ISAPI путем использования слоя совместимости, реализуемого посредством дополнительных модулей IIS 7.0. Это позволяет существующим компонентам ISAPI работать в IIS 7.0 без необходимости переписывания.

Хотя использование существующих вложений в ISAPI снижает планку для перехода на IIS 7.0, следует серьезно рассмотреть перенос устаревшего кода ISAPI на новые API IIS 7.0. Это устраняет затраты на слой совместимости ISAPI и позволяет использовать преимущества производительности, недоступные для компонентов ISAPI. В зависимости от работы, выполняемой компонентом ISAPI, эти преимущества производительности могут быть довольно значительными. Например, API модуля IIS 7.0 предоставляет встроенную поддержку кэширования метаданных конфигурации и других произвольных данных, связанных с узлами, приложениями, URL-адресами, что можно значительно увеличить скорость выполнения внутренних операций компонента.

Помимо этого, API модуля IIS позволяет модулям асинхронно выполнять длительные операции, такие как получение данных объекта запроса и отправка ответа. Асинхронное выполнение этих задач позволяет серверу масштабироваться до большого количества одновременно клиентов (десятки тысяч) вместо прежнего максимального количества в несколько десятков или самое большое нескольких сотен одновременных клиентов из-за ограничений количества потоков запросов. Асинхронная обработка также может устранить эффект обработки на других запросах и действиях в приложении, снизить загрузку памяти и обеспечить гораздо лучшее использование ЦП.

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

Для этого могут быть необходимы определенные эксперименты и прототипы для определения оптимальной архитектуры, наилучшим образом использующую улучшения перехода. Из-за фундаментальных архитектурных различий ISAPI и API модуля IIS 7.0 прямой маршрут переноса не всегда является верным. Хорошая новость заключается в том, что API модуля IIS 7.0 также более прост в использовании, чем ISAPI, что упрощает переход.

Расширяемость сервера

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

Это может быть выполнено путем замены каких-либо встроенных функций IIS 7.0 пользовательскими реализациями. Хотя IIS 7.0 претерпели значительную оптимизацию и тестирование производительности, они, конечно же, не оптимизированы для всех возможных применений. Поэтому можно повысить производительность определенных модулей путем создания оптимизаций для конкретной рабочей нагрузки. Например, можно решить повторно реализовать модуль вывода каталогов для кэширования списков содержимого каталогов в памяти вместо использования интерфейсов API операционной системы для перечисления файлов.

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

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

Заключение

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

Настройка 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. Если вы увидите слишком большое количество перезапусков без явной на то причины, попробуйте сопоставить полученные значения с потреблением памяти приложением и нагрузкой на процессор, потому что перезапуски могут быть обусловлены превышением других пределов, определяемых настройками пула приложения.

Илон Маск рекомендует:  Borland delphi 4 0 для начинающих типы данных указательные типы

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

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

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

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

Веб-сад

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

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

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

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

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

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

Как я и обещал в посте несколько дней назад, начинаю писать серию постов типа инструкций шаг за шагом «как это установить и настроить» для тех админов, у которых действительно мало времени «на найти и разобраться», да еще если все это на английском языке. Кстати, кому таки не лениво – вот здесь очень хорошая подборка англоязычных документов под общим названием «Windows Server 2008 Step-by-Step Guides» — очень полезно в работе. Надеюсь, найдутся время и ресурсы, чтобы их тоже «отфильтровать» и сделать на их базе русские версии.

Если вам не интересны мои мысли «почему я пишу про IIS 7.0», можете смело пропустить пару абзацев.

В ближайший месяц я буду писать о веб-платформе от Microsoft, и в основном это будет касаться администрирования Internet Information Services 7.0 (IIS 7.0), входящего в состав Windows Server 2008. Это не значит, что я не буду писать ни о чем другом – конечно буду, у меня масса планов и тем с барселонского TechEd IT Forum 2008, в основном по направлению Windows Server 2008 R2, просто про администрирование IIS7 буду писать в этот месяц намного чаще и более последовательно, чем я это делал ранее. Поэтому даже те, для кого тема IIS7 не интересна, смогут как минимум раз в неделю находить у меня на блоге что-то интересное по другим тематикам.

Почему именно IIS 7.0? Здесь несколько причин. Во-первых, в уже упомянутом сборнике документов «шаг за шагом» «Windows Server 2008 Step-by-Step Guides» по странному стечению обстоятельств документа по IIS 7.0 почему-то нет. Во-вторых, как показывает опыт семинаров TechNet в Украине – знания, и даже можно сказать – представления многих админов о технологиях Microsoft для веб базируются на «сказках-страшилках» конца прошлого века, и хотелось бы показать всем желающим простой путь попробовать все технологии самостоятельно, без каких-то предрассудков и прочих ОБС. В-третьих – мне самому, человеку, который достаточно долгий период своей жизни занимался вебом вообще и IIS в частности – а я помню и IIS 2.0, и 3.0, и 4.0 и, конечно же, 5.0 – эта тема близка и интересна, и могу сказать, что за 10 лет в этом направлении Microsoft сделал существенные, даже можно сказать – эпохальные шаги вперед. Потому хотелось бы поделиться и опытом, и знаниями в этой прогрессирующей области с коллегами. В-четвертых – небольшой сюрприз в рамках проводимой в Украине акции для тех, кто разворачивает и управляет веб-серверами под управлением продуктов Microsoft – украинский офис Microsoft проводит акцию, по которой вы можете получить лицензионный Windows Server 2008 Web Edition (коробочная версия) бесплатно для хостинга ваших проектов и сайтов в Интернете. Так что торопитесь получить такой легальный продукт – пишите через блог на почту. И, наконец, в-пятых – в Киеве проводится полигон по веб-технологиям Microsoft, в том числе и IIS 7.0, так что мои статьи послужат хорошим фоном для такого мероприятия.

Ну, вроде это вcе наиболее веские причины писать в ближайший месяц о IIS 7.0. Кроме одной – зачем вообще админу знание IIS 7.0, который, в принципе, больше является платформой для разработчиков, на которой они делают свои веб-проекты? Проблема в том, что, как показывает опыт, разработчики не очень «напрягаются» созданием архитектуры и проработкой деталей веб-проекта, таких, как безопасность, администрирование, масштабирование и т.п. будущего работаеющего решения. И все это становится головной болью админа. Другая головная боль – это работодатели, которые часто под словом «компьютерщик» понимают, что человек может и спаять сгоревшую плату, и сетку настроить, и программку бухгалтерскую написать. И конечно же – веб сайт родной фирмы «Рога и Ко» сделать – как же без него. А то, что в ИТ отрасли есть глубокая специализация – никого не волнует. И вот потом и пишет мне в Live Messenger такой админ – «Игорь, а что делать?! За что хвататься?!», или если такого «Игоря», который бы подсказал, нет рядом – начинается такое.

Вроде, мотивы мои всем понятны. получилось довольно длинно, обещаю, сами технические части будут куда короче. Итак.

Часть 1. Установка IIS 7.0

Первый вопрос, который мне задают – что такое веб сервер под Windows, что нужно установить? Ответ – вебсервер под Windows – это служба IIS 7.0. Следующий вопрос – где взять IIS 7.0, откуда скачать? Ответ очень простой – IIS 7.0 (как и предыдущие версии, начиная с IIS 5.0) интегрирован в саму серверную ОС Microsoft Windows Server 2008 (а предыдущие версии IIS – соответственно в Windows Server 2003 и Windows 2000) и устанавливается как роль Windows Server. Тогда более тривиальный вопрос – где взять «настоящий» Windows Server 2008? Пробную версию Windows Server 2008 для всех экспериментов и тестирования рекомендую брать только с сайта Microsoft http://www.microsoft.com/windowsserver2008 — проверенная и гарантированно правильная версия (только не забудьте установить все обновления). Серийный номер для Windows Server 2008 не требуется – вы просто при установке в мастере установки оставляете его пустым и на вопрос, хотите ли вы все же его заполнить – гордо отвечаете НЕТ. Фактически, если вы при установке или в ходе эксплуатации таки введете настоящий продуктовый номер – вы получите «настоящую» версию. Версия без введенного серийного номера работает 60 дней, после чего требует активации. Мало кто любит читать иструкции при загрузке файлов, особенно те, которые написаны мелким шрифтом – на самом деле, на странице загрузке есть ссылка на инструкцию, какой скрипт надо запустить, чтобы сбросить счетчик активации Windows снова на 60 дней. Такую операцию надо не забыть сделать до истечения 60дневного срока (например, на 59й день эксплуатации). Всего вы можете посторить операцию сброса счетчика 3 раза – т.е. пробную версию можно эксплуатировать 240 дней, что вполне достаточно с тем, чтобы распробовать плюсы и минусы системы. Ну а для желающих уже сейчас эксплуатировать лицензионный Windows Server 2008 для своих веб-проектов – напоминаю про акцию, пишите.

Теперь о выборе редакции, которых доступно аж 4 – Datacenter, Enterprise, Standard, Web Edition. Пожалуйста, подходите более ответственно к их выбору. Зачем, ну зачем использовать Enterprise для запуска веб-сайтов – «шоб було?». Для таких задач есть оптимизированная редакция Web Edition. Сравнение возможностей разных редакций можно найти там же, на официальном сайте http://www.microsoft.com/windowsserver2008. Кроме того, некоторые соображения по использованию лицензионных соглашений и виртуализации в разных редакциях я написал на этом блоге ранее.

После установки экземпляра Windows Server 2008 и его конфигурации (если это также вызывает затруднения – смотрим видео с семинара по Windows Server 2008) переходим непосредственно к установке IIS 7.0. Что нового в IIS 7.0, какие модули включены в него и т.д. – я рассматривать не буду, все теоретические выкладки можно найти в электронной версии журнала TechNet Magazine, которая выходит в том числе и на русском. IIS 7.0 были посвящены 2 статьи в мартовском и июльском номерах журнала. Рекомендую ознакомиться с ними перед практическим применение – знание теории, пусть даже в сжатой форме весьма полезно.

Основным нововведением в направлении установки различных компонент и служб в Windows Server 2008 является понятие «роли». Роль представляет из себя набор всех необходимых компонент, настроек системы, безопасности и т.п., которые необходимы для выполнения определенной задачи. Кроме того, имеется также информация о взаимодействии ролей между собой – одна роль может работать как подмножество другой и, наоборот – роли могут конфликтовать между собой – об этом администратор будет уведомлен при установке такой роли поверх уже существующих. Установку и конфигурацию всего необходимого система выполняет автоматически при выборе конкретной роли. Такой подход гарантирует, что даже в случае ошибки администратора, связанной с установкой той или иной роли, не требуемой в текущий момент – система будет функционировать нормально и это не затронет работоспособность других ролей. Как впрочем, это также существенно упрощает и сам подход к управлению системой Windows Server 2008 в целом.

Управление ролями осуществляется через стандартную оснастку управления Windows Server 2008 – Server Manager или в процессе начальной конфигурации сервера через Initial Configuration Tasks.

IIS 7.0 устанавливается как роль Windows Server 2008. Для этого требуется:

1. Запустить оснастку Server Manager из меню Start или из панели Quick Launch. Server Manager по умолчанию стартует автоматически при входе администратора в систему. Server Manager является основным инструментом управления сервером Windows Server 2008.

2. В оснастке на стартовой странице убедиться, что сервер сконфигурирован правильно. Желательно проверить наличие статического IP адреса. Если он не установлен, его можно поменять тут же, из консоли Server Manager, открыв в правой панели по линку «View Network Connections» сетевые интерфейсы.

3. Выбираем в левой панели Server Manager пункт Roles, в правой панели видим список текущих ролей. В зависимости от редакции ОС и установленных ролей список может варьироваться. В данном примере ни одна роль не установлена.

4. Для установки новой роли используем в правой панели в разделе «Roles Summary» линк «Add Roles».

5. Запускается мастер установки ролей «Add Roles Wizard», пропускаем первую страницу «Before You Begin» мастера, нажав кнопку «Next >»

6. На странице «Select Server Roles» в списке ролей выбираем роль «Web Server (IIS)». Список ролей может отличаться в зависимости от редакции. Данный список соответствует редакции Windows Server 2008 Enterprise Edition x64.

7. При выборе роли «Web Server (IIS)» мастер автоматически предлагает установить сервисы, которые требуются для функционирования веб сервера. Это службы активации процессов, фактически, они обеспечивают среду исполнения процессов, обслуживающих вебсайты. Соглашаемся с установкой данных служб путем нажатия кнопки «Add Required Features» и нажимаем кнопку «Next >» в мастере.

8. На странице «Select Role Services» отображается список всех доступных модулей (сервисов), входящих в состав IIS 7.0, представляющих 3 большие группы – Web, Management и FTP – и внутри сгруппированых по назначению – общие модули для поддержки HTTP Common HTTP Features, модули для исполнения сценариев и приложений Application Development, модули управления журналированием и диагностикой Health and Diagnostics, модули обеспечения безопасности Security, производительности Performance, модули управления и совместимости с предыдущей версией IIS 6.0 Management Tools, и, наконец, модули FTP. По умолчанию роль веб сервера IIS 7.0 устанавливается и конфигурируется в минимальном наборе из 9 модулей:

a. только для работы со статическим HTML контентом (модули из Common HTTP Features),

b. только с подключением анонимных пользователей и с фильтрацией вредоносных запросов (Security),

c. с базовыми модулями для журналирования запросов к вебсайтам на сервере и просмотра очереди запросов (Health and Diagnostics),

d. с модулем сжатия статического контента при передаче страниц клиенту HTTP (Performance),

e. и консоли администрирования в режиме локального подключения к веб серверу IIS Management Console.

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

10. При отметке отдельного модуля для добавления, также, как и при выборе роли, мастер автоматически проводит проверку всех связей и зависимостей и предлагает установить дополнительные модули, без которых функционирование выбраного невозможно. В данном примере для установки выбран модуль ASP.NET и мастер автоматически запрашивает разрешение на установку других модулей и служб, необходимых для его работы. Соглашаемся с установкой данных служб и модулей путем нажатия кнопки «Add Required Role Services». По окончанию выбора всех модулей нажимаем кнопку «Next >» в мастере.

11. На странице «Confirm Installation Selection» отображается для подтверждения информация о всех выбранных модулях, которые будут установлены. Также отображаются служебные и информационные сообщения рекомендательного характера. Например, рекомендация после установки роли IIS 7.0 выполнить обновления ОС или установить Windows System Resource Manager (WSRM), который позволяет обеспечить распределение ресурсов системы при выполнении веб-приложений. Нажатие кнопки «Next >» на этой странице устанавливает весь указанный перечень модулей.

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

13. После закрытия окна мастера установки роли в левой панели консоли Server Manager в разделе «Roles» среди других ролей появляется подраздел «Web Server (IIS)». В правой панели отображается информация о состоянии всех установленных ролей.

14. Выбираем подраздел «Web Server (IIS)» в левой панели Server Manager, в правой панели отображается информация о работе роли веб сервера. Здесь представлены:

a. Events: агрегированный список записей из всех журналов событий ОС за последние 24 часа, имеющих отношение к работе веб служб,

b. System Services: список всех системных сервисов, обеспечивающих функционирование данной роли и с возможностями по управлению ими и мониторингу их состояний,

c. Role Services: в данном случае – список всех модулей IIS 7.0 с указанием установлен данный модуль или нет и с возможностями старта мастера установки/удаления модулей данной роли (о котором мы говорили выше),

d. Resources and Support: наиболее интересный раздел информации о каждой роли, который содержит в себе базу знаний с рекомендациями по дополнительной более тонкой настройке той или иной роли для отдельных сценариев использования. Рекомендуется к широкому использованию.

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

Отладка высокой загрузки процессора в процессе IIS

Высокое использование ЦП в процессе IIS

В настоящее время я изучаю использование большого количества процессоров на одном из наших производственных серверов, я застрял и надеюсь, что кто-то здесь сможет помочь. Сравнение использования ЦП с количеством входящих вызовов веб-сервиса (WCF и REST) ​​говорит мне, что они не связаны, использование ЦП, похоже, растет, когда вызовы увеличиваются или снижаются.

Настройка

  • Сервер Windows® R2 R2 x64
  • IIS 8.5
  • .NET 4.5
  • Один пул приложений, запускающий наше приложение
  • Автозагрузка приложения в 00:00

Проблема

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

Данные

Анализируя taskmanager и используя счетчики perfmon, я смог подтвердить, что это действительно наш W3WP-процесс, который потребляет процессор.

Я сконфигурировал DebugDiag 2.1, чтобы взять 3 отвала памяти на 10 секунд, когда потребление ЦП повысилось на 50% более чем на 10 секунд. (обычное использование ЦП до того, как эта проблема была 5-10%)

Заглядывая в файлы дампа с помощью ntsd, я вижу, что несколько потоков потребляют много CPU:

(Здесь показаны только некоторые из потоков) Поэтому я пытаюсь понять, что происходит в этих потоках, поскольку это не ожидаемое поведение. Кажется, что все потоки с длинными задачами управляются, НО когда когда-либо я пытаюсь! Clrstack на любом из них я получаю:

Что меня смущает, поскольку я ожидал управляемый стек. Когда я смотрю на собственный стек, я получаю что-то другое:

Это заставляет меня поверить, что поток ждет какой-то ресурс (это правильно?), и именно здесь я действительно теряюсь! Что происходит в этих строках в середине трассы:

Я предполагаю, что некоторые управляемые вещи здесь, но почему? clrstack не работает? Посмотрев на первый кадр, он смотрит на меня, поскольку он ждет некоторого дескриптора ресурса. Я выгляжу как ручка 0xa, но я далек от этого. Глядя на дескриптор с! Handle 0xa ff, я получаю следующее:

Рассказывая мне, что это указывает на файл, но WHAT файл, как я могу перейти отсюда? Глядя на другие верхние потоки ВПП дает мне ту же картину.

Крик о помощи

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

Новости

После создания нашего отдела. зарегистрируйте набор данных perfMon для меня с некоторыми счетчиками, которые я нашел интересными, я пришел к выводу: 1) Мы протекаем потоки 2) GC сходит с ума (вероятно, из-за утечки). Любые идеи о том, как определить, что вызывает утечку потока? Смотрите счетчики здесь: 2

После обнаружения того, что мы протекаем потоки, я изучал наш код и нашел код интереса:

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