mod_performance 0.4 (статья перенесена из docuwiki)

Linux Apache PHP

Это обычный модуль Apache 2.x для Linux:

  • модуль предназначен для сбора и накопления статистики по использованию ресурсов(CPU и memory, время выполнения скрипта и пр.) веб-сервером Apache 2.4/2.2/2.0;

  • модуль позволяет производить анализ собранных данных. Он позволяет отслеживать за тем, сколько ресурсов потребляет поступивший веб-серверу запрос. Каждый раз сохраняя следующую информацию:

  • виртуальный хост, которому поступил запрос;

  • файл, который запрашивается;

  • URI запроса;

  • CPU нагрузка в %;

  • использование памяти в %;

  • время обработки запроса.

А накопившуюся статистику — позволяет анализировать. В качестве базы данных для сохранения и анализа используется SQLite (MySQL, PostgreSQL, error_log). Модуль позволяет отслеживать как абсолютно все запросы, так и конкретные, отфильтрованные по правилу с помощью регулярных выражений. Точнее будет сказано, что модуль ВСЕГДА обрабатывает только те запросы, которые соответствуют фильтру, содержащему регулярное выражение

Модуль адаптирован под Apache 2.0/2.2/2.4

  1. отключить selinux
  2. yum install httpd-devel apr-devel gd-devel sqlite3
  3. mkdir ~/tmp
  4. cd ~/tmp
  5. wget https://github.com/bayrepo/mod_performance/archive/master.zip --no-check-certificate -O mod_performance.zip
  6. unzip mod_performance.zip
  7. cd mod_performance-master/
  8. make
  9. cp .libs/mod_performance.so /etc/httpd/modules/
  10. cp mod_performance.conf /etc/httpd/conf.d/
  11. раскомментировать LoadModule performance_module modules/mod_performance.so
  12. mkdir -p /opt/performance/
  13. chown apache:apache /opt/performance/
  14. chmod 755 /opt/performance/
  15. раскомментировать в mod_performance.conf строки #PerformanceDB и #PerformanceSocket
  16. service httpd restart
  17. cp libmodperformance.so.0.4 /usr/lib64/
  18. ln -s libmodperformance.so.0.4 /usr/lib64/libmodperformance.so
  19. ldconfig

  1. отключить selinux
  2. apt-get install make apache2-prefork-dev libgd2-xpm-dev sqlite3
  3. mkdir ~/tmp
  4. cd ~/tmp
  5. wget https://github.com/bayrepo/mod_performance/archive/master.zip --no-check-certificate -O mod_performance.tar.gz
  6. unzip mod_performance.zip
  7. cd mod_performance-master/
  8. make
  9. cp .libs/mod_performance.so /usr/lib/apache2/modules/
  10. cp mod_performance.conf /etc/apache2/mods-available/
  11. echo "LoadModule performance_module /usr/lib/apache2/modules/mod_performance.so" > /etc/apache2/mods-available/mod_performance.load
  12. a2enmod mod_performance
  13. /etc/init.d/apache2 restart
  14. mkdir -p /opt/performance/
  15. chown www-data:www-data /opt/performance/
  16. chmod 755 /opt/performance/
  17. раскомментировать в mod_performance.conf строки #PerformanceDB и #PerformanceSocket
  18. service apache2 restart
  19. cp libmodperformance.so.0.4 /usr/lib64/
  20. ln -s libmodperformance.so.0.4 /usr/lib64/libmodperformance.so
  21. ldconfig

  1. отключить selinux
  2. yast2 -i apache2-devel gd-devel libapr1-devel sqlite3 make
  3. mkdir ~/tmp
  4. cd ~/tmp
  5. wget https://github.com/bayrepo/mod_performance/archive/master.zip --no-check-certificate -O mod_performance.tar.gz
  6. unzip mod_performance.zip
  7. cd mod_performance-master/
  8. make
  9. cp .libs/mod_performance.so /usr/lib/apache2-prefork/
  10. cp mod_performance.conf /etc/apache2/conf.d/
  11. раскомментировать LoadModule performance_module /usr/lib/apache2-prefork/mod_performance.so
  12. mkdir -p /opt/performance/
  13. chown wwwrun:wwwrun /opt/performance/
  14. chmod 755 /opt/performance/
  15. раскомментировать в mod_performance.conf строки #PerformanceDB и #PerformanceSocket
  16. service apache2 restart
  17. cp libmodperformance.so.0.4 /usr/lib64/
  18. ln -s libmodperformance.so.0.4 /usr/lib64/libmodperformance.so
  19. ldconfig

  1. pkg_add -rv apache
  2. pkg_add -rv apr-ipv6-devrandom-gdbm-db42
  3. pkg_add -rv gd
  4. pkg_add -rv wget
  5. cd ~/tmp
  6. wget https://github.com/bayrepo/mod_performance/archive/master.zip --no-check-certificate -O mod_performance.tar.gz
  7. unzip mod_performance.zip
  8. cd mod_performance-master/
  9. gmake
  10. cp .libs/mod_performance.so /usr/local/libexec/apache22/
  11. cp mod_performance.conf /usr/local/etc/apache22/Includes/
  12. раскомментировать LoadModule performance_module libexec/apache22/mod_performance.so
  13. mkdir -p /opt/performance/
  14. chown www:www /opt/performance/
  15. chmod 755 /opt/performance/
  16. раскомментировать в mod_performance.conf строки #PerformanceDB и #PerformanceSocket
  17. /usr/local/etc/rc.d/apache22 restart

  1. pkg install apache24
  2. pkg install graphics/gd
  3. pkg install wget
  4. pkg install sqlite3
  5. mkdir ~/tmp
  6. cd ~/tmp
  7. wget https://github.com/bayrepo/mod_performance/archive/master.zip --no-check-certificate -O mod_performance.zip
  8. unzip mod_performance.zip
  9. cd mod_performance-master/
  10. gmake
  11. cp .libs/mod_performance.so /usr/local/libexec/apache24/
  12. cp mod_performance.conf /usr/local/etc/apache24/Includes/
  13. раскомментировать или добавить LoadModule performance_module libexec/apache24/mod_performance.so
  14. mkdir -p /opt/performance/
  15. chown www:www /opt/performance/
  16. chmod 755 /opt/performance/
  17. раскомментировать в mod_performance.conf строки #PerformanceDB и #PerformanceSocket
  18. service apache24 start
  19. cp libmodperformance.so.0.4 /usr/lib/
  20. ln -s libmodperformance.so.0.4 /usr/lib/libmodperformance.so
  21. ldconfig

