Kaç tane iplik çok fazla?

Bir sunucu yazıyorum ve istek alındığında her eylem ayrı bir iş parçacığına gönderirim. Hemen hemen her istek bir veritabanı sorgusu yapar çünkü bunu yapmak. Ben iş parçacığı inşaat / imha azaltmak için bir threadpool kütüphane kullanıyorum.

Sorum şu: G / Ç iş parçacıkları için iyi bir kesme noktası nedir? Bunun kaba bir tahmin olacağını biliyorum, ama yüzlerce mi konuşuyoruz? Binlerce?

Bu kesmenin ne olacağını nasıl anlayabilirim?

DÜZENLE:

Yanıtlarınız için hepinize teşekkür ederim, sadece iplik sayısı tavanımı bulmak için test etmek zorunda kalacağım gibi görünüyor. Soru şu: o tavana çarptığımı nasıl bilebilirim? Tam olarak neyi ölçmeliyim?

Bazı insanlar iki konu çok fazla olduğunu söyleyebilirim - Ben o kampta değilim :-)

İşte tavsiyem: ölçü, tahmin etme. Bir öneri yapılandırılabilir hale getirmek ve başlangıçta 100'e ayarlamak, daha sonra yazılımınızı wild'a bırakın ve ne olduğunu izlemek.

İplik kullanımınız 3'te zirve yapıyorsa, 100 çok fazladır. Günün çoğu için 100'de kalırsa, 200'e kadar çarpın ve ne olduğunu görün.

Sen olabilir aslında kendisi kullanımını izlemek ve onu başlar ama muhtemelen overkill sonraki sefer için yapılandırmayı ayarlamak için kodu var.

Açıklama ve detaylandırma için:

Kendi iş parçacığı havuzu alt sisteminizi haddeleme savunmuyorum, elbette sahip olduğunuz birini kullanın. Ancak, iş parçacıkları için iyi bir kesme noktası hakkında soruyorduğunuzdan, iş parçacığı havuzu uygulamanızın oluşturulan maksimum iş parçacığı sayısını (bu iyi bir şey) sınırlama yeteneğine sahip olduğunu varsayıyorum.

Ben iş parçacığı ve veritabanı bağlantısı havuz kodu yazdım ve (performans için gerekli olduğuna inanıyorum) aşağıdaki özelliklere sahip:

• minimum sayıda aktif iş parçacığı.
• maksimum iplik sayısı.
• bir süredir kullanılmayan dişleri kapatmak.

Birincisi, iş parçacığı havuzu istemcisi açısından minimum performans için bir taban çizgisi belirler (bu iş parçacığı sayısı her zaman kullanılabilir). İkincisi, aktif iş parçacıkları tarafından kaynak kullanımına bir kısıtlama getirir. Üçüncüsü, kaynak kullanımını en aza indirgemek için sessiz zamanlarda taban çizgisine geri döner.

Kullanılmayan iş parçacıklarına (A) sahip olmanın kaynak kullanımını, işi yapmak için yeterli iş parçacığına sahip olmamakla (B) kaynak kullanımını dengelemeniz gerekir.

(A) genellikle bellek kullanımıdır (yığınlar vb.) Çünkü iş yapmayan bir iş parçacığı CPU'nun çoğunu kullanmayacaktır. (B) genellikle bir iş parçacığının kullanılabilir olmasını beklemeniz gerektiğinden, isteklerin işlenmesinde gecikme olacaktır.

Bu yüzden ölçüyorsun. Belirttiğiniz gibi, iş parçacıklarınızın büyük çoğunluğu veritabanından yanıt bekler, böylece çalışmazlar. Kaç tane iş parçacığına izin vermeniz gerektiğini etkileyen iki faktör vardır.

Birincisi, kullanılabilir DB bağlantısı sayısıdır. DBMS'de artıramadığınız sürece bu zor bir sınır olabilir - DBMS'nizin bu durumda sınırsız sayıda bağlantı alabileceğini varsayacağım (ideal olarak bunu da ölçmelisiniz).

