Nginx worker_connections", bir çalışan işlem tarafından açılabilecek maksimum eşzamanlı bağlantı sayısını belirler. Bu sayı, yalnızca istemcilerle olan bağlantıları değil, tüm bağlantıları (örn. Proxy sunucularıyla yapılan bağlantılar) içerir. maksimum açık dosya sayısındaki geçerli sınırı geçemez ". Bununla ilgili birkaç sorum var:

1. Bunun için en uygun veya önerilen değer ne olmalıdır?
2. Çok sayıda işçi bağlantısı kullanmanın olumsuz yanları nelerdir?

Pragmatik yaklaşımı ele alalım.

Tüm bu sınırlar, donanımın yavaş ve pahalı olduğu geçen yüzyılda kodlanmış ve tasarlanmış şeylerdir. Şimdi 2016’dayız, ortalama bir duvar tost makinesi varsayılan değerlerden daha fazla istek işleyebilir.

Varsayılan ayarlar aslında tehlikelidir. Bir web sitesinde yüzlerce kullanıcıya sahip olmak etkileyici bir şey değildir.

worker_process

İlgili bir ayar, konuyu açıklarken açıklayalım.

Yük dengeleyici olarak nginx:

• HTTP yük dengelemesi için 1 işçi.
• HTTPS yük dengelemesi için çekirdek başına 1 işçi.

web sunucusu olarak nginx:

Bu çok zor.

Bazı uygulamalar / çerçeveler / ara katman yazılımları (örneğin php-fpm) nginx dışında çalıştırılır. Bu durumda, 1 nginx çalışanı yeterlidir, çünkü bu genellikle ağır işlem yapan ve kaynakları yiyen harici bir uygulamadır.

Ayrıca, bazı uygulamalar / çerçeveler / ara katman yazılımı bir kerede yalnızca bir isteği işleyebilir ve aşırı yüklemeyi geri teptirir.

Genel olarak konuşursak, 1 işçi her zaman güvenli bir bahistir.

Aksi takdirde, ne yaptığınızı biliyorsanız, çekirdek başına bir işçi koyabilirsiniz. Bu rotanın bir optimizasyon olduğunu ve uygun kıyaslama ve test önerileri olduğunu düşünüyorum.

worker_connections

Toplam bağlantı miktarı worker_process * worker_connections. Yük dengeleyici modunda yarı.

Şimdi tost makinesine geliyoruz. Çok ciddi olarak underrated sistem sınırları vardır:

• ulimits, Linux üzerinde işlem başına 1k maksimum açık dosyadır (1k yumuşak, bazı dağıtımlarda 4k zor)
• systemd limitleri ulimits ile aynıdır.
• nginx varsayılanı, çalışan başına 512 bağlantıdır.
• Daha fazlası olabilir: SELinux, sysctl, supervisord (her dağıtım + sürümü biraz farklıdır)

1k worker_connections

Güvenli varsayılan, her yere 1k koymaktır.

Çoğu iç ve bilinmeyen sitenin karşılaşabileceğinden çok daha fazlası olacak kadar yüksek. Başka herhangi bir sistem sınırına ulaşmayacak kadar düşük.

10 bin işçi

Özellikle halka açık bir web sitesi için binlerce müşteriye sahip olmak çok yaygındır. Gördüğüm web sitelerinin sayısının düşük varsayılanlar nedeniyle azaldığını gördüm.

Üretim için kabul edilebilir minimum 10k. İzin vermek için ilgili sistem limitleri arttırılmalıdır.

Çok yüksek bir limit diye bir şey yoktur (kullanıcı yoksa bir limitin etkisi yoktur). Ancak, çok düşük bir limit, reddedilen kullanıcılar ve ölü bir site ile sonuçlanan çok gerçek bir şeydir.

10 bin'den fazla

10k güzel ve kolaydır.

İsteğe bağlı 1000k limitleri belirleyebiliriz (sonuçta bu yalnızca bir sınırdır) ancak bu çok pratik bir anlam ifade etmiyor, bu trafiği asla elde edemeyiz ve yine de üstesinden gelemedik.

Makul bir ayar olarak 10k'ya sadık kalalım. Daha fazlası için hizmet veren (ve gerçekten yapabilen) hizmetler özel ayar ve kıyaslama gerektirecektir.

Özel Senaryo: Gelişmiş Kullanım

Bazen, sunucunun çok fazla kaynağı olmadığını biliyoruz ve çok fazla şey yapamayacağımıza dair çiviler bekliyoruz. Denemek yerine kullanıcıları reddetmeyi tercih ediyoruz. Bu durumda, makul bir bağlantı limiti koyun ve güzel hata mesajlarını ve işlemeyi yapılandırın.

Bazen, arka uç sunucuları iyi ve iyi çalışıyor, ancak yalnızca bir miktar yüke kadar , daha fazlasını ve her şey hızla güneye gidiyor. Sunucuları çökertmek yerine yavaşlamak istiyoruz. Bu durumda, kuyruğu sıkı limitlerle yapılandırın, istekler sınırlandırılmış bir hızda boşaltılırken nginx'in tüm ısıyı tamponlamasını sağlayın.

