Yüksek Yüklü Bir Apache Sunucusunu Performans Ayarlama

Ben (bizim için) ağır yüklü bir web sunucusu ile gördüğüm bazı sunucu performansı sorunlarını anlamak için arıyorum. Ortam aşağıdaki gibidir:

• Debian Lenny (tüm kararlı paketler + güvenlik güncellemelerine eklenmiştir)
• Apache 2.2.9
• PHP 5.2.6
• Amazon EC2 büyük örneği

Gördüğümüz davranış, web'in tipik olarak duyarlı hissetmesidir, ancak bir isteği işlemeye başlamak için hafif bir gecikmeyle - bazen bir saniyenin bir kısmı, bazen en yoğun kullanım sürelerimizde 2-3 saniye. Sunucudaki gerçek yük çok yüksek olarak bildiriliyor - genellikle 10.xx veya 20.xx tarafından bildirildiği gibi top. Ayrıca, bu zamanlarda (çift vi) sunucuda başka şeyler çalıştırmak çok yavaştır, bu yüzden yük kesinlikle oradadır. Garip bir şekilde, Apache ilk gecikme dışında çok duyarlı olmaya devam ediyor.

Önbellek kullanarak Apache'yi aşağıdaki gibi yapılandırdık:

StartServers          5
MinSpareServers       5
MaxSpareServers      10
MaxClients          150
MaxRequestsPerChild   0

Ve KeepAlive as:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

Sunucu durumu sayfasına baktığımızda, bu ağır yük zamanlarında bile, genellikle 80-100 istek ve saklayıcı durumdaki birçoğu arasında hizmet veren nadiren müşteri başlığına çarparız. Bu bana ilk istek yavaşlığını "bir işleyici bekliyorum" olarak dışlamamı söylüyor ama yanılıyor olabilirim.

Amazon'un CloudWatch izleme sistemi, işletim sistemimiz> 15 yükü bildirirken bile CPU kullanımımızın% 75-80 arasında olduğunu söylüyor.

Örnek çıktı top:

top - 15:47:06 up 31 days,  1:38,  8 users,  load average: 11.46, 7.10, 6.56
Tasks: 221 total,  28 running, 193 sleeping,   0 stopped,   0 zombie
Cpu(s): 66.9%us, 22.1%sy,  0.0%ni,  2.6%id,  3.1%wa,  0.0%hi,  0.7%si,  4.5%st
Mem:   7871900k total,  7850624k used,    21276k free,    68728k buffers
Swap:        0k total,        0k used,        0k free,  3750664k cached

Süreçlerin çoğu şuna benzer:

24720 www-data  15   0  202m  26m 4412 S    9  0.3   0:02.97 apache2                                                                       
24530 www-data  15   0  212m  35m 4544 S    7  0.5   0:03.05 apache2                                                                       
24846 www-data  15   0  209m  33m 4420 S    7  0.4   0:01.03 apache2                                                                       
24083 www-data  15   0  211m  35m 4484 S    7  0.5   0:07.14 apache2                                                                       
24615 www-data  15   0  212m  35m 4404 S    7  0.5   0:02.89 apache2            

vmstatYukarıdaki ile aynı zamanda örnek çıktı :

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 8  0      0 215084  68908 3774864    0    0   154   228    5    7 32 12 42  9
 6 21      0 198948  68936 3775740    0    0   676  2363 4022 1047 56 16  9 15
23  0      0 169460  68936 3776356    0    0   432  1372 3762  835 76 21  0  0
23  1      0 140412  68936 3776648    0    0   280     0 3157  827 70 25  0  0
20  1      0 115892  68936 3776792    0    0   188     8 2802  532 68 24  0  0
 6  1      0 133368  68936 3777780    0    0   752    71 3501  878 67 29  0  1
 0  1      0 146656  68944 3778064    0    0   308  2052 3312  850 38 17 19 24
 2  0      0 202104  68952 3778140    0    0    28    90 2617  700 44 13 33  5
 9  0      0 188960  68956 3778200    0    0     8     0 2226  475 59 17  6  2
 3  0      0 166364  68956 3778252    0    0     0    21 2288  386 65 19  1  0

