Apache performansı ~ 256 eşzamanlı isteğin çok üzerinde düşer


14

Site güncellemesini takiben haftada bir kez ziyaretçilerde büyük bir artış yaşayan nispeten düşük trafikli bir site çalıştırıyorum. Bu artış sırasında, site performansı haftanın geri kalanına kıyasla son derece zayıf. Sunuculardaki gerçek yük çok düşük, güvenilir olarak% 10 CPU ve% 30 RAM'in altında kalıyor (donanım aslında yaptığımız şey için tam bir overkill olmalı), ancak bir nedenle Apache miktarla baş edemiyor gibi görünüyor isteklerin. RHEL 5.7, çekirdek 2.6.18-274.7.1.el5, x86_64 üzerinde apache 2.2.3 çalıştırıyoruz.

Bu davranışı ab ile çalışma saatleri dışında yeniden oluşturmaya çalışırken, yaklaşık 256 kullanıcıyı aşarken performansta büyük bir düşüş görüyorum. Sınava gelebildiğim en küçük kullanım örneğiyle (statik metin dosyası alınıyor, toplamda 223 bayt) performans çalıştırmak, 245 eşzamanlı istekle sürekli olarak normaldir:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       15   25   5.8     24      37
Processing:    15   65  22.9     76      96
Waiting:       15   64  23.0     76      96
Total:         30   90  27.4    100     125

Percentage of the requests served within a certain time (ms)
  50%    100
  66%    108
  75%    111
  80%    113
  90%    118
  95%    120
  98%    122
  99%    123
 100%    125 (longest request)

Ancak 265'e kadar eşzamanlı isteği cırcırla çevirdiğimde, bir alt kümesinin tamamlanması saçma bir zaman almaya başlar:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       13  195 692.6     26    3028
Processing:    15   65  21.3     72     100
Waiting:       15   65  21.3     71      99
Total:         32  260 681.7    101    3058

Percentage of the requests served within a certain time (ms)
  50%    101
  66%    108
  75%    112
  80%    116
  90%    121
  95%   3028
  98%   3040
  99%   3044
 100%   3058 (longest request)

Bu sonuçlar çoklu çalışmalarda çok tutarlıdır. Bu kutuya giden başka bir trafik olduğundan, eğer varsa, zor kesimin nerede olacağından emin değilim, ancak şüphesiz 256'ya yakın görünüyor.

Doğal olarak, bunun preforktaki iplik sınırından kaynaklandığını varsaydım, bu yüzden devam ettim ve mevcut iş parçacıklarının sayısını iki katına çıkarmak ve iş parçacığı havuzunun gereksiz yere büyümesini ve küçülmesini önlemek için yapılandırmayı ayarladım:

<IfModule prefork.c>
StartServers     512
MinSpareServers  512
MaxSpareServers  512
ServerLimit      512
MaxClients       512
MaxRequestsPerChild  5000
</IfModule>

mod_status artık 512 kullanılabilir iş parçacığıyla çalıştığımı onaylıyor

8 requests currently being processed, 504 idle workers

Bununla birlikte, 265 eşzamanlı istekte bulunmaya çalışmak, daha önce neredeyse aynı sonuçları verir.

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       25  211 714.7     31    3034
Processing:    17   94  28.6    103     138
Waiting:       17   93  28.5    103     138
Total:         57  306 700.8    138    3071

Percentage of the requests served within a certain time (ms)
  50%    138
  66%    145
  75%    150
  80%    161
  90%    167
  95%   3066
  98%   3068
  99%   3068
 100%   3071 (longest request)

Dokümanları (ve Stack Exchange) inceledikten sonra, bu darboğazın üstesinden gelmeye çalışmak için daha fazla yapılandırma ayarının kaybına uğradım. Kaçırdığım bir şey var mı? Apache dışında cevap aramaya başlamalı mıyım? Başka kimse bu davranışı gördü mü? Herhangi bir yardım büyük mutluluk duyacağız.

DÜZENLE:

Ladadadada'nın tavsiyesine göre apache'ye karşı koştum. -Tt ve -T ile birkaç kez denedim ve sıradan bir şey bulamadım. Daha sonra şu anda çalışan tüm apache işlemlerine karşı strace -c çalıştırmayı denedim ve bunu aldım:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 22.09    0.317836           5     62128      4833 open
 19.91    0.286388           4     65374      1896 lstat
 13.06    0.187854           0    407433           pread
 10.70    0.153862           6     27076           semop
  7.88    0.113343           3     38598           poll
  6.86    0.098694           1    100954     14380 read

(... abdridged)

Bu hakkı okuyorsam (ve sık sık kullanmıyorum gibi benimle taşıyorsam), sistem çağrılarının hiçbiri bu isteklerin aldığı süreyi açıklayamaz. Neredeyse darboğaz, talepler işçi iş parçacıklarına ulaşmadan gerçekleşiyor gibi görünüyor.

DÜZENLEME 2:

Birkaç kişinin önerdiği gibi, testi tekrar web sunucusunda yürüttüm (daha önce test tarafsız bir internet konumundan çalıştırıldı). Sonuçlar şaşırtıcıydı:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   11   6.6     12      21
Processing:     5  247 971.0     10    4204
Waiting:        3  245 971.3      7    4204
Total:         16  259 973.3     21    4225

Percentage of the requests served within a certain time (ms)
  50%     21
  66%     23
  75%     24
  80%     24
  90%     26
  95%   4225
  98%   4225
  99%   4225
 100%   4225 (longest request)

Sonuç olarak internet tabanlı teste benzer, ancak yerel olarak çalıştırıldığında sürekli olarak biraz daha kötü görünüyor . Daha ilginç olarak, profil önemli ölçüde değişti. Halbuki uzun süredir devam eden taleplerin büyük bir kısmı “bağlan” için harcanmadan önce, şimdi darboğaz işleniyor ya da bekliyor gibi görünüyor. Bunun aslında daha önce ağ sınırlamaları tarafından maskelenen ayrı bir sorun olabileceğinden şüpheleniyorum.

Testi tekrar Apache ana bilgisayarıyla aynı yerel ağdaki başka bir makineden çalıştırdığımda çok daha makul sonuçlar görüyorum:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.8      2       4
Processing:    13  118  99.8    205     222
Waiting:       13  118  99.7    204     222
Total:         15  121  99.7    207     225

Percentage of the requests served within a certain time (ms)
  50%    207
  66%    219
  75%    220
  80%    221
  90%    222
  95%    224
  98%    224
  99%    225
 100%    225 (longest request)

Bu iki test birlikte bir dizi soruyu gündeme getirmektedir, ancak bundan ayrı olarak, artık belirli bir yük altında gerçekleşen bir tür ciddi ağ darboğazının yapılması için zorlayıcı bir durum söz konusudur. Sonraki adımların ağ katmanını ayrı ayrı araştıracağını düşünüyorum.


Dikkate alınacak seçenekler: CloudFlare, drupal.org/project/boost , CDN, Vernik önbellek.
ceejayoz

HTTP isteklerini sunmanın yanı sıra bu sunucunun ne yaptığına (gerçek dünya) ilişkin hiçbir şey söylemiyorsunuz. İlgili bir veritabanı (veya kilit çekişmesinden muzdarip olabilecek başka bir ortak kaynak) var mı? Sorun, TAMAMEN 256 istekte ( 255'te Tamam) aniden ortaya çıkarsa, muhtemelen bazı dış kaynaklar sular altında kalır. (Statik bir sayfa sunan sıçramanız da kesinlikle anormal - orada bazı hata ayıklama ipuçları için Ladadadada'nın cevabına bakın)
voretaq7

ceejayoz: Önerileri takdir ediyorum, ama temelde Apache'nin bu kadar yavaş olmaması gerektiğine inanıyorum. Sorunun etkisini azaltmak için yapabileceğimiz birçok şey var, ama bunu düzeltmeyi veya en azından anlamayı çok isterim.
cmckendry

voretaq7: Tipik bir istek php / mysql de içereceğinden başlangıçta aynı satırlar boyunca düşünüyordum, ancak tamamen statik içerik sunarken bile aynı eşikte sorun devam ediyor.
cmckendry