Устанавливает путь к сокету, посредством которого модуль общается с демоном. Параметр глобальный и не может переопределяться в виртуальных хостах и htaccess файлах. Значение по умолчанию logs/perfsocket — что означает, что сокет будет создан в директории logs Apache. Т.е там, где сервер складывает свои логи.

Не рекомендуется использовать значение по умолчанию,т.к. не на всех системах модуль будет иметь доступ к сокету послестарта и создания. Рекомендуется придерживаться инструкций и хранить сокет в отдельном каталоге /opt/performance/, созданном специально для нужд модуля.

Название: PerformanceSocket
Расположение в конфигурационном файле: Global
Значение по умолчанию: logs/perfsocket
Пример: PerformanceSocket /etc/httpd/logs/perf.sock

Флажок — On/Off. Если этот флажок установлен глобально, то ведется наблюдение за всеми виртуальными хостами. Если параметр глобально выключен, то возможно включение его в отдельных виртуальных хостах, тогда наблюдение будет производится только за этими хостами.

Название: PerformanceEnabled
Расположение в конфигурационном файле: Global, VirtualHost
Значение по умолчанию: Off
Пример: PerformanceEnabled On

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

При наличии трех условий PerformanceHostFilter, PerformanceScript, PerformanceURI условие выполняется только при положительной проверке трех фильтров. При наличии двух — условие выполняется при положительной проверке двумя фильтрами — третий не учитывается. Если не указан ни один фильтр — статистика не ведется ни для одного сайта. Отключить учет статистики можно можно установкой параметра PerformanceEnabled Off.

Название: PerformanceHostFilter
Расположение в конфигурационном файле: Global, VirtualHost
Значение по умолчанию: Null
Пример: PerformanceHostFilter example.host1.com example.host2.com …

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

Название: PerformanceHostFilterExternal
Расположение в конфигурационном файле: Global, VirtualHost
Значение по умолчанию: Null
Пример: PerformanceHostFilterExternal example.host1.com example.host2.com …

Регулярное выражение, для обработки только определенных выражением URI, иными словами – фильтр отслеживаемых запросов по URI(regexp синтаксис).

Название: PerformanceURI
Расположение в конфигурационном файле: Global, VirtualHost
Значение по умолчанию: Null
Пример: PerformanceURI .html$

Фильтр отслеживаемых запросов по вызываемому скрипту(regexp синтаксис).

Название: PerformanceScript
Расположение в конфигурационном файле: Global, VirtualHost
Значение по умолчанию: Null
Пример: PerformanceScript .php$

Хендлер веб-сервера — для вывода страницы отчета модуля. Статистика по всем хостам:

Название: PerformanceWorkHandler
Расположение в конфигурационном файле: Global, VirtualHost
Значение по умолчанию: performance-status
Пример: PerformanceWorkHandler performance-status

Хендлер веб-сервера — для вывода страницы отчета модуля. Статистика по вызываемому хосту:

Название: PerformanceUserHandler
Расположение в конфигурационном файле: Global, VirtualHost
Значение по умолчанию: user-status
Пример: PerformanceUserHandler user-status

Тип логирования — Log(сохранять информацию в лог PerformanceLog, PerformanceLogFormat), SQLite — сохранение информации в SQLite базу (PerformanceDB, PerformanceHistory), MySQL — сохранение информации в базу MySQL(PerformanceDbUserName, PerformanceDBPassword, PerformanceDBName, PerformanceDBHost, PerformanceHistory), Postgres — сохранение информации в базу PostgreSQL(PerformanceDbUserName, PerformanceDBPassword, PerformanceDBName, PerformanceDBHost, PerformanceHistory).

Название: PerformanceLogType
Расположение в конфигурационном файле: Global
Значение по умолчанию: SQLite
Пример: PerformanceLogType Log

Путь к базе данных типа – SQLite

Название: PerformanceDB
Расположение в конфигурационном файле: Global
Значение по умолчанию: logs/perfdb
Пример: PerformanceDB /etc/httpd/log/perf.db

Имя базы данных MySQL, PostgreSQL хранящей данные:

Название: PerformanceDbName
Расположение в конфигурационном файле: Global
Значение по умолчанию: perf_db
Пример: PerformanceDBName perfdb

Пользователь базы данных MySQL, PostgreSQL хранящей данные:

Название: PerformanceDbUserName
Расположение в конфигурационном файле: Global
Значение по умолчанию: perf_user
Пример: PerformanceDbUserName perf

Пароль базы данных MySQL, PostgreSQL хранящей данные:

Название: PerformanceDBPassword
Расположение в конфигурационном файле: Global
Значение по умолчанию: perf_password
Пример: PerformanceDBPassword pass

Хост базы данных MySQL, PostgreSQL хранящей данные:

Название: PerformanceDBHost
Расположение в конфигурационном файле: Global
Значение по умолчанию: localhost
Пример: PerformanceDBHost host1.com

Путь к файлу логов, где сохраняется информация по запросам в режиме Log:

Название: PerformanceLog
Расположение в конфигурационном файле: Global, VirtualHost
Значение по умолчанию: Null
Пример: PerformanceLog logs/perf.log

Формат выводимой в лог информации в режиме Log. Служебные переменные:

  • %DATE% -дата запроса,
  • %HOST% – хост запроса,
  • %URI% – uri запроса,
  • %SCRIPT% – скрипт исполняющий запрос,
  • %CPU% – использование процессора,
  • %MEM% – использование памяти,
  • %EXCTIME% – время исполнения скрипта,

  • % – знак процента:

    Название: PerformanceLogFormat
    Расположение в конфигурационном файле: Global
    Значение по умолчанию: [%DATE%] from %HOST% (%URI%) script %SCRIPT%: cpu %CPU%, memory %MEM%, execution time %EXCTIME%
    Пример: PerformanceLogFormat [%DATE%] from %HOST% (%URI%) script %SCRIPT%: cpu %CPU%, memory %MEM%, execution time %EXCTIME%

Число дней хранения истории для SQLite, MySQL, Postgres.

Название: PerformanceHistory
Расположение в конфигурационном файле: Global
Значение по умолчанию: 30
Пример: PerformanceHistory 10

Позволяет игнорировать redirect-handler. Если для анализируемого скрипта или сайта используется mod_rewrite. Рекомендуется установить его в On:

Название: PerformanceUseCanonical
Расположение в конфигурационном файле: Global
Значение по умолчанию: Off
Пример: PerformanceUseCanonical On