Ve son olarak, Apache'nin çıktısı server-status:

Server uptime: 31 days 2 hours 18 minutes 31 seconds
Total accesses: 60102946 - Total Traffic: 974.5 GB
CPU Usage: u209.62 s75.19 cu0 cs0 - .0106% CPU load
22.4 requests/sec - 380.3 kB/second - 17.0 kB/request
107 requests currently being processed, 6 idle workers

C.KKKW..KWWKKWKW.KKKCKK..KKK.KKKK.KK._WK.K.K.KKKKK.K.R.KK..C.C.K
K.C.K..WK_K..KKW_CK.WK..W.KKKWKCKCKW.W_KKKKK.KKWKKKW._KKK.CKK...
KK_KWKKKWKCKCWKK.KKKCK..........................................
................................................................

Sınırlı tecrübemden şu sonuçları / soruları çıkarıyorum:

• Çok fazla KeepAlivetalebe izin veriyor olabiliriz

• Vmstat içinde IO beklerken biraz zaman geçirdim, ancak çok fazla değil (sanırım?) Bu yüzden bu büyük bir endişe ya da değil emin değilim, vmstat ile daha az deneyimli değilim

• Ayrıca vmstat'ta, bazı yinelemelerde sunulmayı bekleyen birkaç işlem görüyorum, bu da web sunucumuzdaki ilk sayfa yükleme gecikmesini, muhtemelen hatalı olarak ilişkilendiriyorum

• Statik içerik (% 75 veya daha yüksek) ve komut dosyası içeriğinin bir karışımını sunarız ve komut dosyası içeriği genellikle oldukça işlemcidir, bu nedenle ikisi arasında doğru dengeyi bulmak önemlidir; uzun vadede her iki sunucuyu da optimize etmek için statikleri başka bir yere taşımak istiyoruz, ancak yazılımımız bugün buna hazır değil

Herkesin herhangi bir fikri varsa ek bilgi vermekten mutluluk duyuyorum, diğer not ise bu yüksek kullanılabilirlikli bir üretim tesisidir, bu yüzden tweak sonrası tweak yapmaya dikkat ediyorum ve bu yüzden KeepAlivekendime değer gibi şeylerle oynamadım hala.

Bulutlarda bir şeyler yayınlamakla ilgili fazla bir şey olmadığını itiraf ederek başlayacağım - ancak başka bir yerde yaşadığım deneyime dayanarak, bu web sunucusu yapılandırmasının oldukça düşük bir trafik hacmini yansıttığını söyleyebilirim. Runqueue o kadar büyük ki, bununla başa çıkmak için yeterli CPU olmadığını gösteriyor. Çalışma sırasında başka neler var?

Çok fazla KeepAlive isteğine izin veriyor olabiliriz

Hayır - keeplive hala performansını artırır 5 saniyelik bir zaman aşımı oldukça yüksek hala olmasına rağmen, modern tarayıcılar, zaman paralel istekleri çalıştırmak için zaman boru hattına bilerek ve hakkında çok akıllı ve bir var ÇOK bekleyen sunucuların - Sürece' ve BÜYÜK gecikme sorunları var 2-3 aşağı bu krank tavsiye ederim. Bu, çalışma süresini biraz kısaltmalıdır.

Web sunucusunda zaten mod_deflate yüklü değilse - o zaman bunu yapmanızı tavsiye ederim - ve ob_gzhandler () 'i PHP betiklerinize ekleyin. Bunu otomatik başaşağı olarak yapabilirsiniz:

if(!ob_start("ob_gzhandler")) ob_start();