Daha sonra, sahip olmanız gereken iş parçacığı sayısı, tarihsel kullanımınıza bağlıdır. Çalıştırmanız gereken minimum sayı, mutlak minimum (örneğin, ve A gibi yapılandırılabilir hale getirin) ile şimdiye kadar çalıştırdığınız minimum + A% sayısıdır.

Maksimum iş parçacığı sayısı geçmiş maksimum +% B olmalıdır.

Ayrıca davranış değişikliklerini izliyor olmalısınız. Herhangi bir nedenle, kullanımınız önemli bir süre için kullanılabilir olanın% 100'üne giderse (böylece müşterilerin performansını etkileyecektir), bir kez daha% B daha yüksek olana kadar izin verilen maksimum değeri artırmalısınız.

"Tam olarak neyi ölçmeliyim?" soru:

Özel olarak ölçmeniz gereken şey, yük altında eşzamanlı kullanımdaki maksimum iş parçacığı miktarıdır (örneğin, DB çağrısından geri dönüşü beklemek). Daha sonra, örneğin % 10'luk bir güvenlik faktörü ekleyin (diğer posterler örneklerimi sabit öneriler olarak alıyor gibi göründüğünden).

Ayrıca, bu ayar için üretim ortamında yapılmalıdır. Önceden bir tahmin almak tamamdır, ancak hangi üretimin yolunuza çıkacağını asla bilemezsiniz (bu yüzden tüm bu şeyler çalışma zamanında yapılandırılabilir olmalıdır). Bu, gelen müşteri çağrılarının beklenmedik iki katına çıkması gibi bir durumu yakalamaktır.

Bu soru oldukça ayrıntılı bir şekilde tartışıldı ve tüm yanıtları okuma şansım olmadı. Ancak, belirli bir sistemde barış içinde birlikte bulunabilecek eşzamanlı iş parçacığı sayısının üst sınırına bakarken dikkate alınması gereken birkaç şey var.

1. İş Parçacığı Boyutu: Linux'ta varsayılan iş parçacığı yığın boyutu 8MB'dir (bunu bulmak için ulimit -a kullanabilirsiniz).
2. Max Belirli bir OS varyantının desteklediği sanal bellek. Linux Çekirdek 2.4, 2 GB bellek adres alanını destekler. Kernel 2.6 ile biraz daha büyüğüm (3GB)
3. [1], verilen Maksimum VM Desteklenen maksimum iş parçacığı sayısı hesaplamalarını gösterir. 2.4 için yaklaşık 255 iş parçacığı olduğu ortaya çıktı. 2.6 için bu sayı biraz daha büyük.
4. Ne tür bir çekirdek zamanlayıcı var. Linux 2.4 çekirdek zamanlayıcısını 2.6 ile karşılaştırdığınızda, daha sonra bir sistemde mevcut görevlerin sayısına bağımlı olmadan bir O (1) zamanlaması verirken, birincisi O (n) daha fazladır. Dolayısıyla, çekirdek çizelgesinin SMP Yetenekleri de bir sistemdeki maksimum sürdürülebilir iş parçacığı sayısında iyi bir rol oynamaktadır.

Artık yığın boyutunuzu daha fazla iş parçacığı içerecek şekilde ayarlayabilirsiniz, ancak daha sonra iş parçacığı yönetiminin ek yüklerini (oluşturma / imha ve zamanlama) dikkate almanız gerekir. CPU'lar arasındaki iş parçacığı taşıma yüklerinden kaçınmak ve soğuk nakit sorunlarından kaçınmak için belirli bir işlemin yanı sıra belirli bir iş parçacığına CPU benzeşimini zorlayabilirsiniz.

