CPU tek boynuzlu at işlemi başına optimum sayıda

Unicorn altında Ruby on Rails web uygulamasını çalıştırıyoruz. Bizim app kesinlikle CPU bağlı değildir (12 çekirdekli bir çift Xeon E5645 sistemimiz var ve pik yük ortalama değeri 6 civarındadır). Başlangıçta 40 Unicorn çalışanıyla başladık, ancak uygulama belleği ayak izi zamanla arttı. Şimdi, işçi süreçlerinin sayısını azaltmalıyız. Standart (CPU çekirdek sayısı + 1) formülünün Unicorn için de geçerli olduğunu düşündüm, ancak meslektaşım beni CPU başına daha fazla Unicorn örneği ayırmamız gerektiğine ikna etmeye çalıştı ve bu bağlantıyı sağladı . Yine de, boştaki Unicorn süreçlerine neden bu kadar çok bellek harcamamız gerektiğinden tam olarak emin değilim.

Sorum şu: CPU çekirdeği başına birden fazla Unicorn örneğine sahip olmanın nedeni nedir? Unicorn'un bazı mimari özelliklerinden mi kaynaklanıyor? Meşgul Unicorn işlemlerinin yeni bağlantıları kabul edemediğinin farkındayım (Unicorn bulut sunucuları ile iletişim kurmak için UNIX etki alanı yuvalarını kullanıyoruz), ancak biriktirme işleminin tam olarak bunu ele almak için tanıtıldığını düşündüm. CPU kuralı başına bu 2 ila 8 Unicorn örneğinin üstesinden gelmek mümkün müdür?

Tamam, sonunda cevabı buldum. Unicorn çalışanlarının optimum sayısı doğrudan CPU çekirdeği sayısına bağlı değildir, yükünüze ve dahili uygulama yapısına / yanıt verebilirliğine bağlıdır. Temelde biz işçi durumunu belirlemek için örnekleme profiler kullanın, biz işlerini% 70 boşta ve% 30 gerçek işi yapmaya çalışıyoruz. Bu nedenle, örneklerin% 70'i "ön uç sunucusundan istek almak için select () çağrısında bekliyor" olmalıdır. Araştırmamız, çalışanların sadece 3 etkili durumu olduğunu göstermiştir: Örneklerin% 0-30'u boş, örneklerin% 30-50'si boş ve örneklerin% 50-70'i boş (evet, daha boş örnekleri alabiliriz ama orada bunun gerçek bir noktası yoktur çünkü uygulama duyarlılığı önemli ölçüde değişmez). Biz% 0-30 durumu "kırmızı bölge" ve% 30-50 durumu "sarı bölge" olarak değerlendiriyoruz.

CPU bağlantılı işler için N + 1 konusunda haklısınız.

Öte yandan, tek boynuzlu at iplik kullanmaz, bu yüzden her IO op. işlemi engeller ve başka bir işlem HTTP üstbilgilerini ayrıştırabilir ve ayrıştırabilir, dizeleri birleştirebilir ve kullanıcıya sunmak için gereken her CPU-yoğun görevi gerçekleştirebilir (istek gecikmesini azaltmak için daha önce yapar).

Ve çekirdeklerden daha fazla iş parçacığına / işleme sahip olmak isteyebilirsiniz. Şu durumu hayal edin: req. A, talepten on kat daha fazla zaman alır. B, birkaç eşzamanlı A isteğiniz var ve hızlı B isteği A-req'in tamamlanmasını beklemek üzere kuyruğa alındı. Bu nedenle, ağır isteklerin sayısını tahmin edebiliyorsanız, bu sayıyı sistemi ayarlamak için başka bir kılavuz olarak kullanabilirsiniz.