1
Bu gerçek bir sunucu mu yoksa VM mi? Testinizi localhost, yerel ağ veya Internet'ten yapıyor musunuz? 100 ms aralıktaki minimum tepki süreleri İnternet'ten yapılan testleri önerir. Localhost'tan test etmeye çalışın - belki sağlayıcınız sizi kısıyor.
Tometzky

Yanıtlar:


4

Bu durumda ne yapacağım

strace -f -p <PID> -tt -T -s 500 -o trace.txt

Yavaş yanıtlardan birini yakalayana kadar ab testi sırasında Apache işlemlerinizden birinde. Sonra bir göz atın trace.txt.

-ttVe -Tseçenekler yavaş olanları belirlemek yardımına başlangıç ve her sistem çağrı süresinin zaman damgalarını verir.

Veya gibi tek bir yavaş sistem çağrısı bulabilirsiniz open()ya stat()da poll()hemen ardından (muhtemelen birden çok) çağrı ile hızlı bir çağrı bulabilirsiniz . Bir dosya veya ağ bağlantısı üzerinde çalışan birini bulursanız (büyük olasılıkla), o dosyayı veya bağlantı tanıtıcısını bulana kadar iz boyunca geriye doğru bakın. Aynı tutamaçtaki önceki aramalar, ne poll()beklediğine dair bir fikir vermelidir .


Seçeneğe bakmak iyi fikir -c. İzlediğiniz Apache çocuğunun bu süre zarfında yavaş isteklerden en az birine hizmet etmesini sağladınız mı? (Bunu stracetüm çocuklarda aynı anda koşmak dışında nasıl yapacağınızdan bile emin değilim .)

Ne yazık ki, stracebize çalışan bir programın ne yaptığının tam bir resmini vermiyor. Yalnızca sistem çağrılarını izler. Bir programın içinde çekirdeğin herhangi bir şey istemesini gerektirmeyen çok şey olabilir. Bunun olup olmadığını anlamak için, her sistem çağrısının başlangıcındaki zaman damgalarına bakabilirsiniz. Önemli boşluklar görüyorsanız, zamanın gittiği yer burasıdır. Bu kolayca geçilemez ve yine de sistem çağrıları arasında her zaman küçük boşluklar vardır.

CPU kullanımının düşük kaldığını söylediğiniz için, muhtemelen sistem çağrıları arasında aşırı bir şey olmuyor, ancak kontrol etmeye değer.


Şu çıktıya daha yakından bakmak ab:

Tepki sürelerindeki ani sıçrama (150ms ve 3000ms arasında hiçbir yerde tepki süreleri yok gibi görünüyor), 256 eşzamanlı bağlantının üzerinde tetiklenen bir yerde belirli bir zaman aşımı olduğunu gösteriyor. RAM veya CPU döngüleri normal GÇ bitiyorsa daha yumuşak bir bozulma beklenir.

İkincisi, yavaş abyanıt, 3000ms'nin connectfazda harcandığını gösterir . Neredeyse hepsi 30ms civarındaydı, ancak% 5'i 3000ms aldı. Bu, ağın sorun olduğunu gösterir.

Nereye çalışan abden? Apache makinesiyle aynı ağdan deneyebilir misiniz?

Daha fazla veri tcpdumpiçin bağlantının her iki ucunda da çalışmayı deneyin (tercihen ntpher iki ucunda da çalışarak iki görüntüyü senkronize edebilirsiniz.) Ve tcp yeniden iletimlerini arayın. Wireshark, çöplükleri analiz etmek için özellikle iyidir, çünkü tcp yeniden iletimlerini farklı bir renkte vurgular, bu da onları bulmayı kolaylaştırır.

Ayrıca, erişiminiz olan tüm ağ cihazlarının günlüklerine bakmaya değer olabilir. Son zamanlarda kb / s cinsinden bant genişliğini ele alabileceği güvenlik duvarlarımızdan biriyle ilgili bir sorunla karşılaştım, ancak aldığı saniyedeki paket sayısını işleyemedi. Saniyede 140.000 paket çıktı. Koşunuzdaki bazı hızlı matematik, absaniyede yaklaşık 13.000 paket göreceğinize inanmamı sağlıyor (yavaş isteklerin% 5'ini yok sayıyor). Belki bu ulaştığınız darboğazdır. Bunun 256 civarında gerçekleşmesi tamamen tesadüf olabilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.