Kişinin kendi isteği doğrultusunda binlerce iş parçacığı oluşturabileceğini unutmayın, ancak Linux sanal makine tükendiğinde süreçleri rastgele (yani iş parçacıkları) öldürmeye başlar. Bu, yardımcı program profilinin maksimize edilmesini önlemek içindir. (Yardımcı program işlevi, belirli bir miktarda kaynak için sistem genelinde faydadan bahseder. Bu durumda sabit kaynaklarla CPU Döngüsü ve Bellek, yardımcı program eğrisi gittikçe daha fazla görevle düzleşir).

Windows çekirdek zamanlayıcı da kaynakların aşırı kullanımı ile başa çıkmak için bu tür bir şey yapar eminim

[1] http://adywicaksono.wordpress.com/2007/07/10/i-can-not-create-more-than-255-threads-on-linux-what-is-the-solutions/

İş parçacıklarınız herhangi bir kaynak yoğun çalışma (CPU / Disk) gerçekleştiriyorsa, nadiren bir veya ikiden fazla fayda görürsünüz ve çok fazla kişi performansı çok hızlı bir şekilde öldürür.

'En iyi durum', ilk iş parçacıkları tamamlandığında sonraki iş parçacıklarınızın durması veya bazılarının düşük çekişmeli kaynaklarda düşük genel bloklara sahip olmasıdır. En kötü durum, önbelleği / diski / ağı atmaya başlamanız ve genel veriminizin zeminden düşmesidir.

İyi bir çözüm, daha sonra bir iş parçacığı havuzundan çalışan iş parçacıklarına gönderilen (ve evet, sürekli iş parçacığı oluşturma / imhadan kaçınmak için harika bir ilk adımdır) bir havuzdaki istekleri yerleştirmektir.

Bu havuzdaki aktif iş parçacığı sayısı daha sonra profil oluşturma bulgularınız, üzerinde çalıştığınız donanım ve makinede oluşabilecek diğer şeylere bağlı olarak değiştirilebilir ve ölçeklendirilebilir.

Unutmamanız gereken bir şey, python'un (en azından C tabanlı sürüm) küresel bir tercüman kilidi kullanmasıdır çok çekirdekli makinelerde performans üzerinde büyük etkisi olabilecek kullanmasıdır.

Çok iş parçacıklı python'dan gerçekten en fazlasına ihtiyacınız varsa, Jython veya başka bir şey kullanmayı düşünebilirsiniz.

Pax'ın haklı olarak söylediği gibi ölçün, tahmin etmeyin . DNSwitness için yaptığım ve sonuçlar şaşırtıcıydı: İdeal iş parçacığı sayısı, düşündüğümden çok daha yüksekti, en hızlı sonuçları almak için 15.000 iş parçacığı gibi bir şey.

Tabii ki, birçok şeye bağlı, bu yüzden kendinizi ölçmelisiniz.

Kombien de fils d'exécution'da tam önlemler (sadece Fransızca) ? .

Çok sayıda çok iş parçacıklı uygulama yazdım. Genelde bir yapılandırma dosyası tarafından belirlenecek potansiyel iş parçacıklarının sayısına izin veririm. Belirli müşteriler için ayarladığımda, tüm CPU çekirdeklerini kullanımımın oldukça yüksek olduğunu, ancak bellek sorunlarıyla karşılaştığım kadar yüksek olmadığını belirledim (bunlar 32 bit işletim sistemiydi. zaman).

Başka bir deyişle, CPU, veritabanı verimi, disk verimi vb.Gibi bazı darboğazlara ulaştığınızda, daha fazla iş parçacığı eklemek genel performansı artırmayacaktır. Ama o noktaya gelene kadar daha fazla konu ekleyin!

Bunun, söz konusu sistemlerin uygulamanıza adanmış olduğunu ve diğer uygulamaların güzel bir şekilde (açlıktan kaçınmaktan) kaçınmanız gerekmediğini unutmayın.