Режим подсчета % CPU. Solaris – 100% – это когда загружены все ядра, например 4 ядра и одно загружено на 100%, то будет отображено 25%. Irix – 100% – это когда одно ядро загружено на 100%. Например, если 2 ядра загружены на 100%, то будет отображаться – 200%

Название: PerformanceUseCPUTopMode
Расположение в конфигурационном файле: Global
Значение по умолчанию: Irix
Пример: PerformanceUseCPUTopMode Solaris

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

В формате HH:MM:SS или HH-MM-SS или ddddd.

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

Название: PerformanceCheckDaemonTimeExec
Расположение в конфигурационном файле: Global
Значение по умолчанию: NULL
Пример: PerformanceCheckDaemonTimeExec 20:00:00

Экспериментальный параметр для MySQL базы данных. Запускает оптимизацию базы данных модуля в указанное параметром время — ежедневно. Время указывается в формате HH:MM:SS или HH-MM-SS.

Название: PerformanceFragmentationTime
Расположение в конфигурационном файле: Global
Значение по умолчанию: NULL
Пример: PerformanceFragmentationTime 20:00:00

два параметра

  1. число(в 1/100 секунды),

  2. HARD/SOFT – задает минимальное время выполнения скрипта и способ его сохранения HARD(не сохранять)/SOFT(сохранять с 0 %CPU)

    Название: PerformanceMinExecTime
    Расположение в конфигурационном файле: Global
    Значение по умолчанию: NULL
    Пример: PerformanceMinExecTime 10 SOFT

Фильтр отслеживаемых запросов по вызываемому скрипту(regexp синтаксис) для таких модулей как mod_suphp и пр.

Название: PerformanceExternalScript
Расположение в конфигурационном файле: Global, VirtualHost
Значение по умолчанию: NULL
Пример: PerformanceExternalScript .php$

On или Off тихий режим, когда сообщения о том, что клиентский скрипт не смог соединиться с демоном или окончить сессию не падают в лог сервера

Название: PerformanceSilentMode
Расположение в конфигурационном файле: Global
Значение по умолчанию: On
Пример: PerformanceSilentMode Off

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

Используется в виде PerformanceSocketPermType 600 PID или PerformanceSocketPermType 777 NOPID. Используется для режимов работы mod_performance+mod_fcgid+php-cgi. Устанавливает права на сокет, указанные в этом параметре, а также модификацию имени сокета. По умолчанию, имя сокета задается как PerformanceSocket+.pid процесса. А для режима mod_fcgid, php-cgi должен знать точный путь к сокету, и чтоб он не менялся, задается режим NOPID. Если необходимо омтавить станадртные права, то задается PerformanceSocketPermType 000 NOPID. Для изменения прав сокета без смены названия – PerformanceSocketPermType 755 PID

Название: PerformanceSocketPermType
Расположение в конфигурационном файле: Global
Значение по умолчанию: 000 PID
Пример: PerformanceSocketPermType 777 NOPID

Для слежения за птоком/процессом использовать идентификатор потока (TID) – если On или идентификатор процесса (PID), если Off:

Название: PerformanceUseTid
Расположение в конфигурационном файле: Global
Значение по умолчанию: Off
Пример: PerformanceUseTid On

Устанавливает имя хоста, которое логируется вместе с параметрами запросов. Необходимо для одной глобальной базы данных, в которую собирается статистика со многих серверов:

Название: PerformanceHostId
Расположение в конфигурационном файле: Global
Значение по умолчанию: localhost
Пример: PerformanceHostId server1

Путь к файлу пользовательских отчетов:

Название: PerformanceCustomReports
Расположение в конфигурационном файле: Global
Значение по умолчанию: NULL
Пример: PerformanceCustomReports /opt/performance/customrep.tpl

Для создания пользовательского отчета используется следующий синтаксис в файле custom.tpl:

[название отчета]
header=Fld 1|Fld 2|Fld 3;
ssql=запрос в синтаксисе SQLite;
msql=запрос в синтаксисе MySQL;
psql=запрос в синтаксисе PostgerSQL;
sort=1,2;

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

Header – название и список выводимых полей по порядку в select разделенные знаком «|». В примере, первое подхваченное поле из select будет выведено в столбце Fld 1, второе в столбце Fld 2 и т.д.

