Apache 2.x під наглядом або як дізнатися ще більше

Вступ

Що нового в mod_performance 0.2?
Які принципи роботи модуля?
Як збирається статистика про використання CPU?
Як збирається статистика про використання пам'яті?
Як збирається статистика про використання операції введення-висновку?
Рекомендації щодо запуску
Куди зберігати статистику запитів?
[%DATE%] from %HOST% (%URI%) script %SCRIPT%: cpu %CPU% (%CPUS%), memory %MEM% (%MEMMB%), execution time %EXCTIME%, IO: R — %BYTES_R% W — %BYTES_W%
Які звіти доступні в новій версії модуля за замовчуванням?
Як зібрати додаток?
Як додаток впливає на швидкість обробки запитів?
Посилання

Продовжу цикл статей на тему "Apache 2.x під наглядом. Моніторинг завантаження системи веб-сервером ". Знову ж таки під розглядом залишається відомий раніше [2] модуль Apache - mod_performance. На час написання цієї статті на сайті додатка [1] була викладена для доступу нова версія додатка - 0.2. Подальша оповідь у статті буде за принципом «Питання-Відповідь».

Що нового в mod_performance 0.2?

Хочу загострити ще раз увагу, для чого модуль призначається:

додаток призначений для збирання і накопичення статистики з використання ресурсів (CPU і memory, час виконання скрипту, а також I/O процесу) веб-сервером Apache 2.2;
модуль дозволяє провести аналіз зібраних даних.

Якщо коротко описати нововведення, то вийде приблизно такий список:

Збереження зібраної додатком інформації до ПД MySQL.
Збереження зібраної додатком інформації в окремий текстовий лог у визначеному користувачем форматі.
Розширено кількість даних, що збираються, тобто тепер одиниці статистики не обмежуються відсотками, але ще зберігаються в секундах і мегабайтах
Збереження зібраної додатком інформації до ПД PostgreSQL.
Виправлено ряд помилок, що впливають на стабільність роботи в 0.1-х версії.
Додано сумісність роботи модуля з конфігураціями Apache-itk, а також Apache + mod _ ruid2.
Додано збирання статистики операцій введення виводу відстежуваного процесу.
Зменшено вплив модуля на працездатність сервера, оскільки додаток більше не видає помилку 503 при неможливості з'єднається з демоном.

Які принципи роботи модуля?

Повторюся ще раз для тих, хто не читав попередню статтю [2] і додам нових відомостей.

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

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

Як аналізатор використання ресурсів, використовується не scoreboard, як у mod_status і розширеннях perl, а glibtop.

Додаток надає вам змогу стежити як абсолютно всі запити, так і конкретні, відфільтровані за правилом за допомогою формальних виразів. Точніше буде сказано, що модуль ЗАВЖДИ обробляє лише ті запити, які відповідають фільтру, що містить формальний вираз.

А тепер опишу як саме збирається статистика запиту.

При запуску веб-сервера Apache - запускається фонова служба модуля mod_performance. Демон, що запустився, відкриває unix-сокет і очікує з'єднань. Під час обробки запиту сервером, відбувається перевірка запиту на умову: чи необхідно для запиту зберігати статистику чи ні. Якщо перевірка пройшла успішно, процес сервера, який прийняв з'єднання надсилає фоновій службі інформацію і PID (TID) процесу/потоку, який буде обробляти запит. Фонова служба запускає два потоки:1) перший потік, який очікує завершальної передачі даних від процесу обробного запит; 2) потік, який періодично опитує використання пам'яті процесом, що обробляє запит і обчислює максимальне значення. Після закінчення роботи процесу, який обробляє запит, фонова служба записує дані в базу даних статистики.

Як збирається статистика про використання CPU?

