Довгі очікування до відповіді сервера Apache 2.2 (Gentoo LAMP)

Нещодавно я перемістив веб-сайт клієнта (використовуючи бетон5 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% (використовуючи верхню частину) - мені здається, що для поскорення цієї налаштування потрібні або погано оптимізовані речі MySQL, або кешування.

Будь-яка допомога буде дуже вдячна!

Ви точно знаєте, на чому зависають працівники апаш-праці? Спробуйте це побачити:

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

Завантажте декілька нових (тобто не кешованих локально) сторінок у своєму браузері, CTRL + C, щоб зупинити стразе, а потім сортуйте 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 з обтяженням на дзвінки gettimeofday потрібно було до 5 секунд і більше. Дивно я звузив це до CSF, який намагався фільтрувати інтерфейс venet0, інтерфейс зворотного зв'язку в контейнерах OpenVZ або Virtuozzo. Встановлення цього параметра в /etc/csf/csf.conf в основному для мене виправлено:

"ETH_DEVICE_SKIP = "venet0,lo"

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

Ось чудовий праймер / практичний вигляд для усунення неполадок у подібних проблемах за допомогою страйку.

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 це не ваша конфігурація сервера. / маддін