Ssql, msql, psql – запросы к базе. Рекомендую использовать не прямые названия полей таблицы, а их псевдонимы. Отчет отображается, если для текущей конфигурации БД есть запрос(SSQL,MSQL,PSQL)

Соответствие поля таблицы и псевдонима:

  • id :ITEMNUMBER: – идентификатор записи
  • dateadd :DATEADD: – дата добавления записи
  • host :FORHOST: – хост, к которому осуществлялся запрос
  • uri :REQUESTURI: – URI запроса
  • script :CALLEDSCRIPT: – вызываемый скрипт
  • cpu :CPUUSAGE: – CPU в %
  • memory :MEMUSAGEINPRCT: – память в %
  • exc_time :EXECUTIONTIME: – время исполнения запроса
  • cpu_sec :CPUUSAGEINSEC:
  • memory_mb :MEMUSAGEINMB: – память в Mb
  • bytes_read :BYTESREAD:- байт прочитано
  • bytes_write :BYTESWRITE: – байт записано
  • hostnm :HOSTNAME: – запрос осуществлялся на сервере …

Поля для фильтра:

  • :FILTER: – учитывать поля фильтра
  • :PERIOD: – учитывать введенный период
  • performance – :TBL: – псевдоним таблицы

Пример:

file mysql custom.tpl

select count(*) as t1, sum(:CPUUSAGE:)/count(*) as t2, sum(:MEMUSAGEINPRCT:)/count(*) as t3, sum(:BYTESREAD:+:BYTESWRITE:)/count(*) as t4,  :CALLEDSCRIPT:, :FORHOST: from :TBL: where :FILTER: and :PERIOD: group by :CALLEDSCRIPT:,:FORHOST:

Установить этап сбора статистики модулем. LogHook - в logtransaction hook апача или Filter - в выходном фильтре. LogHook - рекомендуется для: mpm-prefork, mpm-itk, а Filter - для mpm-worker, mpm-event.

Название: PerformanceWorkMode
Расположение в конфигурационном файле: Global
Значение по умолчанию: LogHook
Пример: PerformanceWorkMode Filter

Для работы mod_performance с любым типом php(кроме dso) необходимо использовать расширение php: modperf_ext.so. Расширение доступно в исходниках mod_performance. Что необходимо для сборки:

  • Собрать модуль (описано выше)
  • yum install php-devel
  • cd ~/tmp/mod_performance-master/php_ext/modperf_ext
  • phpize
  • ./configure %%--%%enable-modperf_ext
  • make
  • cp .libs/modperf_ext.so /usr/lib64/php/modules/
  • cp modperf_ext.ini /etc/php.d/
  • в php.ini в конце добавить:
[modperf_ext]
modperf_ext.enabled = On

  • в файле /etc/httpd/conf.d/mod_performance.conf

    • раскомментировать строку LoadModule performance_module /opt/lexvit/mod_performance04/mod_performance.so
    • закомментировать строку #PerformanceScript .php
    • раскомментировать или добавить строки

    PerformanceDB /opt/performance/perfdb PerformanceSocket /opt/performance/perfsock PerformanceSocketPermType 777 NOPID

Если необходимо собрать расширения для нескольких версий php то вместо phpize и ./configure %%--%%enable-modperf_ext необходимо сделать:

  • вызвать phpize того php для которого собирается расширение
  • вызвать ./configure %%--%%enable-modperf_ext %%--%%with-php-config=[путь к php-config]

Пример

/usr/local/php53/bin/phpize
./configure --enable-modperf_ext --with-php-config=/usr/local/php53/bin/php-config

для каждой версии php

Пример настройки пользовательских отчетов (для CentOS/Redhat/Fedora) поставляемых с исходным кодом модуля:

  • mkdir ~/tmp
  • cd ~/tmp
  • wget https://github.com/bayrepo/mod_performance/archive/master.zip --no-check-certificate -O mod_performance.zip
  • unzip mod_performance.zip
  • cd mod_performance-master/
  • mkdir -p /opt/performance/
  • chown apache:apache /opt/performance/
  • chmod 755 /opt/performance/
  • cp custom.tpl /opt/performance/
  • добавить в mod_performance.conf параметр PerformanceCustomReports /opt/performance/custom.tpl
  • service httpd restart