ulimit -a sisteminizde bir işlemin kaç tane açık dosya kullandığını size söyleyecektir.

Ayrıca, net.ipv4.ip_local_port_rangeIP başına etkinleştirilecek toplam yuva aralığını ayarlar.

Bu nedenle, worker_connectionsbunlardan hiçbirinden daha fazlası olamazsınız veya istemci bağlantılarınız net.core.netdev_max_backlogTCP sırasının toplam boyutuna kadar sıraya girer.

Nginx'i ters vekil olarak kullanıyorsanız, bağlantı başına iki soket kullandığını unutmayın. net.ipv4.tcp_fin_timeoutPrizlerin durumunu hızlı bir şekilde değiştirmeye çalışmak için biraz ve biraz da çekirdek tcp ile ilgili zaman aşımına uğramak isteyebilirsiniz. Dikkat edilmesi gereken bir başka şey de, her bir soketin TCP bellek yığınının belleğini ayırmasıdır, ayrıca kullanarak TCP bellek yığınının bazı sınırlarını da ayarlayabilirsiniz sysctl, CPU ve yeterli dosya işleyiciniz olduğu sürece RAM'e daha fazla baskı uygulayabilirsiniz.

Bilginize, yeterli hesaplama kaynaklarına sahip olmak, 32GB ram'a sahip bir sunucuya ve sysctl kullanarak bazı çekirdek ayarlarıyla 1MM eşzamanlı bağlantıları yönetmek için bazı sanal ağ arayüzlerine sahip olmak mümkündür. Testlerim sırasında 1MM'den fazla olan ve yaklaşık 700Byte'lık bir veri yükü gönderirken, sunucunun yaklaşık 1.2MM eşzamanlı istemciyi güncellemesi yaklaşık 10 saniye sürdü. Daha sonra, bazı ekstra NIC'leri bağlayarak ve sanal nics'i keserek ağ bant genişliğini artıracaktı. Tüm müşterileri güncellemek için yük, bant genişliği ve makul süre göz önüne alındığında, 1.2 MM'den fazla müşteriyle gerçek zamanlıya yakın iletişim kurmak mümkün.

Mutlu ayar!

Uygun boyutlandırma, test yoluyla keşfedilebilir, çünkü Nginx'in işlediği trafik türüne bağlı olarak değişkendir.

Teorik olarak, nginx işleyebilir: max clients = worker_processes * worker_connections (* = çarpma) ve worker_processes = işlemci sayısı

İşlemcileri bulmak için şunu kullanın: grep processor / proc / cpuinfo | wc -l

Alt sınırların ayarlanması, kaynak kısıtlı olduğunuzda faydalı olabilir. Bazı bağlantılar, örneğin, canlı tutma bağlantıları (yalnızca istemcilerle değil , yukarı akış sunucularıyla da), kaynaklarınızı etkin bir şekilde boşa harcıyorsunuz (nginx çok verimli olsa bile) ve bunlar için gerekli değil Genel amaçlı bir sunucunun doğru çalışması, işlemin geri kalanında daha fazla kaynak sağlamak için güvenle bırakılabileceği anlamına gelir.

Daha düşük bir kaynak sınırına sahip olmak, nginx'e fiziksel kaynaklarda düşük olabileceğinizi gösterir ve mevcut olanların, bağlantı kurmakta güçlük çeken yeni bağlantılar pahasına boşta kalan canlı bağlantıları sürdürmek yerine yeni bağlantılara tahsis edilmesi gerektiğini gösterir. daha acil ihtiyaçlara hizmet eder.

Önerilen değer nedir? Bu varsayılan.

Varsayılan ayarların tümü belgelerde belgelenmiştir:

Varsayılan: worker_connections 512;

Ve edilebilir en kaynak kodu düzeyde teyitevent/ngx_event.c de

13 # DEFAULT_CONNECTIONS 512 tanımla

Marcel'in cevabının gerçekten iyileştirilmesi gerekiyor! Eğer ulimits'ler varsayılan olarak 1k civarında bir değere ayarlanırsa, max_connections aynı değere ayarlanmalıdır, aksi takdirde max_connections 10k olarak ayarlanmasının faydası yoktur.

"Worker_connections bağlantınız bunlardan daha fazla olamazsa veya müşteri bağlantılarınız net.core.netdev_max_backlog - TCP sırasının toplam büyüklüğü kadar" sıraya girerse, sıraya girme isteği ve yuvalar nginx'te kapatılır.

Ulimitlerin izin verdiği ölçüde bağlantı kurabildiği gibi tek bir işlem açılabilir. num_workers * max_connections formüldür, ancak dış yük dengeleyici / proxy max bağlantıları ve ulimitslerin makul değerler için dikkate alınması gerekir. Max_connection değerini gerçekten yüksek bir değere ayarlamak ulimits sınırlayıcı bir faktör olacağından geri tepebilir.