Son zamanlarda SYN taşması nedeniyle çok yavaş yanıt veren bir apache sunucumuz vardı. Bunun için geçici çözüm, tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf) işlevini etkinleştirmekti .
Bu konuda bir soru önergesi burada daha arka plan istiyorum.
Senkronizasyonu etkinleştirdikten sonra, yaklaşık 60 saniyede bir / var / log / messages içinde şu mesajı görmeye başladık:
[84440.731929] possible SYN flooding on port 80. Sending cookies.
Vinko Vrsaloviç, bunun, senk backlog'unun dolduğu anlamına geldiğini söyledi, bu yüzden tcp_max_syn_backlog dosyasını 4096'ya yükselttim. Bir noktada tcp_synack_retries değerini 3'e indirerek (varsayılan 5'ten aşağı) verdim sysctl -w net.ipv4.tcp_synack_retries=3. Bunu yaptıktan sonra, mesajların aralığı yaklaşık 60 ila 180 saniye arasında değişen, frekans düşüyor gibiydi.
Sonra ben yayınladım sysctl -w net.ipv4.tcp_max_syn_backlog=65536, ancak hala kayıt defterinde mesajı alıyorum.
Tüm bunlar boyunca, SYN_RECV durumunda (çalışarak) bağlantıların sayısını izliyorum watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l've hiçbir zaman yaklaşık 240'dan fazla olmayacak, bu da backlog büyüklüğünden çok daha düşük olacaktır. Yine de 512 civarında dolanan bir Red Hat sunucum var (bu sunucudaki limit 1024 varsayılanıdır).
Biriktirme listesinin boyutunu sınırlayacak başka bir tcp ayarları var mı, yoksa yanlış ağaca havlıyor muyum? SYN_RECV bağlantılarının sayısı netstat -tuna, backlog büyüklüğü ile ilişkili mi?
Güncelleştirme
En iyisi, burada meşru bağlantılarla uğraştığımı söyleyebildiğim kadarıyla netstat -tuna|wc -l5000 civarında. Bu konuyu bugün araştırıyorum ve bu yazıyı oldukça faydalı olan bir son.fm çalışanından buldum .
Ayrıca tcp_max_syn_backlog'un eş anlamlı çerezler etkinken etkisinin olmadığını keşfettim ( bu bağlantıya göre )
Böylece bir sonraki adım olarak aşağıdakileri sysctl.conf dosyasına koydum:
net.ipv4.tcp_syn_retries = 3
# default=5
net.ipv4.tcp_synack_retries = 3
# default=5
net.ipv4.tcp_max_syn_backlog = 65536
# default=1024
net.core.wmem_max = 8388608
# default=124928
net.core.rmem_max = 8388608
# default=131071
net.core.somaxconn = 512
# default = 128
net.core.optmem_max = 81920
# default = 20480
Daha sonra cevap sysctl -ptestimi kurdum, koçluk yaptım ve devre dışı bıraktım sysctl -w net.ipv4.tcp_syncookies=0.
Bunu yaptıktan sonra, SYN_RECV durumundaki bağlantıların sayısı hala 220-250 civarında kalmıştır, ancak bağlantılar tekrar gecikmeye başlamıştır. Bu gecikmeleri farkettikten sonra, senkronizasyonları yeniden etkinleştirdim ve gecikmeler durdu.
Gördüğüm şeyin hala başlangıçtaki durumdan bir gelişme olduğuna inanıyorum, ancak bazı talepler hala ertelendi ve bu durum senkronizasyonu etkinleştirmekten çok daha kötü. Öyle görünüyor ki, yüklerle başa çıkabilmek için çevrimiçi olarak daha fazla sunucu alabilene kadar etkin durumdayım. O zaman bile, sunucunun arabellekleri dolduğunda yalnızca göründükleri gibi gönderildiklerinde onları tekrar devre dışı bırakmak için geçerli bir neden gördüğümden emin değilim.
Ancak syn backlog, SYN_RECV durumunda sadece ~ 250 bağlantıyla dolu görünmüyor! SYN sel mesajının kırmızı bir ringa balığı olması ve doldurulan syn_backlog dışında bir şey olması mümkün mü?
Herhangi birinin başka ayarlama seçeneği varsa, henüz denemediğim için denemekten çok mutlu olurum, ancak syn_backlog ayarının bir nedenden dolayı doğru uygulanıp uygulanmadığını merak etmeye başladım.