Список пользовательских отчетов доступных по-умолчанию:

  1. Show site average usage in different time period – показать среднюю нагрузку создаваемую сайтом в различные временные периоды
  2. Show most popular script by site – показать наиболее часто вызываемый скрипт по каждому сайту
  3. Show CPU load range by site – показать распределение нагрузки CPU по каждому сайту
  4. Show Memory Usage range by site — показать распределение использования памяти по каждому сайту
  5. Show Max CPU load in different time periods by site – показать максимальную нагрузку CPU в различные временные периоды по каждому сайту
  6. Show Max Memory Usage in different time periods by site — показать максимальное использование памяти в различные временные периоды по каждому сайту
  7. Show Max IO Usage in different time periods by site — показать максимальную IO нагрузку в различные временные периоды по каждому сайту

Для создания пользовательского отчета используется следующий синтаксис в файле custom.tpl:

[название отчета]
header=Fld 1|Fld 2|Fld 3;
ssql=запрос в синтаксисе SQLite;
msql=запрос в синтаксисе MySQL;
psql=запрос в синтаксисе PostgerSQL;
sort=1,2;

В квадратных скобках пишется название отчета.

  • Header – название и список выводимых полей по порядку в select разделенные знаком «|». В примере, первое подхваченное поле из select будет выведено в столбце Fld 1, второе в столбце Fld 2 и т.д.
  • Ssql, msql, psql – запросы к базе. Рекомендую использовать не прямые названия полей таблицы, а их псевдонимы. Отчет отображается, если для текущей конфигурации БД есть запрос(SSQL,MSQL,PSQL) Соответствие поля таблицы и псевдонима:
  • id :ITEMNUMBER: – идентификатор записи
  • dateadd :DATEADD: — дата добавления записи
  • host :FORHOST: — хост, к которому осуществлялся запрос
  • uri :REQUESTURI: — URI запроса
  • script :CALLEDSCRIPT: — вызываемый скрипт
  • cpu :CPUUSAGE: — CPU в %
  • memory :MEMUSAGEINPRCT: — память в %
  • exc_time :EXECUTIONTIME: — время исполнения запроса
  • cpu_sec :CPUUSAGEINSEC:
  • memory_mb :MEMUSAGEINMB: — память в Mb
  • bytes_read :BYTESREAD:- байт прочитано
  • bytes_write :BYTESWRITE: — ,fqn pfgbcfyj
  • hostnm :HOSTNAME: — запрос осуществлялся на сервере …

Поля для фильтра:

  • :FILTER: — учитывать поля фильтра
  • :PERIOD: — учитывать введенный период
  • performance — :TBL: – псевдоним таблицы

Пример:

select count(*) as t1, sum(:CPUUSAGE:)/count(*) as t2, sum(:MEMUSAGEINPRC
T:)/count(*) as t3, sum(:BYTESREAD:+:BYTESWRITE:)/count(*) as t4,  :CALLEDSCRIPT:, :FORHOST: from :TBL: where :FILTER: and :PERIOD: group by :CALLEDSCRIPT:,:
FORHOST:

Полное описание

Настройка модуля для работы с централизованным хранилищем:

  • в централизованном хранилище(MySQL, PostgreSQL) необходимо создать пользователя, базу данных и таблицу.
    MySQL: CREATE TABLE IF NOT EXISTS performance(id INT NOT NULL AUTO_INCREMENT, dateadd DATETIME, host VARCHAR(255), uri VARCHAR(512), script VARCHAR(512), cpu FLOAT(15,5), memory FLOAT(15,5), exc_time FLOAT(15,5), cpu_sec FLOAT(15,5), memory_mb FLOAT(15,5), bytes_read FLOAT(15,5), bytes_write FLOAT(15,5), hostnm CHAR(32), PRIMARY KEY(id))
    PostgreSQL: create table performance(id SERIAL, dateadd timestamp, host varchar(255), uri varchar(512), script varchar(512), cpu float(4), memory float(4), exc_time float(4), cpu_sec float(4), memory_mb float(4), bytes_read float(4), bytes_write float(4), hostnm char(32), PRIMARY KEY(id))
  • на серверах, с которых будут собираться данные прописать в mod_performance.conf
    PerformanceLogType MySQL или Postgres
    PerformanceHostId HostName (вписать уникальное имя для каждого хоста, например его IP или прочее)
    PerformanceDbUserName username
    PerformanceDBPassword userpassword
    PerformanceDBName dbname
    PerformanceDBHost hostname – IP адрес или имя сервера с централизованным хранилищем данных