Показник CPU usage обчислюється за наступною схемою. Модуль при надходженні запиту знімає показання jiffies процесу (системи в цілому і поточного процесу) і в кінці запиту ще раз проводиться замір і ці дані надсилаються демону. На їх підставі приймається рішення про використання процесора. Тобто. якщо спостерігаючи за допомогою top ви побачили завантаження: 0%, 10%, 100%, 20%, не очікуйте, що модуль збереже 100%, оскільки збережеться саме та кількість часової, яку за час існування запиту було виділено саме на цей процес. «На очок» для вищенаведеного прикладу це число буде дорівнювати - 32%.

Як збирається статистика про використання пам'яті?

А ось показник пам'яті збирається за іншим принципом. Під час обробки запиту фонова служба кожні 10 мілісекунд виконує заміну використання пам'яті процесом обробним запит і в кінці зберігає максимальне значення.

Як збирається статистика про використання операції введення-висновку?

Цей показник відстежується подібно до CPU - проводиться замір прочитаних і записаних даних процесу на початку запиту і в кінці запиту. Різниця цих величин переводиться в кілобайти і зберігається в базі. Тобто. фактично цей показник відстежує кількість записаних/прочитаних байт протягом існування запиту. Відразу скажу, що в якості аналізованого джерела використовується показник: /proc/[pid]/io — read_bytes, write_bytes, cancelled_write_bytes.

Куди зберігати статистику запитів?

Ось воно важливе питання - куди зберегти збиральну статистику. Для спрощення цієї головоломки в новій версії додатка вбудована підтримка таких БД як: SQLite, MySQL, PostgreSQL, а так само екзотика - збереження у файл логів. Тепер не потрібно підлаштовуватися під модуль - він підлаштується під вас. Для успішної роботи модуля (не в режимі «Збереження в лог») потрібна хоча б одна з наступних бібліотек:

При збиранні пакета наявність mysql-devel, sqlite-devel, postgresql-devel не потрібна. Ці бібліотеки завантажуються динамічно під час роботи додатка. Точніше завантажується потрібна для вибраного режиму бібліотека.

Приклад 1. Робота з SQLite. Найпростіший варіант, база даних створюється автоматично, таблиця створюється автоматично, немає необхідності в користувачів та інше. Тільки одне дуже важливе зауваження для тих хто вже використовував додаток версії 0.1: у старій базі і новій розрізняються структури таблиць, тому для успішної роботи стару базу краще видалити. Оскільки сам додаток не створює існуючу таблицю.

Для роботи з SQLite необхідно:

PerformanceDB /statistics/apache/perfdb
PerformanceLogType SQLite

Приклад 2. Робота з MySQL. Більш складний варіант.

Створіть базу даних, наприклад, perf і користувача perf з правами на цю базу:

mysql> create database perf;
mysql> CREATE USER 'perf'@'localhost' IDENTIFIED BY 'perf';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'perf'@'localhost' WITH GRANT OPTION;

таблицю додаток створить сам. І тепер у налаштуваннях додатка:

PerformanceLogType MySQL
PerformanceDbUserName perf
PerformanceDBPassword perf
PerformanceDBName perf

І знову ж таки дуже важливе зауваження для тих хто вже використовував модуль версії 0.2 більш ранніх версій ніж 0.2-8: у старій базі і новій розрізняються структури таблиць, тому для успішної роботи стару базу краще видалити. Оскільки сам додаток не створює існуючу таблицю.

Приклад 3. Робота з PostgreSQL. Більш складний варіант.

Так само необхідно створити базу і користувача для доступу:

postgres=# CREATE USER perf WITH PASSWORD 'perf';
postgres=# CREATE DATABASE perf;
postgres=# GRANT ALL PRIVILEGES ON DATABASE perf to perf;

у файлі/ var/lib/pgsql/data/pg_hba.conf

local all all trust
host all all 0.0.0.0/0 trust
host all all : : : 1/128 trust

і нарешті налаштування додатка:

PerformanceLogType Postgres
PerformanceDbUserName perf
PerformanceDBPassword perf
PerformanceDBName perf

Приклад 4. Робота з текстовим логом.

У цьому режимі не потрібні додаткові бібліотеки. Достатньо приписати файл, куди буде консолідуватися статистика.

