Apache 2.2 sunucu yanıtından önce uzun bekleme süreleri (Gentoo LAMP)

Son zamanlarda bir müşterinin web sitesini (concrete5 CMS kullanarak) Gentoo, Apache 2.2, PHP5 ve MySQL 5 çalıştıran bir VPS'ye taşıdım ve Apache yanıt sürelerinin oldukça kötü olduğunu fark ettim (eski sunucuda da aynıydı) , bazen 8-9 saniyeye kadar, ama daha sık 300ms ve 3 saniye arasında (300ms doğru umursamıyorum). Sunucunun 30ms civarında (konumumdan) bir pingi olduğundan ağ gecikmesi olmadığını biliyorum.

İşte zamanların bir örneği (ilk beklemeden sonra çabuk olduğunu görebilirsiniz):

APC kullanıyorum (bunun doğru çalıştığından emin değilim ...) ve SuExec. Apache modülleri:

 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)

ve PHP modülleri:

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

İlgili tüm dosyalarda gzip etkin.

Apache prefork kullanarak çalışıyor ve httpd.conf'daki ayarlar şunlardır:

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

HostnameLookups Off

CMS'nin Kontrol Paneli gibi veritabanı ağırlıklı olan sayfaların genellikle daha yavaş olduğunu fark ettim. Bunun MySQL'in optimize edilebileceği anlamına gelebileceğini düşündüm. Ben de Apache modülleri hakkında merak ettim - mod_php5, mod_cgi, mod_fastcgi vs vs arasında karıştı - kullanmak için en iyi birine net üzerinden çakışan tavsiye var.

MySQLTuner çıktısı :

-------- 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)

Bir DB-ağır sayfa yüklendiğinde, CPU kullanımı% 57 (üst kullanarak) arttı fark ettim - bana bu kötü optimize bir MySQL malzeme ya da bu kurulum hızlandırmak için kesinlikle önbellek gerekli olduğunu düşündürmektedir.

Herhangi bir yardım çok takdir edilecektir!

Apache çalışanı işlemlerinin tam olarak hangi süreçlere asıldığını biliyor musunuz? Bunu görmek için şunu deneyin:

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

Tarayıcınıza birkaç yeni (yani yerel olarak önbelleğe alınmayan) sayfa yükleyin, katmanlamayı durdurmak için CTRL + C tuşlarına basın ve ardından strace.log'ları her çağrıda harcanan zamana göre sıralayın:

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

1.0 saniyeden fazla çağrı ile strace.log'ları görüntüleyin ve önceki komutun çıkışından itibaren zamana göre arama yapın. Bu sizi asıldıkları tam adıma yönlendirecektir.

Değişiklik yaparak CSF gibi bir güvenlik duvarınız var mı? Aynı problemi bir VPS'de gördüm. Httpd işlemlerinde strage ile hata ayıklarken gettimeofday çağrılarında 5 saniye veya daha uzun sürüyordu. Garip bir şekilde bunu, OpenVZ veya Virtuozzo kaplarındaki geri döngü arayüzü olan venet0 arayüzünü filtrelemeye çalışan CSF'ye daralttım. /Etc/csf/csf.conf dosyasında bu parametreyi ayarlamak çoğunlukla benim için düzeltti:

"ETH_DEVICE_SKIP = "venet0,lo"

Çoğunlukla diyorum çünkü bazen bağlantıların kurulmasını beklemek için 500-1000 ms var ama 5000'den büyük bir gelişme.

İşte bir var mükemmel astar / walktthrough strace kullanarak bu tür konuları sorun giderme.

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

Bu bir alt uç VPS kutusu olmalı mı?

• MySQL ayarlarınızı geri çevirmek isteyebilirsiniz
• Httpd çatallarının sayısını azaltmak için Apache'yi ayarlayın
• Değiştirmeyi etkinleştirip etkinleştiremeyeceğinizi kontrol edin
• APC otomatik olarak önbellekleri önbelleğe alacak şekilde ayarlanmış mı? Apc ile dağıtılan 'apc.php' komut dosyasını kullanarak kontrol edin.

Gecikmenin kaynakları olarak ağ, apache, mysql ve php'yi ayırmanız gerekir.

Bir görüntüyü apache'den hızlı bir şekilde çekebiliyorsanız (ilk bayta çok az zaman), ağ ve apache genellikle iyidir.

Bir phpinfo () ifadesi ile bir sayfa çekebiliyorsanız, genellikle PHP tamamdır (birkaç değişiklik gerekebilir).

Basit bir DB bağlantı testi yazarsanız ve hızlıysa, o katman genellikle de iyidir.

Son olarak, uygulama sayfasını çekin. Yavaşsa, sorun uygulamaların işlenmesinde dâhildir. Ayarlama yardımcı olabilirken, bu sorunun çözülmesi çok daha zordur.

Uygulamayı profillemeden sorunu bulmak zor olabilir. NewRelic gibi araçlar bu soruna yardımcı olabilir, ancak bir tedavi değildir.

Uygulamanızın zamanın nerede harcandığını göstermek için herhangi bir dahili hata ayıklaması var mı?

bir oluşturma süresi ölçümü ekleme ve sunucunun saf HTML sayfasını işlemenin ne kadar sürdüğünü kontrol etmenizi öneririz. Sonra biliyorsun onun CMS veya başka bir yerde. Bahse girerim benim 2cent onun sunucu yapılandırma değil. / Maddin