"Büyük demir" yanıtı genellikle sınırlı kaynak başına bir iş parçacığıdır (işlemci (CPU bağlı), kol (G / Ç bağlı), vb.), Ancak bu yalnızca çalışmayı kaynağın doğru iş parçasına yönlendirebiliyorsanız çalışır erişilebilir.

Bunun mümkün olmadığı durumlarda, mantar kaynaklarınız (CPU'lar) ve mantar olmayan kaynaklarınız (silahlarınız) olduğunu düşünün. CPU'lar için, her bir iş parçacığını belirli bir CPU'ya atamak kritik öneme sahip değildir (önbellek yönetimine yardımcı olsa da), ancak kollar için, kola bir iplik atayamazsanız, kuyruk teorisine ve kolları tutmak için en uygun sayıya girersiniz. meşgul. Genel olarak, kullanılan kola dayalı istekleri yönlendiremezseniz, kol başına 2-3 ipliğin doğru olacağına inanıyorum.

İpliğe geçirilen iş birimi makul bir atomik iş yürütmediğinde bir komplikasyon ortaya çıkar. Örneğin, iş parçacığının bir noktada diske erişmesini, başka bir noktada ağda beklemesini sağlayabilirsiniz. Bu, ek dişlerin girebileceği ve faydalı işler yapabileceği "çatlak" sayısını arttırır, ancak ek dişlerin birbirlerinin önbelleklerini, vb. Kirletme ve sistemi bozma fırsatını da artırır.

Tabii ki, tüm bunları bir ipliğin "ağırlığına" karşı tartmalısınız. Ne yazık ki, çoğu sistem çok ağır dişlere sahiptir (ve "hafif iplikler" olarak adlandırdıkları şey genellikle diş değildir), bu nedenle düşük tarafta hata yapmak daha iyidir.

Pratikte gördüğüm şey, çok ince farkların kaç tane ipliğin optimal olduğu konusunda büyük bir fark yaratabileceğidir. Özellikle, önbellek sorunları ve kilit çakışmaları pratik eşzamanlılık miktarını büyük ölçüde sınırlayabilir.

Dikkate alınması gereken bir şey, kod üzerinde çalışacak makinede kaç tane çekirdek olduğudur. Bu, herhangi bir zamanda kaç iş parçacığının ilerleyebileceğine dair kesin bir sınırı temsil eder. Ancak, durumunuzda olduğu gibi, iş parçacıklarının sık sık bir veritabanının bir sorguyu yürütmesini beklemesi bekleniyorsa, büyük olasılıkla iş parçacığınızı veritabanının kaç eşzamanlı sorguyu işleyebileceğine göre ayarlamak istersiniz.

Bence bu soruya biraz sıyrılıyor, ama neden onları süreçlere ayırmıyorsun? Ağ kurma anlayışım (puslu günlerden beri, gerçekten ağları kodlamıyorum), gelen her bağlantının ayrı bir işlem olarak ele alınabileceğiydi, çünkü o zaman birisi işleminizde kötü bir şey yaparsa, tüm programı nuke.

ryeguy, şu anda benzer bir uygulama geliştiriyorum ve benim iş parçacığı sayısı 15 olarak ayarlanmış. Ne yazık ki 20'de artırırsanız, çöküyor. Yani, evet, bununla başa çıkmanın en iyi yolunun, mevcut yapılandırmanızın X sayısından daha fazla veya daha az iş parçacığına izin verip vermediğini ölçmektir.

Çoğu durumda, iş parçacığı havuzunun bunu işlemesine izin vermelisiniz. Bazı kodlar gönderirseniz veya daha fazla ayrıntı verirseniz, iş parçacığı havuzunun varsayılan davranışının en iyi olmamasının bir nedeni olup olmadığını görmek daha kolay olabilir.

Bunun nasıl çalışması gerektiği hakkında daha fazla bilgiyi burada bulabilirsiniz: http://en.wikipedia.org/wiki/Thread_pool_pattern

CPU çekirdeği kadar çok iş parçacığı çok sık duyduğum şeydir.