Долгое время ожидания до ответа сервера Apache 2.2 (Gentoo LAMP)

Недавно я переместил веб-сайт клиента (с использованием конкретной CMS) на VPS, работающий на Gentoo, Apache 2.2, PHP5 и MySQL 5, и заметил, что время отклика Apache довольно плохое (на старом сервере это было то же самое) иногда до 8-9 секунд, но чаще от 300 мс до 3 с (до 300 мс я не против). Я знаю, что это не задержка в сети, так как сервер имеет пинг (от моего местоположения) около 30 мс.

Вот пример времени (вы можете увидеть его быстро после первоначального ожидания):

Я использую APC (хотя я не уверен, что он работает правильно ...) и SuExec. Модули Apache:

 core_module (static)
 authn_file_module (static)
 authn_default_module (static)
 authz_host_module (static)
 authz_groupfile_module (static)
 authz_user_module (static)
 authz_default_module (static)
 auth_basic_module (static)
 include_module (static)
 filter_module (static)
 deflate_module (static)
 log_config_module (static)
 env_module (static)
 expires_module (static)
 headers_module (static)
 setenvif_module (static)
 version_module (static)
 ssl_module (static)
 mpm_prefork_module (static)
 http_module (static)
 mime_module (static)
 status_module (static)
 autoindex_module (static)
 asis_module (static)
 info_module (static)
 suexec_module (static)
 cgi_module (static)
 negotiation_module (static)
 dir_module (static)
 actions_module (static)
 userdir_module (static)
 alias_module (static)
 rewrite_module (static)
 so_module (static)
 suphp_module (shared)

и PHP модули:

bcmath
calendar
ctype
curl
db
dbase
domxml
exif
ftp
gd
gettext
iconv
imap
mbstring
mcrypt
mime_magic
mysql
openssl
overload
pcre
posix
session
standard
sysvsem
sysvshm
tokenizer
xml
xslt
zlib

У меня включен gzip для всех соответствующих файлов.

Apache работает с использованием prefork, а настройки в httpd.conf:

<IfModule prefork.c>
StartServers         10
MinSpareServers      10
MaxSpareServers      20
MaxClients           250
MaxRequestsPerChild  4000
</IfModule>

HostnameLookups Off

Я заметил, что страницы, которые (я думаю) имеют большой объем базы данных, такие как панель инструментов CMS, обычно медленнее. Я думал, что это может означать, что MySQL может быть оптимизирован. Мне также интересно узнать о модулях Apache - я запутался между mod_php5, mod_cgi, mod_fastcgi и т. Д. И т. Д. - в сети есть противоречивые советы относительно того, какой из них лучше всего использовать.

Вот вывод MySQLTuner :

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.44-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 35M (Tables: 161)
[!!] Total fragmented tables: 15

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 3d 21h 44m 16s (293K q [0.868 qps], 1K conn, TX: 135M, RX: 90M)
[--] Reads / Writes: 99% / 1%
[--] Total buffers: 58.0M global + 1.6M per thread (100 max threads)
[!!] Maximum possible memory usage: 219.7M (93% of installed RAM)
[OK] Slow queries: 0% (0/293K)
[OK] Highest usage of available connections: 2% (2/100)
[OK] Key buffer size / total MyISAM indexes: 16.0M/20.9M
[OK] Key buffer hit rate: 99.6% (5M cached / 21K reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 3K sorts)
[!!] Temporary tables created on disk: 47% (2K on disk / 5K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 6% (64 open / 1K opened)
[OK] Open file limit used: 12% (128/1K)
[OK] Table locks acquired immediately: 100% (356K immediate / 356K locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Reduce your overall MySQL memory footprint for system stability
    Enable the slow query log to troubleshoot bad queries
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    query_cache_size (>= 8M)
    tmp_table_size (> 32M)
    max_heap_table_size (> 16M)
    thread_cache_size (start at 4)
    table_cache (> 64)

Я заметил, что при загрузке страницы, загруженной БД, загрузка ЦП возросла на 57% (при использовании top) - для меня это говорит о том, что либо есть некоторые плохо оптимизированные компоненты MySQL, либо для ускорения этой установки абсолютно необходимо кэширование.

Любая помощь приветствуется!

Вы точно знаете, за что зависают рабочие процессы apache? Попробуйте это, чтобы увидеть:

mkdir /strace; ps auxw | grep httpd | awk '{print"-p " $2}' | xargs strace -o /strace/strace.log -ff -s4096 -r

Загрузите несколько новых (то есть не локально кэшированных) страниц в браузере, нажмите CTRL + C, чтобы остановить strace, а затем отсортируйте strace.logs по времени, потраченному на каждый вызов:

for i in `ls /strace/*`; do echo $i; cat $i | cut -c11-17 | sort -rn | head; done

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

У вас, напротив, установлен брандмауэр типа CSF? Я видел эту же проблему на VPS. При отладке процессов httpd с помощью strace на вызовы gettimeofday уходило до 5 секунд или более. Странно, я сузил это до CSF, который пытался отфильтровать интерфейс venet0, петлевой интерфейс в контейнерах OpenVZ или Virtuozzo. Установка этого параметра в /etc/csf/csf.conf по большей части исправила его для меня:

"ETH_DEVICE_SKIP = "venet0,lo"

Я говорю в основном потому, что иногда для установления соединения все еще остается 500-1000 мс, но это большое улучшение по сравнению с 5000+.

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

Maximum possible memory usage: 219.7M (93% of installed RAM)

Это должно быть бюджетная коробка VPS?

• Вы можете хотеть набрать свои настройки MySQL
• Настройте Apache, чтобы уменьшить количество вилок httpd
• Проверьте, можете ли вы включить обмен
• APC настроен на автоматическое кэширование кодов операций? Проверьте, используя скрипт apc.php, поставляемый с apc.

Вы должны разделить сеть, apache, mysql и php как источники задержки.

Если вы можете быстро извлечь изображение из apache (очень мало времени до первого байта), то сеть и apache обычно в порядке.

Если вы можете вытащить страницу только с помощью оператора phpinfo (), то обычно с PHP все в порядке (может потребоваться несколько настроек).

Если вы пишете простой тест соединения с БД, и он быстрый, то этот уровень обычно тоже в порядке.

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

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

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

Я предлагаю добавить измерение времени рендеринга и проверить, сколько времени требуется серверу для рендеринга чистой HTML-страницы. Тогда вы знаете, если это в CMS или в другом месте. Бьюсь об заклад, мой 2cent это не ваш конфиг сервера. / Maddin