İçeriğe geç

Kaynak yönetimi

Markdown olarak görüntüle GitHub üzerinde düzenle Dokümantasyon: 2cc7b2b

Queuety, kaynak denetimini dört temel katmana ve bunların üzerine eklenen isteğe bağlı havuz boyutlandırmasına ayırır.

İlk katman, bir iş biriminin ne kadar maliyetli olduğunu açıklar. İkinci katman, bir kuyruğun veya sağlayıcı grubunun aynı anda taşıyabileceği paylaşılan yükü sınırlar. Üçüncü katman, tek bir iş akışı çalıştırmasının ne kadar tüketebileceğini belirler. Dördüncü katman ise bir işçinin aldığı sonraki işi hemen başlatması mı yoksa geçerli süreç ve kapsayıcıda yeterli kaynak kalana kadar ertelemesi mi gerektiğine karar verir.

Bu katmanlar birlikte çalışır. Bir işleyici, maliyetli bir paylaşılan havuza ait olduğunu belirtebilir; bir kuyruk, tek bir sağlayıcı için yalnızca belirli miktarda ağırlıklı iş ayırabilir; bir iş akışı, oluşturacağı bu tür işlerin miktarını sınırlayabilir. İşçi de geçerli süreç veya kapsayıcı zaten sınırlarına çok yaklaşmışsa bu işlerden daha fazlasını başlatmayı reddedebilir.

Bir iş biriminin maliyetini tanımlayın

İşler, iş akışı adımları ve durum girişi eylemleri aynı üç kaynak ipucunu yayımlayabilir:

  • concurrency_group
  • concurrency_limit
  • cost_units

concurrency_group ve concurrency_limit, aynı alt sistem üzerindeki paylaşılan yükü tanımlar. Birden fazla işleyici aynı sağlayıcıya, API hesabına veya kiracıya istek gönderiyorsa işçiler aynı anda çok fazla iş başlatmasın diye aynı grubu kullanabilirler.

cost_units, göreli ağırlığı tanımlar. Önbellek yenilemesiyle sağlayıcıya yapılan büyük bir çağrı da “bir iş” sayılabilir; ancak bir iş akışı bütçesi veya işçi kabul kuralı daha fazla işin güvenli olup olmadığına karar verirken bunlara eşit ağırlık verilmemelidir.

PHP
final class CallProviderStep implements \Queuety\Step
{
    public function handle( array $state ): array
    {
        // ...
    }

    public function config(): array
    {
        return [
            'concurrency_group' => 'providers',
            'concurrency_limit' => 3,
            'cost_units' => 5,
        ];
    }
}

Aynı fikir, sınıf özellikleri üzerinden dağıtılabilir işler ve PendingJob::concurrency_group() ile PendingJob::cost_units() aracılığıyla tek tek dağıtımlar için de geçerlidir.

Paylaşılan kuyruklar ve sağlayıcı grupları için bütçe belirleyin

Paylaşılan yük her zaman basit bir eşzamanlılık sayısıyla ilgili değildir. Bazen maliyetli olan, hâlihazırda çalışan işlerin toplam ağırlığıdır.

Queuety bunu ağırlıklı kuyruk ve grup bütçeleriyle destekler. Kuyruk bütçeleri kuyruk adına göre belirlenir. Grup bütçeleri ise concurrency_group ile belirlenir; böylece ilgisiz işleyiciler aynı paylaşılan kapsama dahil olabilir.

PHP
define( 'QUEUETY_RESOURCE_QUEUE_COST_BUDGETS', [
    'providers' => 20,
    'exports' => 8,
] );

define( 'QUEUETY_RESOURCE_GROUP_COST_BUDGETS', [
    'openai' => 12,
    'tenant:acme' => 6,
] );

Bir işçi bir işi aldığında, o kuyruğa veya gruba ait etkin processing satırlarını inceler. O anda çalışan işlerin maliyetiyle alınan işin cost_units maliyetinin toplamı yapılandırılan bütçeyi aşacaksa işçi işi serbest bırakır ve daha sonra yeniden dener.

Bu, concurrency_limit'dan farklı bir denetim sağlar. Bir sağlayıcı aynı anda üç isteğe izin verebilir, ancak büyük istekler için küçük isteklere kıyasla toplam maliyet birimlerinden daha azını ayırabilir.

Tek bir iş akışını belirlenen sınırlar içinde tutun

İş akışı bütçeleri, sorunun tek bir ağır iş olmadığı; bir çalıştırmanın amaçlanandan fazla iş keşfetmeye devam ettiği durumlar içindir.

Bu durum aracı sistemlerde yaygındır. Bir planlayıcı aynı maliyetli dalı yeniden ziyaret edebilir, çok fazla alt göreve ayrılabilir veya normal bir yeniden deneme modelinin sınırları içinde kalırken alt iş akışları başlatmaya devam edebilir.

Queuety bunun için iş akışı düzeyinde sınırlar sunar:

PHP
Queuety::workflow( 'research_run' )
    ->max_transitions( 20 )
    ->max_for_each_items( 12 )
    ->max_state_bytes( 32768 )
    ->max_cost_units( 40 )
    ->max_started_workflows( 8 )
    ->then( PlanResearchStep::class )
    ->for_each( 'tasks', ExecuteResearchTask::class, 'results' )
    ->dispatch();

