Waktu tunggu yang lama sebelum respons server Apache 2.2 (Gentoo LAMP)

Saya baru-baru ini memindahkan situs web klien (menggunakan CMS concrete5) ke VPS yang menjalankan Gentoo, Apache 2.2, PHP5 dan MySQL 5 dan saya perhatikan bahwa waktu respons Apache sangat buruk (sama pada server lama) , kadang-kadang jauh hingga 8-9 detik, tetapi lebih sering antara 300ms dan 3 detik (menuju 300ms saya tidak keberatan). Saya tahu ini bukan latensi jaringan, karena server memiliki ping (dari lokasi saya) sekitar 30ms.

Berikut ini adalah contoh waktu (Anda dapat melihat itu tajam setelah menunggu awal):

Saya menjalankan APC (walaupun saya tidak yakin itu berfungsi dengan benar ...) dan SuExec. Modul Apache adalah:

 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)

dan modul PHP adalah:

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

Saya mengaktifkan gzip di semua file yang relevan.

Apache berjalan menggunakan prefork, dan pengaturan di httpd.conf adalah:

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

HostnameLookups Off

Saya perhatikan bahwa halaman-halaman yang (menurut saya) adalah database-berat, seperti Dashboard CMS, biasanya lebih lambat. Saya pikir ini mungkin berarti MySQL dapat dioptimalkan. Saya bertanya-tanya juga tentang modul Apache - saya bingung antara mod_php5, mod_cgi, mod_fastcgi dll dll - ada saran yang saling bertentangan di internet untuk yang terbaik untuk digunakan.

Inilah output dari 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)

Saya perhatikan ketika halaman DB-berat dimuat, penggunaan CPU melonjak 57% (menggunakan atas) - bagi saya yang menunjukkan ada beberapa hal MySQL yang dioptimalkan dengan buruk atau cache sangat diperlukan untuk mempercepat pengaturan ini.

Bantuan apa pun akan sangat dihargai!

Apakah Anda tahu persis apa proses pekerja apache digantung? Coba ini untuk melihat:

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

Muat beberapa halaman baru (yaitu tidak di-cache secara lokal) di browser Anda, CTRL + C untuk menghentikan strace kemudian mengurutkan strace.log berdasarkan waktu yang dihabiskan untuk setiap panggilan:

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

Lihat strace.logs dengan panggilan lebih dari 1,0 detik dan cari berdasarkan waktu dari output perintah sebelumnya. Ini akan mengarahkan Anda ke langkah yang tepat mereka digantung.

Apakah Anda memiliki firewall seperti CSF yang diinstal? Saya melihat masalah yang sama pada VPS. Saat men-debug proses httpd dengan strace, diperlukan waktu hingga 5 detik atau lebih pada panggilan gettimeofday. Anehnya, saya mempersempitnya menjadi CSF, yang mencoba memfilter antarmuka venet0, antarmuka loopback dalam wadah OpenVZ atau Virtuozzo. Mengatur parameter ini di /etc/csf/csf.conf sebagian besar memperbaikinya untuk saya:

"ETH_DEVICE_SKIP = "venet0,lo"

Saya katakan sebagian besar karena kadang-kadang masih ada 500-1000ms menunggu koneksi untuk membangun tetapi ini adalah peningkatan besar dari 5000+.

Berikut ini adalah sangat baik primer / walktthrough untuk pemecahan masalah jenis masalah menggunakan strace.

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

Ini harus berupa kotak VPS low-end?

• Anda mungkin ingin mematikan pengaturan MySQL Anda
• Tune Apache untuk mengurangi jumlah garpu httpd
• Periksa apakah Anda dapat mengaktifkan swapping
• Apakah APC diatur untuk secara otomatis menyimpan opcodes? Periksa menggunakan skrip 'apc.php' yang didistribusikan dengan apc.

Anda harus memisahkan jaringan, apache, mysql, dan php sebagai sumber latensi.

Jika Anda dapat menarik gambar dari apache dengan cepat (waktu sangat rendah ke byte pertama), maka jaringan dan apache biasanya baik-baik saja.

Jika Anda dapat menarik halaman hanya dengan pernyataan phpinfo (), maka PHP biasanya baik-baik saja (mungkin perlu beberapa penyesuaian).

Jika Anda menulis tes koneksi DB sederhana dan cepat, maka layer itu biasanya ok juga.

Terakhir, tarik halaman aplikasi. Jika lambat maka masalahnya adalah internal untuk pemrosesan aplikasi. Meskipun penyetelan bisa membantu, ini jauh lebih sulit untuk diselesaikan.

Tanpa membuat profil aplikasi, akan sulit menemukan masalahnya. Alat seperti NewRelic dapat membantu dengan masalah ini tetapi bukan obatnya.

Apakah aplikasi Anda memiliki jenis debugging internal untuk menunjukkan di mana waktu dihabiskan?

saya sarankan menambahkan pengukuran waktu rendering dan memeriksa berapa lama server untuk membuat halaman HTML murni. Maka Anda tahu apakah itu di CMS atau di tempat lain. Saya yakin 2cent saya bukan konfigurasi server Anda. / Nyonya