Как ограничить число php-cgi процессов для mod_fcgid? Многопроцессный Firefox: тестирование продолжается.

17 дек 2010

У нас вы можете скачать бесплатно .
Данный материал предоставлен сайтом исключительно в ознакомительных целях. Администрация не несет ответственности за его содержимое.

В этой статье я опишу принципиальные различия Apache и Nginx, архитектуру фронтэнд-бэкэнд, установку Apache в качестве бэкэнда и Nginx в качестве фронтэнда. А также опишу технологию, позволяющую ускорить работу веб-сервера: gzip_static+yuicompressor.

Nginx – сервер легкий; он запускает указанное число процессов (обычно число процессов = числу ядер), и каждый процесс в цикле принимает новые соединения, обрабатывает текущие. Такая модель позволяет с низкими затратами ресурсов обслуживать большое количество клиентов. Однако, при такой модели, нельзя выполнять длительные операции при обработке запроса (например mod_php), т.к. это по сути повесит сервер. При каждом цикле внутри процесса по сути выполняются две операции: считать блок данных откуда-то, записать куда-то. Откуда-то и куда-то – это соединение с клиентом, соединение с другим веб-сервером или FastCGI-процессом, файловая система, буфер в памяти. Модель работы настраивается двумя основными параметрами:
worker_processes – число запускаемых процессов. Обычно устанавливают равным числу ядер процессора.
worker_connections – максимальное число соединений, обрабатываемых одним процессом. Напрямую зависит от максимального числа открытых файловых дескрипторов в системе (1024 по умолчанию в Linux).

Apache – сервер тяжелый (следует заметить, что при желании его можно достаточно облегчить, однако это не изменит его архитектуры); он имеет две основных модели работы – prefork и worker.
При использовании модели prefork Apache создает новый процесс для обработки каждого запроса, и этот процесс выполняет всю работу: принимает запрос, генерирует контент, отдает пользователю. Настраивается эта модель следующими параметрами:


MinSpareServers – минимальное число висящих без дела процессов. Нужно это для того, чтобы при поступлении запроса быстрее начать его обрабатывать. Веб-сервер будет запускать дополнительные процессы, чтобы их было указанное количество.
MaxSpareServers – максимальное число висящих без дела процессов. Это нужно, чтобы не занимать лишнюю память. Веб-сервер будет убивать лишние процессы.
MaxClients – максимальное число параллельно обслуживаемых клиентов. Веб-сервер не запустит более указанного количества процессов.
MaxRequestsPerChild – максимальное число запросов, которые обработает процесс, после чего веб-сервер убьет его. Опять же, для экономии памяти, т.к. память в процессах будет постепенно «утекать».

Эта модель была единственной, которую поддерживал Apache 1.3. Она стабильная, не требует от системы многопоточности, но потребляет много ресурсов и немного проигрывает по скорости модели worker.
При использовании модели worker Apache создает несколько процессов, по несколько потоков в каждом. При этом каждый запрос полностью обрабатывается в отдельном потоке. Чуть менее стабильна, чем prefork, т.к. крах потока может привести к краху всего процесса, но работает немного быстрее, потребляя меньше ресурсов. Настраивается эта модель следующими параметрами:

StartServers – задает число запускаемых процессов при старте веб-сервера.
MinSpareThreads – минимальное число потоков, висящих без дела, в каждом процессе.
MaxSpareThreads – максимальное число потоков, висящих без дела, в каждом процессе.
ThreadsPerChild – задает число потоков, запускаемых каждым процессом при старте процесса.
MaxClients – максимальное число параллельно обслуживаемых клиентов. В данном случае задает общее число потоков во всех процессах.
MaxRequestsPerChild – максимальное число запросов, которые обработает процесс, после чего веб-сервер убьет его.

Фронтэнд-бэкэнд

Основная проблема Apache – на каждый запрос выделен отдельный процесс (как минимум – поток), который к тому же увешан различными модулями и потребляет немало ресурсов. Вдобавок, этот процесс будет висеть в памяти до тех пор, пока не отдаст весь контент клиенту. Если у клиента узкий канал, а контент достаточно объемный, то это может занять длительное время. Например, сервер сгенерирует контент за 0,1 сек, а отдавать клиенту его будет 10 сек, все это время занимая системные ресурсы.
Для решения этой проблемы используется архитектура фронтэнд-бэкэнд. Суть ее в том, что запрос клиента приходит на легкий сервер, с архитектурой типа Nginx (фронтэнд), который перенаправляет (проксирует) запрос на тяжелый сервер (бэкэнд). Бэкэнд формирует контент, очень быстро его отдает фронтэнду и освобождает системные ресурсы. Фронтэнд кладет результат работы бэкэнда в свой буфер и может долго и упорно отдавать его (результат) клиенту, потребляя при этом намного меньше ресурсов, чем бэкэнд. Дополнительно фронтэнд может самостоятельно обрабатывать запросы статических файлов (css, js, картинки и т.д.), управлять доступом, проверять авторизацию и т.д.

Настройка связки Nginx (фронтэнд) + Apache (бэкэнд)

Предполагается, что Nginx и Apache у вас уже установлены. Необходимо настроить сервера так, чтобы они слушали разные порты. При этом, если оба сервера установлены на одной машине, бэкэнд лучше вешать только на loopback-интерфейс (127.0.0.1). В Nginx это настраивается директивой listen:

В Apache это настраивается директивой Listen:

Listen 127.0.0.1:81

Далее нужно указать Nginx проксировать запросы на бэкэнд. Это делается директивой proxy_pass 127.0.0.1:81;. Это вся минимальная конфигурация. Однако выше мы говорили, что отдачу статических файлов лучше тоже поручить Nginx. Допустим, что у нас типичный сайт на PHP. Тогда нам нужно проксировать на Apache только запросы к.php файлам, обрабатывая все остальное на Nginx (если ваш сайт использует mod_rewrite, то реврайты тоже можно делать на Nginx, а.htaccess файлы просто выкинуть). Также необходимо учесть, что запрос клиента приходит на Nginx, а запрос к Apache делает уже Nginx, поэтому https-заголовка Host не будет, а адрес клиента (REMOTE_ADDR) Apache определит как 127.0.0.1. Заголовок Host подставить несложно, а вот REMOTE_ADDR Apache определяет сам. Решается эта проблема при помощи mod_rpaf для Apache. Работает он следующим образом: Nginx знает IP клиента и добавляет некий https-заголовок (например X-Real-IP), в который прописывает этот IP. mod_rpaf получает этот заголовок и прописывает его содержимое в переменную REMOTE_ADDR Apache. Таким образом, php-скрипты, выполняемые Apache будут видеть реальный IP клиента.
Теперь конфигурация усложнится. Сначала позаботьтесь, чтобы и в Nginx, и в Apache существовал один и тот же виртуальный хост, с одинаковым корнем. Пример для Nginx:

server {
listen 80;
server_name сайт;
root /var/www/сайт/;
}

Пример для Apache:

ServerName сайт

Теперь задаем настройки для вышеописанной схемы:
Nginx:
server {
listen 80;
server_name сайт;
location / {
root /var/www/сайт/;
index index.php;
}
location ~ \.php($|\/) {
proxy_pass https://127.0.0.1:81;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
}
}


Apache:

# настройки mod_rpaf
RPAFenable On
RPAFproxy_ips 127.0.0.1
RPAFheader X-Real-IP


DocumentRoot "/var/www/сайт/"
ServerName сайт

Регулярное выражение \.php($|\/) описывает две ситуации: запрос к *.php и запрос к *.php/foo/bar. Второй вариант необходим для работы многих CMS..com/index.php (т.к. мы определили index-файл) и также будет проксирован на Apache.

Ускоряемся: gzip_static+yuicompressor

Gzip в Web это хорошо. Текстовые файлы отлично сжимаются, трафик экономится, и контент быстрее доставляется пользователю. Nginx умеет сжимать на лету, так что тут проблем нет. Однако на сжатие файла тратится определенное время, в том числе процессорное. И тут на помощь приходит директива Nginx gzip_static. Суть ее работы в следующем: если при запросе файла Nginx находит файл с таким же именем и дополнительным расширением ".gz", например, style.css и style.css.gz, то вместо того, чтобы сжимать style.css, Nginx прочитает с диска уже сжатый style.css.gz и отдаст его под видом сжатого style.css.
Настройки Nginx будут выглядеть так:

https {
...
gzip_static on;
gzip on;
gzip_comp_level 9;
gzip_types application/x-javascript text/css;
...

Прекрасно, мы один раз будем генерировать.gz файл, чтобы Nginx много раз его отдал. А дополнительно мы будем сжимать css и js при помощи YUI Compressor. Эта утилита максимально минимизирует css и js файлы, удаляя пробелы, сокращая наименования и т.д.
А заставить все это сжиматься автоматически, да еще и обновляться автоматически можно при помощи cron и небольшого скрипта. Пропишите в cron для запуска раз в сутки следующую команду:

/usr/bin/find /var/www -mmin 1500 -iname "*.js" -or -iname "*.css" | xargs -i -n 1 -P 2 packfile.sh

в параметре -P 2 укажите число ядер вашего процессора, не забудьте прописать полный путь к packfile.sh и изменить /var/www на ваш веб-каталог.
В файл packfile.sh пропишите.

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

Нас в первую очередь интересуют два подхода к хранению и работе с данными SQL и NoSQL.

SQL (Structured Query Language) - язык структурированных запросов, применяемый для создания, модификации и управления данными в реляционных базах данных, основанных на реляционной модели данных. Думаю, подробно останавливаться на рассмотрении одноименного подхода не стоит, так как это первое с чем сталкивается любой, при изучении баз данных.

NoSQL (not only SQL, не только SQL) - ряд подходов, направленных на реализацию моделей баз данных, имеющих существенные отличия от средств языка SQL, характерного для традиционных реляционных баз данных.

Термин NoSQL был придуман Эриком Эвансом, когда Джоан Оскарсон из Last.fm хотел организовать мероприятие для обсуждения распределенных баз данных с открытым исходным кодом.

Концепция NoSQL не является полным отрицанием языка SQL и реляционной модели. NoSQL - это важный и полезный, но не универсальный инструмент. Одна из проблем классических реляционных БД - это сложности при работе с данными очень большого объема и в высоконагруженных системах. Основная цель NoSQL - расширить возможности БД там, где SQL недостаточно гибок, не обеспечивает должной производительности, и не вытеснять его там, где он отвечает требованиям той или иной задачи.

В июле 2011 компания Couchbase, разработчик CouchDB, Memcached и Membase, анонсировала создание нового SQL-подобного языка запросов - UnQL (Unstructured Data Query Language). Работы по созданию нового языка выполнили создатель SQLite Ричард Гипп (Richard Hipp) и основатель проекта CouchDB Дэмиен Кац (Damien Katz). Разработка передана сообществу на правах общественного достояния

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

NoSQL системы

NoSQL СУБД

Определимся с понятиями.

Масштабируемость - автоматическое распределение данных между несколькими серверами. Такие системы мы называем распределенные базы данных. В них входят Cassandra, HBase, Riak, Scalaris и Voldemort. Если вы используете объем данных, который не может быть обработан на одной машине или если вы не хотите управлять распределением вручную, то это то, что вам нужно.

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

Прозрачное добавление машины в кластер

Поддержка нескольких датацентров

Необходимо доработать напильником

К нераспределенным базам данных относятся: CouchDB, MongoDB, Neo4j, Redis и Tokyo Cabinet . Эти системы можно использовать в качестве «прослойки» для распределенных систем.

Модель данных и запросов

Существует огромное количество моделей данных и API запросов в NoSQL базах данных.

Модель данных

API запросов

Семейство столбцов

Документы

Семейство столбцов

Документы

Коллекции

Документы

Nested hashes, REST

Ключ / Значение

Ключ / Значение

Ключ / Значение

Система семейства столбцов (column family) используется в Cassandra и HBase. В обеих системах, у вас есть строки и столбцы, но количество строк не велико: каждая строка имеет переменное число столбцов и столбцы не должны быть определены заранее.

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

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

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

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

Система хранения данных

Это вид, в котором данные представлены в системе.

Вид данных

Memtable / SSTable

Append-only B-Tree

Memtable / SSTable on HDFS

On-disk linked list

In-memory with background snapshots

Pluggable (primarily BDB MySQL)

Система хранения данных может помочь при оценке нагрузок.

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

Memtables / SSTables буферизируют запросы на запись в памяти (Memtable), а после записи добавляют в лог. После накопления достаточного количества записей, Memtable сортируется и записывается на диск, как SSTable. Это позволяет добиться производительности близкой к производительности оперативной памяти, в тоже время избавиться от проблем, актуальных при хранении только в памяти.

B-деревья используются в базах данных уже очень давно. Они обеспечивают надежную поддержку индексирования, однако производительность, при использовании на машинах с магнитными жесткими дисками, очень низкая.
Интересным является использование в CouchDB B-деревьев, только с функцией добавления (append-only B-Trees), что позволяет получить хорошую производительность при записи данных на диск. Достигается это тем, что бинарное дерево не нужно перестраивать при добавлении элемента.

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

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

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

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

Memcached имеет множество модификаций, развиваемых в рамках нескольких проектов: Mycached, membase, Memcache, MemcacheQ, Memcacheddb и libMemcached .

Центральный проект, локомотив концепции NoSQL - Memcached. Один из самых существенных минусов Memcached состоит в том, что сам кэш - весьма ненадежное место хранения данных. Устранить этот недостаток и призваны дополнительные решения: Memcacheddb и membase. На уровне интерфейса (API) эти продукты полностью совместимы с Memcached. Но здесь, при устаревании данных, они сбрасываются на диск (стратегия « db checkpoint »). В таком виде они представляют собой яркий пример «нереляционных баз данных» - персистентных (долговременных) систем распределённого хранения данных в виде пар «ключ-значение».

Следующий продукт, на основе Memcached - MemcacheQ. Это система очередей сообщений, в которой используется очень упрощенный API от Memcached. MemcacheQ образует именованный стек, куда можно записать свои сообщения, а сами данные физически хранятся в БД BerkeleyDB (аналогично Memcacheddb), следовательно, обеспечиваются сохранность, возможность реплицирования и прочее.

LibMemcached - это известная клиентская библиотека, написанная на С++, для работы с уже стандартным протоколом Memcached.

Все нереляционные хранилища, выполненные в виде распределенной системы и хранящие пары «ключ-значение», можно подразделить на два типа: устойчивые и неустойчивые. Устойчивые (например, MemcachedB, membase, Hypertable ) - записывают данные на диск, обеспечивая их сохранность в случае сбоя. Неустойчивые (классический Memcached) - хранят ключи в энергозависимой памяти и не гарантируют их сохранность. Неустойчивые хранилища оправдано использовать для кеширования и снижения нагрузки на устойчивые - в этом их неразрывная связь и главное преимущество.

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

Схема frontend+backend

Самая распространенная схема, при которой в роли frontend выступает быстрый и легкий web сервер (например Nginx), а в качестве backend работает Apache.

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

В случае применения схемы frontend+backend, после того как пришел запрос клиента, Nginx передает запрос Apache и быстро получает ответ. А в случае со статическим контентом (html, картинки, файлы кеша и пр.) Nginx самостоятельно сформирует ответ, не потревожив Apache. Если нам все-таки нужно выполнить логику (php-скрипт), Apache после того как сделал это и отдал ответ Nginx освобождает память, далее с клиентом взаимодействует web сервер Nginx, который как раз и предназначен для раздачи статического контента, большому количеству клиентов, при незначительном потреблении системных ресурсов. В купе с грамотным кэшированием, получаем колоссальную экономию ресурсов сервера и систему, которую по праву можно назвать высоконагруженной.

Рабочие лошадки

Apache - оптимизация производительности

Для схемы frontend+backend производительность Apache не стоит столь остро, но если Вам дорога каждая микросекунда процессорного времени и каждый байт оперативной памяти, то следует уделить внимание этому вопросу.

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

Загружайте только необходимые модули

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

Уменьшив количество модулей, Вы уменьшите объем потребляемой памяти. Если вы решили скомпилировать Apache самостоятельно, то либо тщательно подходите к выбору списка модулей, которые Вы хотите включить, либо скомпилируйте их как DSO, используя apxs в Apache1 и apxs2 в Apache2. Чтобы отключить ненужные DSO-модули, достаточно закомментировать лишние строчки LoadModule в httpd.conf. Если скомпилировать модули статически, Apache будет потреблять чуть меньше памяти, но Вам придется каждый раз его перекомпилировать, чтобы отключить или вкличить тот или иной модуль.

Выбирайте подходящий MPM

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

Если безопасность превыше производительности, выбирайте peruser или Apache-itk. Если важнее производительность, обратите внимание на prefork или worker.

Название

Разработчик

Поддерживаемые OS

Описание

Назначение

Apache Software Foundation

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

Среднезагруженные веб-серверы.

Стабильный.

Apache Software Foundation

MPM, основанная на предварительном создании отдельных процессов, не использующая механизм threads.

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

Стабильный.

Apache Software Foundation

Гибридная модель, с фиксированным количеством процессов.

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

В разработке, нестабильный.

Apache Software Foundation

Мультипоточная модель, оптимизированная для работы в среде NetWare.

Серверы Novell NetWare

Стабильный.

Apache Software Foundation

Microsoft Windows

Мультипоточная модель, созданная для операционной системы Microsoft Windows.

Серверы под управлением Windows Server.

Стабильный.

Steinar H. Gunderson

MPM, основанная на модели prefork. Позволяет запуск каждого виртуального хоста под отдельными uid и gid.

Хостинговые серверы, серверы, критичные к изоляции пользователей и учёту ресурсов.

Стабильный.

Sean Gabriel Heacock

Модель, созданная на базе MPM perchild. Позволяет запуск каждого виртуального хоста под отдельными uid и gid. Не использует потоки.

Обеспечение повышенной безопасности, работа с библиотеками, не поддерживающими threads.

Для смены MPM требуется перекомпиляция Apache. Для этого удобнее взять source-based дистрибутив.

DNS lookup

Директива HostnameLookups включает обратные DNS запросы, при этом в логи пишутся dns-хосты клиентов вместо ip-адресов. Это существенно замедляет обработку запроса, т.к. запрос не обработается, пока не будет получен ответ от DNS-сервера. Следите, чтобы эта директива всегда была выключена (HostnameLookups Off). Если необходимы dns-адреса, можно «прогнать» лог в утилите logresolve.

Кроме того, следите, чтобы в директивах Allow from и Deny From использовались ip-адреса а не доменные имена. В противном случае Apache будет делать два dns запроса (обратный и прямой), чтобы узнать ip и убедиться что клиент валиден.

AllowOverride

Если директива AllowOverride не установлена в None, Apache попытается открыть.htaccess файлы в каждой директории, которую он посещает и во всех директориях выше нее. Например:

DocumentRoot /var/www/html

AllowOverride all

Если будет запрошен /index.html, Apache попытается открыть (и интерпретировать) файлы /.htaccess, /var/.htaccess, /var/www/.htaccess, и /var/www/html/.htaccess. Очевидно, что это увеличивает время обработки запроса. Так что, если вам нужен.htaccess только для одной директории, разрешите его только для нее:

DocumentRoot /var/www/html

AllowOverride None

AllowOverride all

FollowSymLinks и SymLinksIfOwnerMatch

Если для каталога включена опция FollowSymLinks, Apache будет следовать по символическим ссылкам в этом каталоге. Если включена опция SymLinksIfOwnerMatch, Apache будет следовать по символическим ссылкам, только если владелец файла или каталога на которую указывает эта ссылка, совпадает с владельцем указанного каталога. Поэтому при включенной опции SymLinksIfOwnerMatch Apache делает больше системных запросов. Кроме того, дополнительные системные запросы требуются, когда FollowSymlinks не определен. Следовательно, наиболее оптимальным для производительности будет включение опции FollowSymlinks, конечно, если политика безопасности позволяет это сделать.

Content Negotiatio

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

Нетрудно понять, чем это грозит для производительности сервера, поэтому избегайте применения content negotiaion.

MaxClients

Директива MaxClients устанавливает максимальное количество параллельных запросов, которые будет поддерживать сервер. Значение MaxClient не должно быть слишком маленьким, иначе многим клиентам будет отказано. Нельзя устанавливать слишком большое количество – это грозит нехваткой ресурсов и «падением» сервера. Ориентировочно, MaxClients = количество памяти выделенное под веб-сервер / максимальный размер порожденного процесса или потока. Для статических файлов Apache использует около 2-3 Мб на процесс, для динамики (php, cgi) – зависит от скрипта, но обычно около 16-32 Мб. Если сервер уже обслуживает MaxClients запросов, новые запросы попадают в очередь, размер которой устанавливается директивой ListenBacklog.

MinSpareServers, MaxSpareServers, и StartServers

Создание потока, и особенно процесса – ресурсоемкая операция, поэтому Apache создает их про запас. Директивы MaxSpareServers и MinSpareServers устанавливают минимальное и максимальное число процессов/потоков, которые должны быть готовы принять запрос. Если значение MinSpareServers слишком мало и пришло много запросов, Apache начнет создавать много новых процессов/потоков, что создаст лишнюю нагрузку в пиковые моменты. Если MaxSpareServers слишком велико, Apache будет излишне нагружать систему, даже если число запросов минимально.

Опытным путем нужно попдобрать такие значения, чтобы Apache не создавал более 4 процессов/потоков в секунду. Если он создаст более 4, в ErrorLog будет сделана соответствующая запись – сигнал того что MinSpareServers нужно увеличить.

MaxRequestsPerChild

Директива MaxRequestsPerChild определяет максимальное число запросов, которое может обработать один дочерний процесс/поток прежде чем он завершиться. По умолчанию значение установлено в 0, что означает, что не будет завершен никогда. Рекомендуется установить MaxRequestsPerChild равное числу запросов за час. Это не создаст лишней нагрузки на сервер и, в то же время, поможет избавиться от проблем с утечкой памяти в дочерних процессах (например, если вы используете нестабильную версию php).

KeepAlive и KeepAliveTimeout

KeepAlive позволяет делать несколько запросов в одном TCP-подключении. При использовании схемы frontend+backend, эти директивы не актуальны.

HTTP-сжатие

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

Отмечу, что не следует устанавливать степень сжатия gzip более 5, так как существенно возрастает нагрузка на процессор, а степень сжатия растет незначительно. Также, не следует сжимать файлы, формат которых уже подразумевает сжатие – это практически все мультимедийные файлы и архивы.

Кеширование на стороне клиента

Не забывайте устанавливать Expires заголовки для статических файлов (модуль mod_expires). Если файл не изменяется, то всегда следует дать указание клиенту закэшировать его. При этом у клиента будут быстрее загружаться страницы, а сервер избавиться от лишних запросов.

Отключение логов

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

Nginx

Простой и легкий веб-сервер, специально предназначенный для обработки статических запросов. Причина его производительности в том, что рабочие процессы обслуживают одновременно множество соединений, мультиплексируя их вызовами операционной системы select, epoll (Linux) и kqueue (FreeBSD). Сервер имеет эффективную систему управления памятью с применением пулов. Ответ клиенту формируется в буферах, которые хранят данные либо в памяти, либо указывают на отрезок файла. Буферы объединяются в цепочки, определяющие последовательность, в которой данные будут переданы клиенту. Если операционная система поддерживает эффективные операции ввода-вывода, такие как writev и sendfile , то Nginx, по возможности, применяет их.

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

Lighttpd

«Веб-сервер, разрабатываемый с расчётом на быстроту и защищённость, а также соответствие стандартам.» – википедия

Является альтернативой Nginx и применяется для тех же целей.

Акселераторы PHP

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

Существующие решения

The Alternative PHP Cache -был задуман, как бесплатный, открытый и стабильный фреймворк для кэширования и оптимизации исходного кода PHP. Поддерживает PHP4 и PHP5, включая 5.3.

eAccelerator - это свободный открытый проект, выполняющий также роли акселератора, оптимизатора и распаковщика. Имеет встроенные функции динамического кэширования контента. Имеется возможность оптимизации PHP-скриптов. Поддерживает PHP4 и PHP5, включая 5.3.

PhpExpress бесплатный ускоритель обработки PHP скриптов на веб-сервере. Также обеспечивает поддержку загрузки файлов закодированных через Nu-Coder. Поддерживает PHP4 и PHP5, включая 5.3

XCache поддерживает PHP4 и PHP5, включая 5.3. Начиная с версии 2.0.0 (release candidate от 2012-04-05) включена поддержка PHP 5.4.

Windows Cache Extension for PHP - PHP-акселератор для Microsoft IIS (BSD License). Поддерживает только PHP (5.2 и 5.3).

Логика кэширования

«Кэшировать, кэшировать и еще раз кэшировать!» - вот девиз высоконагруженной системы.

Давайте представим себе идеальный высоконагруженный сайт. Сервер получает http запрос от клиент. Frontend сопоставляет запрос с физическим файлом на сервере и, если тот существует, отдает его. Загрузку скриптов и картинок опустим, так как это в большинстве своем статика и отдается по такому же принципу. Далее, если физически файл не существует, frontend обращается с этим запросом к backend-у, который занимается обработкой логики (скриптов php и т.д.). Backend должен решить кэшировать ли данный запрос и создать файл в определенном месте, который и будет отдаваться frontend-ом в дальнейшем. Таким образом, мы навсегда закэшировали данный запрос и сервер будет обрабатывать его максимально быстро с минимально возможной нагрузкой на сервер.

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

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

Таким образом, запрос клиента (кроме запроса статики) переадресуется на backend и его обработка сводится к следующим действиям:

  1. Получение информации о блоках, которые будут на странице.
  2. Проверка информации о кэшах для каждого блока. Кэш может не существовать или нуждаться в обновлении. В этом случае генерируем файл кэша. Если блок не должен кэшироваться выполняем соответствующую логику. Информацию о кэшах можно хранить в nosql базе данных или в файловой структуре. Тут требование одно: получение этой информации должно занимать минимум ресурсов.
  3. Формируем html страницы. Закэшированные блоки встраиваем при помощи ssi инструкции (вставляется ссылка на файл кэша), что позволит существенно экономить память.
  4. Страница попадает на frontend, который производит замену всех ssi инструкций на содержимое файлов и отдает страницу клиенту.

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

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

Картинки, пикчи, тумбочки

Оказывается изображение тоже можно кэшировать. Зачем? Спросите Вы. В принципе, после загрузки на сервер у нас уже есть файл, который frontend быстренько выплюнет при необходимости. Но часто нам требуется получить на основе уже имеющейся картинки другое изображение (например, других размеров). Допустим, нам нужна миниатюра изображения – thumbnail (тумбочка жарг.). В этом случае, нам достаточно сформировать путь к бедующему файлу уменьшенной картинки и отдать страницу клиенту.

  1. Клиент, получив исходный код страницы, начинает подгружать статику и обращается с запросом на несуществующую пока картинку к frontend-у.
  2. Frontend переадресует запросы к несуществующим изображениям на backend.
  3. Backend анализирует запрос, формирует файл изображения и отдает бинарные данные с соответствующим http-заголовком.
  4. Все последующие запросы будут отдаваться frontend-ом.

Вообще, если вы можете не поднимать Apache , не делайте этого. Задумайтесь, может ли нужные вам задачи выполнять lighttpd или thttpd . Эти веб-серверы могут оказаться весьма кстати в ситуациях, где системных ресурсов на всех не хватает, а работать должно. Ещё раз повторюсь: речь идёт о тех ситуациях, когда функциональности этих продуктов будет достаточно для выполнения поставленных задач (кстати, lighttpd умеет работать с PHP ). В тех ситуациях, где без Apache ну просто никак не обойтись, всё равно обычно можно освободить немало системных ресурсов, перенаправив запросы к статическому контенту (JavaScript, графика) от Apache к легковесному HTTP-серверу. Наибольшей проблемой Apache является его большой аппетит к оперативной памяти. В этой статье я рассмотрю методы, помогающие ускорить работу и снизить объёмы занимаемой им памяти:

  • обработке меньшего числа параллельных запросов;
  • циркуляция процессов;
  • использование не слишком «долгих» KeepAlive;
  • уменьшение таймаута;
  • уменьшение интенсивности логирования;
  • отключение разрешения имён хостов;
  • отключение использования .htaccess .

    • Загрузка меньшего количества модулей

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

    Обработка меньшего числа параллельных запросов

    Чем большему количеству процессов Apache разрешено запускаться одновременно, тем больше одновременных запросов он сможет обработать. Увеличивая это число, вы тем самым увеличиваете и объём памяти, отдаваемой под Apache . Воспользовавшись top, можно увидеть, что каждый процесс Apache занимает совсем немножко памяти, поскольку используются разделяемые библиотеки. В Debian 5 с Apache 2 по умолчанию используется такая конфигурация:

    StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 20 MaxRequestsPerChild 0

    Директива StartServers определяет количество процессов сервера, запускаемых изначально, сразу после его старта. Директивы MinSpareServers и MaxSpareServers определяют минимальное и максимальное количество дочерних «запасных» процессов Apache . Такие процессы находятся в состоянии ожидания входящих запросов и не выгружаются, что даёт возможность ускорить реакцию сервера на новые запросы. Директива MaxClients определяет максимальное количество параллельных запросов, одновременно обрабатываемых сервером. Когда количество одновременных соединений превысит это количество, новые соединения будут поставлены в очередь на обработку. Фактически, директива MaxClients и определяет максимально-допустимое число дочерних процессов Apache ,запущенных одновременно. Директива MaxRequestsPerChild определяет количество запросов, которое должен обработать дочерний процесс Apache , прежде чем завершить своё существование. Если значение этой директивы установлено равным нулю, то процесс не будет «истекать».

    Для своего домашнего сервера, с соответствующими нуждами, я исправил конфигурацию на следующую:

    StartServers 1 MinSpareServers 1 MaxSpareServers 1 MaxClients 5 MaxRequestsPerChild 300

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

    Циркуляция процессов

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

    Использование не слишком «долгих» KeepAlive

    KeepAlive — это метод поддержки постоянного соединения между клиентом и сервером. Изначально протокол HTTP разрабатывался как не ориентированный на постоянные соединения. То есть, когда веб-страница отправляется клиенту, все её части (картинки, фреймы, JavaScript) передаются с использованием различных, отдельно устанавливаемых соединений. С появлением KeepAlive , у браузеров появилась возможность запрашивать постоянное соединение и, установив его, загружать данные, используя одно установленное соединение. Такой способ даёт неслабый прирост производительности. Однако Apache по умолчанию использует слишком большой таймаут перед закрытием соединения, равный 15-ти секундам. Это значит, что после того, как был отдан весь контент клиенту, запросившему KeepAlive , дочерний процесс ещё 15 секунд будет находиться в ожидании входящих запросов. Многовато, однако. Лучше уменьшить этот таймаут до 2-3 секунд.

    KeepAliveTimeout 2

    Уменьшение таймаута

    Как вариант, можно уменьшить значение директивы TimeOut , которая определяет время ожидания завершения отдельных запросов. По умолчанию её значение равно 300 , быть может, в вашем случае будет иметь смысл это значение уменьшить/увеличить. Я лично пока оставил как есть.

    Уменьшение интенсивности логирования

    На пути к увеличению производительности сервера можно попробовать снизить интенсивность ведения протоколов. Модули, такие как mod_rewrite , могут писать в лог отладочную информацию, и если она вам не нужна — отключайте её вывод.

    Отключение разрешения имён хостов

    На мой взгляд, нет никакой необходимости в том, чтобы выполнять обратное преобразование IP-адресов в имена хостов. Если они уж так сильно вам необходимы при анализе логов, то можно определять их на стадии анализа, а не в процессе работы сервера. За разрешение имён хостов отвечает директива HostnameLookups , которая, вообще-то, по умолчанию и установлена в Off , однако проверьте это, если действительно считаете необходимым отключить преобразование.

    HostnameLookups Off

    Отключение использования.htaccess

    Обработка файлов .htaccess выполняется Apache каждый раз при запросе данных. Мало того, что Apache должен загрузить этот файл, так ещё немало времени и ресурсов уходит на его обработку. Взгляните на ваш веб-сервер и пересмотрите необходимость в использовании файлов .htaccess . Если вам нужны различные настройки для разных каталогов, может быть реально будет их вынести в основной файл конфигурации сервера? А отключить обработку .htaccess можно директивой в конфигурации сервера.

    Процессы php-cgi пожирают память размножаясь в геометрической прогрессии и не хотят умирать по истечении лимита FcgidMaxRequestsPerProcess , после чего php-cgi активно начинает сваливать всё в swap и система начинает выдавать " 502 Bad Gateway ".

    Чтобы ограничить число форкнутых php-cgi процессов , не достаточно установить FcgidMaxRequestsPerProcess , после обработки которых процессы должны загибаться, но не всегда они делают это добровольно.

    Ситуация до боли знакомая когда php-cgi процессы (чилды ) плодятся выедая память, а умирать их ну никак не заставишь - жить хотят с.ки!:) Напоминает проблему с перенаселением земли "пиплами" - неправда ли?;)

    Урегулировать извечные дисбаланс между предками и чилдами можно путем ограничения числа php-cgi чилдов, времени их жизни (геноцид ) и контроля активности их размножения (контрацепция ).

    Ограничение числа php-cgi процессов для mod_fcgid

    Приведённые ниже директивы играют наверное самую главную роль в ограничении числа php-cgi процессов и в большинстве случаев приведённые здесь значения по умолчанию являются ущербными для серверов с оперативной памятью ниже 5-10 ГБ:

    • FcgidMaxProcesses 1000 - максимальное количество процессов, которые могут быть активны одновременно;
    • FcgidMaxProcessesPerClass 100 - максимальное количество процессов в одном классе (сегменте ), т.е. максимальное количество процессов которое разрешено порождать через один и тот же враппер (wrapper - обвертку );
    • FcgidMinProcessesPerClass 3 - минимальное количество процессов в одном классе (сегменте ), т.е. минимальное количество процессов запускаемые через один и тот же враппер (wrapper - обвертку ), которое будет доступно после завершения всех запросов;
    • FcgidMaxRequestsPerProcess 0 - FastCGI должен "сыграть в ящик" после выполнения этого количества запросов.

    Какое число php-cgi процессов будет самым оптимальным? Для определения оптимального числа php-cgi процессов нужно {pub}Зарегистрироваться на нашем сайте!:) {/pub}{reg}принимать во внимание общий объем оперативной памяти и размер памяти выделяемый для РНР в memory_limit (php.ini ), который может быть поглощен каждым из php-cgi процессов при выполнении РНР скрипта. Так например если у нас есть 512 МБ, 150-200 из которых отведено под саму ОС, ещё 50-100 под сервер БД, почтовый МТА и т.д., а memory_limit=64 , то в таком случае на наши 200-250 МБ оперативки мы без особого ущерба можем запустить одновременно 3-4 php-cgi процесса.{/reg}

    Настройки тайм-аута жизни php-cgi процессов

    При активном размножении php-cgi чилдов, поедая РАМу они могут жить чуть ли не вечно, а это чревато катаклизмами. Ниже есть перечень ГМО-директив, которые помогут урезать срок жизни для php-cgi процессов и своевременно освободить занимаемые ими ресурсы:

    • FcgidIOTimeout 40 - время (в сек. ) в течении которого модуль mod_fcgid будет пытаться выполнить скрипт.
    • FcgidProcessLifeTime 3600 - если процесс существует дольше этого времени (в секундах ), то он должен будет помечен для уничтожения во время следующего сканирования процессов, интервал которого задается в директиве FcgidIdleScanInterval ;
    • FcgidIdleTimeout 300 - если число процессов превышает FcgidMinProcessesPerClass , то процесс, который не обрабатывает запросы за это время (в сек.), во время следующего сканирования процессов, интервал которого задается в директиве FcgidIdleScanInterval , будет отмечен для убивания;
    • FcgidIdleScanInterval 120 - интервал, через который mod_fcgid модуль будет искать процессы превысившие лимиты FcgidIdleTimeout или FcgidProcessLifeTime .
    • FcgidBusyTimeout 300 - если процесс занят обработкой запросов свыше этого времени (в сек. ), то во время следующего сканирования, интервал которого задается в FcgidBusyScanInterval , такой процесс будет отмечен для убивания;
    • FcgidBusyScanInterval 120 - интервал, через который выполняется сканирование и поиск занятых процессов превысивших лимит FcgidBusyTimeout ;
    • FcgidErrorScanInterval 3 - интервал (в сек. ), через который модуль mod_fcgid будет убивать процессы ожидающие завершения, в т.ч. и те которые превысили FcgidIdleTimeout or FcgidProcessLifeTime . Убивание происходит путем отправки процессу сигнала SIGTERM , а если процесс продолжает быть активным, то он убивается сигналом SIGKILL .

    Нужно принимать во внимание, что процесс превысивший FcgidIdleTimeout или FcgidBusyTimeout может прожить + ещё время FcgidIdleScanInterval или FcgidBusyScanInterval , через которое он будет отмечен для уничтожения.

    ScanInterval-ы лучше устанавливать с разницей в несколько сек., например если FcgidIdleScanInterval 120 , то FcgidBusyScanInterval 117 - т.е. чтобы сканирование процессов не происходило в одно и тоже время.

    Активность порождения php-cgi процессов

    Если ничего из вышеприведённого не помогло, что удивительно, то можно ещё попробовать пошаманить с активностью порождения php-cgi процессов...

    Помимо лимитов на количество запросов, процессов php-cgi и времени их жизни, есть ещё такая штука как активность порождения дочерних процессов, которую можно урегулировать такими директивами как FcgidSpawnScore , FcgidTerminationScore , FcgidTimeScore и FcgidSpawnScoreUpLimit , перевод которых с буржуйского думаю я дал правильный (указаны значения по умолчанию ):FcgidSpawnScoreUpLimit , никакие дочерние процессы приложения не будут порождены, а все запросы на порождение должны будут ожидать, пока существующий процесс не освободится или пока оценка (Score ) не упадает ниже этого предела.

    Если мой перевод описания и понимание указанных выше параметров верное, то для понижения активности порождения php-cgi процессов следует понизить значение директивы FcgidSpawnScoreUpLimit или увеличить значения FcgidSpawnScore и FcgidTerminationScore .

    Итоги

    Надеюсь я перечислил и детально разжевал большую часть директив модуля mod_fcgid, которые помогут ограничить число php-cgi и время их жизни , а также понизить потребление ресурсов. Ниже приводиться полная конфигурация mod_fcgid для успешно рабочего сервера с процессором 2500 Мгц и оперативной памятью 512 Мб:

    Олег Головский

    Применимо к:System Center 2012 R2 Operations Manager, System Center 2012 - Operations Manager, System Center 2012 SP1 - Operations Manager

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

    Сценарии

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

    Критического процесса

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

    Нежелательного процесса

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

    Долго выполняющегося процесса.

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

    Мониторинг, выполняемый шаблоном мониторинга процессов

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

    Описание

    При включении

    Мониторы

    Количество желаемую процессов

    Включено при выборе процессы нужно на процесс для отслеживания страницы и число процессов на запущенные процессы страницы.

    Время выполнения требуемого процесса

    Включено при выборе процессы нужно на процесс для отслеживания страницы и длительность на запущенные процессы страницы.

    Выполнение нежелательного процесса

    Если включен сценарий наблюдения для ненужные процессы.

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

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

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

    Правила сбора данных

    Коллекция процессора процесса

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

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

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

    Просмотр данных мониторинга

    Все данные, собранные мониторинг шаблон доступен в состояние процесса представление находится в Отслеживание процессов и служб Windows папки. В этом представлении объекта отображается для каждого агента в выбранной группе. Даже если агент не наблюдение за процессом, его в списке и монитор отражает состояние для процесса, который не выполняется.

    Можно просмотреть состояние мониторов отдельных процессов, открыв Operations Manager Анализатор работоспособности для объекта процесса. Можно просмотреть данные о производительности, откройте представление производительности для объекта процесса.

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

    Параметры мастера

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

    Общие свойства

    Общие параметры странице мастера.

    Процесс для отслеживания

    Следующие параметры доступны на процесс для отслеживания странице мастера.

    Параметр

    Описание

    Сценарии наблюдения

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

    Имя процесса

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

    Целевая группа

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

    Выполняющиеся процессы

    Следующие параметры доступны на запущенные процессы странице мастера.

    Параметр

    Описание

    Создать оповещение число процессов - ниже минимального значения или превышает максимальное значение дольше, чем в течение указанного периода

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

    Чтобы убедиться, что по крайней мере один экземпляр процесса выполняется, минимум и максимум равным 1.

    Минимальное число процессов

    Минимальное число процессов, которые должна быть запущена.

    Максимальное число процессов

    Максимальное число процессов, которые должны выполняться.

    Продолжительность

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

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

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

    Данные производительности

    Следующие параметры доступны на данных о производительности странице мастера.

    Параметр

    Описание

    Создать предупреждение, если загрузка ЦП превышает заданное пороговое значение

    Указывает, должно вестись наблюдение ЦП для процесса. Монитор будет создаваться задают состояние ошибки в объекте и создает предупреждение, если превышено заданное пороговое значение. Правило создается для сбора ЦП для анализа и отчетности.

    ЦП (в процентах)

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

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

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

    Память (МБ)

    Если мониторинг использования памяти, этот параметр задает пороговое значение. Если на диске в мегабайтах (МБ) Общая загрузка ЦП превышает пороговое значение, набор объектов в состоянии ошибки и создается предупреждение.

    Число отсчетов

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

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

    Интервал выборки

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

    Меньшее значение для этого параметра позволяет сократить время для обнаружения проблемы, но увеличивает нагрузку на агенте и объем данных, собранных для отчетов. Обычное значение составляет от 5 до 15 минут.

    Дополнительные функции мониторинга

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