max_cost_units(), çalıştırmanın amaçlanandan fazla ağırlıklı iş tüketmesini önler. max_started_workflows(), bir üst öğenin sınırsız sayıda üst düzey alt çalıştırmadan oluşan bir ağaç oluşturmasını engeller. Denetim önlemlerinin geri kalanı da önemlidir; çünkü kontrolden çıkan her iş akışı aynı biçimde maliyetli değildir.

İş akışı durumu, yapılandırılmış sınırları ve geçerli kullanımı herkese açık budget yükünde gösterir; böylece sınırlar etkin olduğu sürece çalıştırma incelenebilir.

İşlem zaten çok yoğunsa çalışanların işleri ertelemesine izin verin

Meta veri ve iş akışı bütçeleri iyi yapılandırılmış olsa bile son karar, işi yürütmek üzere olan çalışan sürece aittir.

Kaynakları dikkate alan kabul mekanizması burada devreye girer. Talep edilen bir iş başlamadan önce Queuety şunları inceleyebilir:

  • işin paylaşılan eşzamanlılık grubu
  • ağırlıklı kuyruk ve sağlayıcı grubu bütçeleri
  • işleyiciye ait yakın dönem süre ve tepe bellek kullanımı geçmişi
  • mevcut çalışanın kalan bellek payı
  • mevcut kapsayıcı veya ana makinenin kalan bellek payı
  • tek seferlik tarzda çalıştırmalar için kalan süre aralığı

Çalışan yapılandırılmış sınırına zaten fazla yaklaştıysa Queuety, sorunsuz tamamlanması pek olası olmayan bir işi başlatmak yerine işi serbest bırakır.

Bu yaklaşım bilerek temkinlidir. Tam kapsamlı bir küme zamanlayıcısı değildir. Yoğun bir çalışanın, çalıştığı sürecin kapasitesini aşırı kullanmasını ve bellek ölçümleri mevcut olduğunda çevresindeki kapsayıcı veya ana makinenin kapasitesini aşmasını önlemeye yardımcı olan bir güvenlik katmanıdır.

Kapsayıcı veya ana makine denetimi isteğe bağlıdır. QUEUETY_RESOURCE_SYSTEM_MEMORY_AWARENESS etkinleştirildiğinde Queuety önce cgroup bellek verilerini okumayı dener, Linux ana makinelerde ise /proc/meminfo kullanımına geri döner. Güvenilir bir sistem düzeyi anlık görüntü yoksa çalışan, süreç düzeyindeki denetimleri kullanmayı sürdürür.

Kapasiteyi göz ardı etmeden çalışan havuzlarını ölçeklendirin

Sabit çalışan havuzlarını anlamak kolaydır, ancak sakin dönemler ve ani yoğunluklar için aynı sayıyı seçmenizi gerektirirler.

Uyarlanabilir havuzlar bunun yerine bir alt ve üst sınır belirlemenizi sağlar:

Kabuk
wp queuety work --queue=providers --min-workers=2 --max-workers=6

Üst süreç en az asgari sayıda alt süreci çalışır durumda tutar, talep edilebilir birikmiş işler arttığında azami sayıya doğru büyür ve kuyruk yapılandırılmış boşta kalma tolerans süresi boyunca sessiz kaldıktan sonra küçülür.

Ölçeği büyütme işlemi kullanılabilir kapasiteyi yine dikkate alır. Sistem belleğini izleme etkinse ve üst süreç başka bir çalışan için gereken bellek aralığını karşılayacak kadar boş bellek göremiyorsa daha fazla alt süreç başlatmak yerine havuzu mevcut boyutunda tutar.

Katmanları bir arada kullanmanın gerçekçi bir yolu

Sağlayıcı çağrılarını planlayan, uzmanlaşmış iş akışlarını başlatan ve ardından sonucu birleştiren bir araştırma iş akışı düşünün.

Sağlayıcıya yönelik adım, birden fazla çalışanın aynı model sağlayıcısına aynı anda yüklenmesini önlemek için cost_units ve paylaşılan bir concurrency_group yayımlayabilir. Kuyruk, sağlayıcı trafiği için ağırlıklı bir bütçe ayırabilir. Üst iş akışı, planlayıcının çalışmayı sonsuza dek büyütmesini önlemek için max_cost_units() ve max_started_workflows() sınırlandırabilir. Ardından çalışan, yakın dönem tepe bellek verileri sürecin veya kapsayıcının sınıra fazla yaklaştığını gösteriyorsa talep edilmiş yeni bir sağlayıcı çağrısını erteleyebilir.

Böylece birbirinden ayrı dört denetim elde edersiniz:

  1. İşin ağırlığını tanımlayın
  2. Kuyruk veya sağlayıcı kapasitesini paylaşarak ayırın
  3. Tek bir çalıştırmanın oluşturabileceklerini sınırlandırın
  4. Yoğun bir çalışanın gerekenden fazla iş başlatmasını önleyin

Ayrıntılı API'lerin bulunduğu yer

Bu sayfa kavramsal bir genel bakıştır.

Ayarlar için: