Soru HAProxy için Yüksek Tq değerleri


Yeni bir çevre yönetimi aldım. Bilinen bir konu, çevrenin yüksek tepki süreleriyle (20+ saniye) bilinmesidir, bu yüzden haproxy kayıtlarını açıp neler olup bittiğini anladım. Uygulama sunucularında yavaş yükleme süreleri görebileceğimi düşündüm, ancak aslında HAProxy'de yüksek Tq değerlerini görüyorum. HAProxy, EC2 üzerindedir ve ELB'nin arkasında DEĞİLDİR.

Sep  5 14:22:00 haproxy-apps01 haproxy[24695]: 76.14.153.221:3371 [05/Sep/2012:14:21:49.780] http-in default_apps/fe04-c 10936/0/0/55/10991 200 488 - - ---- 111/111/0/1/0 0/0 "GET /event_times/next?callback=jQuery170189312373075111_1346854917562&_=1346854918453 HTTP/1.1"

Gördüğünüz gibi, bu yaklaşık 10 saniye Tq değerine sahiptir. Tüm Tq'lar yüksek değil (1+ saniye), ancak iyi bir yüzdesi (yaklaşık% 35). Normalde, bu davranışı gördüğümde, ağ sorunları olmasını beklerdim, ancak bu, ziyaretçilerin inanılmaz derecede yüksek bir yüzdesini böyle bir sorunla karşı karşıya getiriyor, bu yüzden, herhangi birinin bunu görüp görmediğini veya teşhis edilmesi konusunda herhangi bir ipucu olduğunu merak ediyorum. Sorun bu kutuda olabilir mi?


6
2017-09-05 14:29


Menşei




Cevaplar:


Yüksek Tq zamanları her zaman bir problemin göstergesi değildir, http-server-close set?

Belgelere göre:

"Option http-server-close" ayarı daha büyük istek zamanları gösterebilir   "Tq" ayrıca ek için harcanan zamanı da ölçer   istekleri.

Örneğin, bu Yığın Taşması için ve bazı örnek veriler olarak, aşağıdaki sorgu için ayarlanır:

Select Top 20 Tq from LogsLastTwoDays WITH (NoLOCK) WHERE
CreationDate > DATEADD(minute, -5, GETUTCDATE()) AND 
ResponseCode = 200 AND Host = 'stackoverflow.com'
ORDER by Tq DESC

Verim:

Tq    
----- 
14990 
14987 
14986 
14983 
14974 
14972 
14972 
14965 
14964 
14964 
14962 
14961 
14960 
14955 
14952 
14951 
14945 
14943 
14935 
14932 

Çünkü http-server-close, bağlantı istemciye açık (kalıcı bağlantı) timeout http-keep-alive 15s çevremizde.

Genelde odaklanıyorum Tr İlk olarak, bu LB ve sunucu arasındaki yanıt süresini gösterir.


4
2017-09-05 14:33



Üzgünüm, belirtmeliydim. Hayır, http-server-close ayarlanmadı - Will
@Will: Tamam, bu başka birinin gelecekte aynı soruna sahip olması durumunda bırakacaktır. Benim tahminim o zaman bir ağ / kaynak problemidir. Dmesg'i ve tüm hayati kontrol ettin mi? Conntrack tablo doldurma vb ile ilgili bir sorun yok? - Kyle Brandt♦
Bir yan not olarak, günlükleri karşı sorgulamak için ne kullanıyorsunuz? - Will
@Will: UDP üzerinden syslog verilerini alan, bir regex ile ayrıştırılan ve MS SQL Server'a ekleyen bir hizmet yazdık. Her gün kendi masasını alır. - Kyle Brandt♦
Kaynak kodunu her yere gönderdin mi? Başka bir yere veri göndermek için değiştirmek isterim. - Will


Yapılandırmanızı bir yere yapıştırmanız yardımcı olabilir.

Bu, zaman aşımı yapılandırması ve HTTP moduna da bağlı olabilir. Kyle'ın bahsettiği gibi, önce http-sunucu-kapat seçeneği için oy kullanırdım. Bunu etkinleştirmediğiniz için yavaş bir lor gibi saldırıya maruz kalabilirsiniz.

Bir "timeout http-request" parametresini 5s'e kurabilir ve hala o satıra sahip olup olmadığınızı veya 408 yanıtıyla değiştirilip değiştirilmediğini görebilir misiniz?

şerefe


4
2017-09-05 15:21



Ağır loris saldırısında mükemmel video youtube.com/watch?v=XiFkyR35v2Y - Siddhartha