(evet, copression daha fazla CPU kullanır - ancak sunucuları çalışma ortamından daha hızlı çıkararak / daha az TCP paketini işleyerek ve ayrıca bir bonus olarak siteniz de daha hızlıdır.

MaxRequestsPerChild için bir üst sınır belirlemenizi tavsiye ederim - 500 gibi bir şey söyleyin. Bu, bir yere bellek sızıntısı olması durumunda süreçlerde biraz ciroya izin verir. Httpd işlemleriniz BÜYÜK görünüyor - ihtiyacınız olmayan apache modüllerini kaldırdığınızdan ve iyi önbellek bilgileri içeren statik içerik sunduğunuzdan emin olun.

Hala sorun görüyorsanız, sorun muhtemelen PHP kodundadır (fastCGI kullanmaya geçerseniz, bu önemli bir performans cezası olmadan açıkça görülmelidir).

Güncelleme

Statik içerik sayfalar arasında çok fazla farklılık göstermiyorsa, aşağıdakileri denemeye değer olabilir:

if (count($_COOKIE)) {
    header('Connection: close');
}

PHP betiklerinde de.

W durumunda bir dizi işlem de oldukça yüksek olduğundan, zaman uyumsuz bir ters proxy yüklemeyi düşünmelisiniz. Apache işlemleriniz, ağ üzerindeki engellenen ağ üzerinden yavaş istemcilere içerik göndermek için çok zaman harcıyor gibi görünüyor. Apache sunucunuzun ön ucu olarak Nginx veya lighttpd, W durumundaki bir dizi işlemi önemli ölçüde azaltabilir. Ve evet, bir dizi saklayıcı isteği sınırlamanız gerekir. Muhtemelen kaleci kapatmaya çalışmak önemlidir.

BTW, 107 Apache işlemleri 22 rps için çok yüksek, sadece 5 Apache işlemi kullanarak 100-120 rps sunabildim. Muhtemelen, bir sonraki adım başvurunuzu profillendirmektir.

Vmstat'ınızda CPU bekleme sürenizin oldukça yüksek olduğunu gösteren iki satır vardır ve bunların çevresinde, çok sayıda yazma (io - bo) ve bağlam değiştirme yaparsınız. Yazı bloklarının ne olduğuna ve bu bekleyişi nasıl ortadan kaldıracağına bakardım. En fazla gelişmenin disk IO'nuzu iyileştirmede bulunabileceğini düşünüyorum. Syslog'u kontrol et - zaman uyumsuz yazmaya ayarlayın. Denetleyicinizin yazma önbelleğinin çalıştığından emin olun (kontrol edin - zayıf bir piliniz olabilir).

Keepalive mükemmel sorununuza neden olmaz, önde bir önbellek çalıştırmıyorsanız bağlantı kurulumunda size zaman kazandırır. MaxSpareServers'ı biraz çarpabilirsiniz, böylece bir çıtırda tüm çatalları beklemezsiniz.

keepalive'ı ilk denemede kapatmayı düşünmelisin ...

107 istek işlendiğinde MaxSpareServers'ı ayarladığınızdan daha yüksek tutacağım ...

Statik içerik için ters proxy olarak uzun vadeli nginx'te IMHO dikkate alınmalıdır

İlk öneri: saklayıcıları devre dışı bırakın. Sadece performansın arttığı belirli bir durumu tanımlayabildiğimde ihtiyacım vardı, ancak genel istek / sn'de Keepalive etkinleştirildiğinde azaldı.

İkinci öneri: Bir MaxRequestsPerChild ayarlayın. Ben burada symcbean yankı, bir bellek sızıntısı durumunda süreç rollover yardımcı olacaktır. 500 iyi bir başlangıç ​​noktasıdır.

Üçüncü Öneri: MaxClients'ı artırın. Bunun için bir basketbol sahası hesaplaması (fiziksel bellek - httpd olmayan işlem tarafından kullanılan bellek) / her httpd işleminin boyutudur. Httpd'nin nasıl derlendiğine bağlı olarak, bu sayı 255'tir. Genel sunucularım için sistemleri tararken google / yahoo / MS ile uğraşmak için 250 kullanıyorum.

Dördüncü Öneri: MaxSpareServers'ı artırın: 4-5x MinSpareServers gibi bir şey.

Bu öneriler başarısız Baring, ben DB için ters proxy veya memcache ile yük dengeleme bakmak istiyorum.