Скачать исходные коды модуля на github здесь

При запуске веб-сервера Apache — запускается демон модуля mod_performance. Успешный запуск демона отмечается в логе сервера строками ниже:

[timestamp] mod_performance: module enabled :)
[timestamp] mod_performance: server started :)

Запустившийся демон открывает unix-сокет и ожидает соединений.

При обработке запроса сервером, происходит проверка запроса на условие: необходимо ли для запроса сохранять статистику или нет. Если проверка прошла успешно, процесс сервера, принявший соединение отправляет демону информацию из procfs и PID(TID) процесса/потока, который будет обрабатывать запрос. По окончании работы отслеживаемого процесса, демон записывает данные в базу данных статистики. На текущий момент, модуль может работать в режиме сервера:

  • Apache mod_php (prefork, worker);
  • Apache itk + mod_php
  • Apache mod_ruid2 + mod_php
  • Apache + suphp (c наложенным патчем на suphp)((устаревший метод))
  • Apache + php-fpm (c наложенным патчем на php-fpm)((устаревший метод))
  • Apache + любой тип php (с помощью расширения php)(описан выше)

Полный список параметров описан выше.

Приведу пример сборки и конфигурирование модуля для CentOS:

  1. отключить selinux
  2. yum install httpd-devel apr-devel gd-devel sqlite3
  3. mkdir ~/tmp
  4. cd ~/tmp
  5. wget https://github.com/bayrepo/mod_performance/archive/master.zip %%--%%no-check-certificate -O mod_performance.zip
  6. unzip mod_performance.zip
  7. cd mod_performance-master/
  8. make
  9. cp .libs/mod_performance.so /etc/httpd/modules/
  10. cp mod_performance.conf /etc/httpd/conf.d/
  11. раскомментировать LoadModule performance_module modules/mod_performance.so
  12. mkdir -p /opt/performance/
  13. chown apache:apache /opt/performance/
  14. chmod 755 /opt/performance/
  15. раскомментировать в mod_performance.conf строки #PerformanceDB и #PerformanceSocket
  16. service httpd restart
  17. cp libmodperformance.so.0.4 /usr/lib64/
  18. ln -s libmodperformance.so.0.4 /usr/lib64/libmodperformance.so
  19. ldconfig

Типовая конфигурация для DSO: CentOS

file mod_performance.conf

LoadModule performance_module modules/mod_performance.so

`<IfModule mod_performance.c>`
 PerformanceEnabled On
 PerformanceUseCanonical On
 PerformanceScript .php
 PerformanceLogType SQLite
 PerformanceDB /opt/performance/perfdb
 PerformanceSocket /opt/performance/perfsock
 #Minimal script execution time, wich accounts by script as load
 PerformanceMinExecTime 50 SOFT
 <Location /performance-status>
 SetHandler performance-status
    Allow from 1.1.1.1
 </Location>

</IfModule>

Объясню, что задано в конфигурационном файле.

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

PerformanceScript — здесть самое сердце модуля. Этот параметр задает — за чем следить. За какими скриптами. Я установил, что необходима слежка именно за PHP-скриптами.Параметр принимает регулярное выражение.

PerformanceUseCanonical -параметр позволяет игнорировать redirect-handler, генерируемый модулем mod_rewrite. Например, если не включить этот параметр, то можно в итоге получит не путь к скрипту, а нечто нижеследующее:

redirect: /index.php

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

Далее, подобно mod_status, я прикрепляю админский хендлер модуля ко всем хостам по запросу /admin-status. И разрешаю доступ к этой странице только с адреса 1.1.1.1.

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

PerformanceDB и PerformanceSocket задают путь к базе дынных и сокету.

Типовая конфигурация для php как cgi,suphp,php-fpm,cgid,fastcgi. Предварительно устанавливается расширение:

file mod_performance.conf

LoadModule performance_module modules/mod_performance.so

<IfModule mod_performance.c>
 PerformanceEnabled On
 PerformanceUseCanonical On
 PerformanceLogType SQLite
 PerformanceDB /opt/performance/perfdb
 PerformanceSocket /opt/performance/perfsock
 #Minimal script execution time, wich accounts by script as load
 PerformanceMinExecTime 50 SOFT
 PerformanceSocketPermType 777 NOPID
 <Location /performance-status>
    SetHandler performance-status
    Allow from 1.1.1.1
 </Location>