PerformanceLogType Log
PerformanceLog /statistics/apache/perf.log

Типово, дані до цього файла потрапляють у такий формат:

[%DATE%] from %HOST% (%URI%) script %SCRIPT%: cpu %CPU% (%CPUS%), memory %MEM% (%MEMMB%), execution time %EXCTIME%, IO: R — %BYTES_R% W — %BYTES_W%

що розгортається в:

[2011-06-05 19:28:28] from example.com (/index.php) script /var/www/example.com/index.php: cpu 0.093897 (0.010000), memory 0.558202 (5.597656), execution time 10.298639, IO: R — 104.000000 W — 248.000000

[2011-06-05 19:28:39] from example.com (/index2.php) script /var/www/example.com/index2.php: cpu 0.000000 (0.000000), memory 0.558202 (5.597656), execution time 10.159158, IO: R — 0.000000 W — 0.000000

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

% DATE% - перетворюється на дату початку запиту;
% CPU% - використання CPU у відсотках;
% MEM% - використання пам'яті у відсотках;
% URI% - URI запиту
% HOST% - назва віртуального хоста, до якого адресовано запит;
% SCRIPT% - назва скрипту;
% EXCTIME% - тривалість виконання скрипту в секундах;
% CPUS% - скільки секунд система витратила саме на цей процес у секундах;
% MEMMB% - використання пам'яті в мегабайтах;
% BYTES _ W% - кілобайт записано;
% BYTES _ R% - кілобайт прочитано;
%% - вивести знак відсотка.

Наприклад:

Hello from %HOST% I use %CPU% %% cpu today %DATE%

розгорнеться в

Hello from example.com I use 0.23 % cpu today 2011-06-05 19:28:28

Такий лог може бути глобальним, а також і для кожного віртуального хосту свій. Також як і кожен хост може мати свій унікальний формат виведення в лог.

Ще однією важливою особливістю є те, що в цьому режимі не доступний екран аналізу накопичених даних. Тобто. не відпрацьовують хендлери модуля. У цьому випадку утиліти аналізуючі логи потрібно писати окремо.

Які звіти доступні в новій версії модуля за замовчуванням?

Як і раніше у версії 0.1 в новому модулі доступні звіти:

Show output without analytics - вивести зібрану інформацію без аналізу, відфільтровану за хостом, скриптом і URI (графічний і текстовий режим);
Maximal% CPU - вивести тільки записи з максимальним значенням% CPU (з урахуванням фільтрації);
Maximal memory% - вивести тільки записи з максимальним значенням% memory (з урахуванням фільтрації);
Maximal execution request time - вивести самийдовго виконуваний скрипт;
Host requests statistics - вивести статистику звернень до вузлів із сортуванням зі збування (у% від загального числа з урахуванням фільтрів);
Number of requests per domain - вивести статистику звернень до вузлів із сортуванням зі збування (не у відсотках а кількість);
Average usage per host - показати середнє завантаження сервера кожним вузлом (сума% CPU, сума% MEMORY, сума виконання скриптів, середній% CPU за період, середній% використання пам'яті, середній час виконання скриптів);
Show current daemon threads - показати список відстежуваних демоном запитів (відображається тільки для хендлера performance-status і при включеному параметрі PerformanceExtended).

Виводимі поля у звітах:

ІД - ідентифікатор запису;
DATE ADD - коли пройшов запит;
HOSTNAME - назва віртуального хосту;
URI - uri запиту;
SCRIPT - скрипт;
CPU (%) - використання CPU у%;
MEM (%) - використання пам'яті в%;
TIME EXEC (sec) - час виконання запиту;
CPU TM (sec) - процесорний час у секундах;
MEM USE (Mb) - використання пам'яті в мегабайтах;
IO READ (Kb) - прочитано Кбайт процесом;
IO WRITE (Kb) - записано Кбайт процесом.

Звіти доступні в режимі: SQLite, MySQL, Postgres.

Як зібрати додаток?

Повторюся, оскільки порівняно з попередньою версією з'явилися зміни (установка під Debian [4]).

Всі дії необхідно проводити під користувачем root:

1) встановимо необхідні пакети для складання:

yum install httpd-devel apr-devel libgtop2-devel gd-devel

2) створимо тимчасову паку для вихідних кодів:

mkdir ~/my_tmp
cd ~/my_tmp

3) створимо тимчасову паку для вихідних кодів:

wget http://lexvit.dn.ua/utils/getfile.php?file_name=mod_performance-0.2.tar.gz -O mod_performance-0.2.tar.gz
tar zxvf mod_performance-0.2.tar.gz
cd mod_performance-0.2/

4) збираємо модуль:

make

5) на warning не звертаємо уваги. Головне, щоб не було error. Якщо все зібралося нормально, то:

make install

або

cp .libs/mod_performance.so < шлях куди копіювати >

Інструкція щодо параметрів модуля доступна за адресою в посиланнях [3].

Як додаток впливає на швидкість обробки запитів?

З теоретичної точки зору модуль по суті не повинен впливати на швидкість обробки запиту, оскільки в процесі самого запиту читається тільки CPU інформація, все інше зчитує фонову службу. І основне навантаження лягає саме на демона. Навантаження може зрости на сервер, оскільки демону необхідно звертатися до бази для запису інформації. А так само не слід забувати про пам'ять, яка потрібна для роботи потоків.

Для дослідження практичної частини цього питання було проведено невелике дослідження за допомогою утиліти ab (ApacheBench).

1-й тест. Досліджувався php скрипт створює навантаження на файлову підсистему:

Без додатка mod_performance:

Time taken for tests: 205.952423 seconds
Complete requests: 100
Failed requests: 0
Requests per second: 0.49 [#/sec] (mean)
Time per request: 10297.621 [ms] (mean)
Time per request: 2059.524 [ms] (mean, across all concurrent requests)

З додатком mod_performance:

Time taken for tests: 206.386260 seconds
Complete requests: 100
Failed requests: 0
Requests per second: 0.48 [#/sec] (mean)
Time per request: 10319.313 [ms] (mean)
Time per request: 2063.863 [ms] (mean, across all concurrent requests)

2-й тест. Дослідження php скрипту, що створює навантаження на CPU.

Без додатка mod_performance:

Time taken for tests: 60.333852 seconds
Complete requests: 100
Failed requests: 0
Requests per second: 1.66 [#/sec] (mean)
Time per request: 3016.692 [ms] (mean)
Time per request: 603.339 [ms] (mean, across all concurrent requests)

З додатком mod_performance:

Time taken for tests: 60.714260 seconds
Complete requests: 100
Failed requests: 0
Requests per second: 1.65 [#/sec] (mean)
Time per request: 3035.713 [ms] (mean)
Time per request: 607.143 [ms] (mean, across all concurrent requests)

3-й тест. Дослідження php скрипту, що швидко виконується і не створює навантаження.

Без додатка mod_performance:

Time taken for tests: 0.075594 seconds
Complete requests: 100
Failed requests: 0
Requests per second: 1322.86 [#/sec] (mean)
Time per request: 3.780 [ms] (mean)
Time per request: 0.756 [ms] (mean, across all concurrent requests)

З додатком mod_performance:

Time taken for tests: 0.109116 seconds
Complete requests: 100
Failed requests: 0
Requests per second: 916.46 [#/sec] (mean)
Time per request: 5.456 [ms] (mean)
Time per request: 1.091 [ms] (mean, across all concurrent requests)

Досліджувана машина: віртуальна, оперативної пам'яті 1Gb, процесор AMD Phenom (tm) 8650 Triple-Core Processor, ОС CentOS 5.5.

Чим вагоміший запит, тим меншим є вплив модуля. Перші тести показали, що вплив модуля несуттєвий, останній же тест показав збільшення часу обробки запиту в півтора рази. Але судячи з часу виконання запиту це допустима жертва.