</IfModule>

Доступен при PerformanceLogType = SQLite, MySQL, Postgres.

Расскажу немного о его особенностях (рис 1).

Рис 1.

  1. Hide/Show – кнопка «Скрыть/Показать фильтр» – предназначена для сворачивания и разворачивания окна фильтров.\
  2. Report – выпадающий список доступных отчетов (отчеты анализа накопленных данных)\
  3. Sort Field – номер выводимого поля, по которому будет производится сортировка (не действует на пользовательские отчеты)\
  4. Sort Type – тип сортировки выбранного поля – по-возрастанию или по-убыванию (не действует на пользовательские отчеты)\
  5. Period(days) – интервал в днях от текущего дня за который будут проанализированы данные\
  6. Period begin (Period End) – точная дата и время начала и конца анализируемого периода (если указаны эти значения, то поле Period(days) игнорируется)\
  7. Дополнительные параметры фильтра анализируемых данных. Возможно как строгое совпадение, так и не строгое – например значение заканчивающееся на test – %test.\
  8. Дополнительные параметры фильтра анализируемых данных. Возможно как строгое совпадение, так и не строгое – например значение заканчивающееся на test – %test.\
  9. Дополнительные параметры фильтра анализируемых данных. Возможно как строгое совпадение, так и не строгое – например значение заканчивающееся на test – %test.\
  10. Ссылка на скачивание самой последней версии\
  11. Ссылка на документацию по модулю\
  12. Значок сортировки данных на странице (v – по-убыванию, ^-по-возрастанию)\
  13. Строка заголовков столбцов\
  14. Фиксированная строка номера столбца. Не сдвигается даже при прокрутке страницы.\

Интерфейс модуля использует JavaScript.

  • 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 за период, средний % использования памяти, среднее время выполнения скриптов);

Выводимые поля в отчетах:

  • ID — идентификатор записи;
  • 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

Если текстовой информации не достаточно, есть возможность посмотреть на диаграмму:

Добавлена возможность создавать свои отчеты (отчет – это метод анализа собираемых модулем данных). Модуль по-прежнему несет определенный набор отчетов, так называемый «из коробки». Но в исходных кодах модуля присутствует файл custom.tpl, который расширяет число доступных отчетов модуля. А также позволяет создавать свои собственные запросы к базе данных и отображение полученных результатов. Как это сделать я опишу далее.

Пример настройки пользовательских отчетов (для CentOS/Redhat/Fedora) поставляемых с исходным кодом модуля:

Пользовательские отчеты - описаны выше.

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

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

Показатель IO (read & write) отслеживается подобно CPU — производится замер прочитанных и записанных данных процесса в начале запроса и в конце запроса. Разница этих величин переводится в килобайты и сохраняется в базе. Т.е. фактически этот показатель отслеживает число записанных/прочитанных байт в течении существования запроса. Сразу скажу, что в качестве анализируемого источника используется показатель: /proc/[pid]/io — read_bytes, write_bytes, cancelled_write_bytes.

Вот он важный вопрос — куда сохранить собираемую статистику. Для упрощения этой головоломки в новой версии модуля встроена поддержка таких БД как: SQLite, MySQL, PostgreSQL, а так же экзотика — сохранение в файл логов. Теперь не нужно подстраиваться под модуль — он подстроится под вас. Для успешной работы модуля(не в режиме «Сохранение в лог») необходимо наличие на машине хотя бы одной из следующих библиотек:

  • libsqlite3.so;
  • libmysqlclient_r.so;
  • libpq.so.

При сборке пакета наличие mysql-devel, sqlite-devel, postgresql-devel не требуется. Эти библиотеки подгрузятся динамически во время работы модуля. Точнее подгрузится нужная для выбранного режима библиотека.

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

Для работы с 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: в старой базе и новой различаются структуры таблиц, поэтому для успешной работы старую базу лучше удалить. Т.к. cам модуль не пересоздает существующую таблицу.

Пример 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

file /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.4 поменялся формат таблицы данных. Для корректного функционирования 0.4 версии старую таблицу необходимо модифицировать:

:::sql
SQLITE: ALTER TABLE performance ADD hostnm CHAR(32);
MySQL: ALTER TABLE performance ADD hostnm CHAR(32);
PostreSQL: ALTER TABLE performance ADD hostnm CHAR(32);

Добавить комментарий

Следующая запись Предыдущая запись