Kararlı Çalışanlar

Sorun bildirin Kaynağı göster Gece · 7,4 , 7.3 · 7.2 · 7,1 · 7,0 · 6,5

Bu sayfada, kalıcı çalışanların nasıl kullanılacağı, avantajları, koşulları ve çalışanların korumalı alanı nasıl etkilediği ele alınmaktadır.

Kalıcı çalışan, Bazel sunucusu tarafından başlatılan uzun süreli bir işlemdir. gerçek aracın (genellikle bir derleyici) etrafında bir sarmalayıcı işlevi görür veya aracın kendisidir. Kalıcı çalışanlardan yararlanmak için aracının bir dizi derleme yapmayı desteklemesi ve sarmalayıcının aracının API'si ile aşağıda açıklanan istek/yanıt biçimi arasında çeviri yapması gerekir. Aynı işçi, aynı derlemede --persistent_worker işaretiyle ve işaretsiz olarak çağrılabilir. İşçi, aracı uygun şekilde başlatmaktan ve araçla konuşmaktan, ayrıca çıkışta işçileri kapatmaktan sorumludur. Her çalışan örneği atanır altında ayrı bir çalışma dizinine (ana dizin olmadan) <outputBase>/bazel-workers

Kalıcı çalışanları kullanmak, yürütme stratejisi ile daha fazla JIT derlemesine olanak tanır ve işlemindeki soyut söz dizimi ağaçlarına örnek olarak verilebilir. Bu strateji, uzun süren bir işleme birden fazla istek göndererek bu iyileştirmeleri sağlar.

Kalıcı çalışanlar çeşitli dillerde uygulanır. Bu diller arasında Java, Scala, Kotlin ve daha fazlası.

NodeJS çalışma zamanı kullanan programlar @bazel/worker yardımcı kitaplığını kullanarak çalışan protokolüdür.

Kalıcı çalışanları kullanma

Bazel 0.27 ve sonraki sürümler, derlemeleri çalıştırırken varsayılan olarak kalıcı çalışanları kullanır ancak uzaktan yürütme önceliklidir. Kalıcı çalışanları desteklemeyen işlemler için Bazel her işlem için bir araç örneği başlatır. Bu kapsamdaki kullanıcıları worker ayarlayarak derlemenizi kalıcı çalışanları kullanacak şekilde ayarlayın geçerli aracın stratejisini anımsatıcılar. En iyi uygulama olarak bu örnekte, worker stratejisine yedek olarak local belirtilmiştir:

bazel build //my:target --strategy=Javac=worker,local

Yerel strateji yerine çalışan stratejisini kullanmak derlemeyi hızlandırabilir ve uygulamaya bağlı olarak, hızda büyük artış sağlayabilir. Java için derlemeler 2-4 olabilir kat daha hızlı, bazen de artımlı derlemeler için daha fazla çözüm sunar. Bazel derleniyor: yaklaşık 2,5 kat daha hızlıdır. Daha fazla bilgi için "Çalışanların sayısını seçme" bölümüne bakın.

Yerel derleme ortamınızla eşleşen uzak bir derleme ortamınız da varsa uzaktan yürütme ve işleyici yürütme işlemlerini yarıştıran deneysel dinamik stratejiyi kullanabilirsiniz. Dinamik gezinmeyi etkinleştirmek için strateji, proje yönetimi --experimental_spawn_scheduler tıklayın. Bu strateji, çalışanları otomatik olarak etkinleştirir. Dolayısıyla, worker stratejisini belirtebilir ancak local veya sandboxed öğesini, oluşturabilirsiniz.

Çalışan sayısını seçme

Anımsatıcı başına varsayılan çalışan örneği sayısı 4'tür, ancak ayarlanabilir şununla: worker_max_instances tıklayın. Mevcut CPU'lardan iyi bir şekilde yararlanmak ile elde ettiğiniz JIT derlemesi ve önbellek isabeti oranıdır. Daha fazla çalışanla, hedefler, JIT uygulanmamış kod çalıştırmanın ve baştan başlatmanın başlangıç maliyetlerini öder. önbellek. Oluşturulacak az sayıda hedefiniz varsa tek bir çalışan size en iyi dengeyi bulmaya çalışın (örneğin, 8586 numaralı sorunu inceleyin. worker_max_instances işareti, her bir anımsatıcı ve işaret grubu için maksimum işleyici örneği sayısını belirler (aşağıya bakın). Bu nedenle, karma bir sistemde varsayılan değeri kullanırsanız çok fazla bellek kullanabilirsiniz. Artımlı derlemelerde birden fazla çalışan örneğinin avantajı daha da azdır.

Bu grafik, Bazel (hedef) için sıfırdan derleme sürelerini göstermektedir //src:bazel), 6 çekirdekli hiper iş parçacıklı Intel Xeon 3,5 GHz Linux iş istasyonunda 64 GB RAM'e sahip. Her çalışan yapılandırması için beş tane temiz derleme çalıştırılıyor ve ortalaması alınır.

Şekil 1. Temiz derlemelerin performans iyileştirmeleri grafiği.

Bu yapılandırmada iki çalışan en hızlı derlemeyi sağlar ancak bir çalışana kıyasla yalnızca %14 oranında iyileşme sağlar. Daha az bellek kullanmak istiyorsanız bir işleyici iyi bir seçenektir.

Artımlı derleme genellikle daha da fazla avantaj sağlar. Temiz derlemeler nispeten nadirdir ancak tek bir dosyanın derlemeler arasında değiştirilmesi, teste dayalı geliştirmede pek çok yöntem mevcut. Yukarıdaki örnekte ayrıca, ek derleme süresini gölgede bırakabilecek paketleme işlemleri içerir.

Yalnızca Java kaynaklarını yeniden derleme (//src/main/java/com/google/devtools/build/lib/bazel:BazelServer_deploy.jar) dahili dize sabit değerini değiştirdikten sonra AbstractContainerizingSandboxedSpawn.java 3 kat hızlanma sağlar (bir ısınma derlemesi ile ortalama 20 artımlı derleme) silindi):

Şekil 2. Artımlı derlemelerdeki performans iyileştirmelerini gösteren grafik.

Hızlanma, yapılan değişikliğe bağlıdır. Faktör 6’nın hızlanması yaygın olarak kullanılan bir sabit değer değiştirildiğinde yukarıdaki durumda ölçülür.

Kalıcı çalışanları değiştirme

Çalışanlara başlangıç işaretlerini belirtmek için --worker_extra_flag işaretini iletebilirsiniz. Örneğin, --worker_extra_flag=javac=--debug parametresini iletmek yalnızca Javac için hata ayıklamayı etkinleştirir. Bu işaretin kullanımı başına ve yalnızca bir anımsatıcı için yalnızca bir çalışan işareti ayarlanabilir. Çalışanlar yalnızca her bir hatırlatıcı için ayrı ayrı değil, aynı zamanda başlangıç işaretlerindeki varyasyonlar için de ayrı ayrı oluşturulur. Anımsatıcı ve başlatmanın her kombinasyonu bayraklar bir WorkerKey olarak birleştirilir ve her WorkerKey için worker_max_instances çalışan oluşturulabilir. işlem yapılandırması, kurulum bayraklarını da belirtebilir.

URL parametrelerinin Google tarafından nasıl ele alınmasını istediğinizi belirtmek için --high_priority_workers normal öncelikli öncelikli olarak çalıştırılması gereken bir anımsatıcıyı belirtmek için işaret anımsatıcılar. Bu sayede her zaman kritik önemde olan işlemlere öncelik verebilirsiniz yol'a dokunun. İstekleri yürüten iki veya daha fazla yüksek öncelikli çalışan varsa diğer tüm çalışanların çalışması engellenir. Bu işaret birden fazla kez kullanılabilir.

--worker_sandboxing işaretçisi iletildiği takdirde her işleyici isteği, tüm girişleri için ayrı bir korumalı alan dizini kullanır. Korumalı alanın oluşturulması biraz zaman alır. özellikle macOS'te çalışır, ancak daha iyi doğruluk garantisi verir.

--worker_quit_after_build işareti, çoğunlukla hata ayıklama ve profil oluşturma için yararlıdır. Bu işaret, tüm çalışanları zorluyor birçok farklı yolu vardır. Ayrıca, çalışanların ne yaptığıyla ilgili daha fazla sonuç almak için --worker_verbose parametresini de iletebilirsiniz. Bu işaret, WorkRequest içinde verbosity alanı, çalışan uygulamalarının da kullanılmasına izin verir anlatabilmişimdir.

Çalışanlar günlüklerini <outputBase>/bazel-workers dizininde (ör. /tmp/_bazel_larsrc/191013354bebe14fdddae77f2679c3ef/bazel-workers/worker-1-Javac.log) depolar. Dosya adı, çalışan kimliğini ve anımsatıcıyı içerir. Her anımsatıcı için birden fazla WorkerKey olabilir. Bu nedenle, belirli bir anımsatıcı için worker_max_instances'ten fazla günlük dosyası görebilirsiniz.

Android derlemeleri için Android Derleme Performansı sayfasında ayrıntıları inceleyin.

Kalıcı çalışanları uygulama

Daha fazla bilgi için kalıcı çalışanlar oluşturma sayfasına bakın bilgi almalısınız.

Bu örnekte, JSON kullanan bir işleyici için Starlark yapılandırması gösterilmektedir:

args_file = ctx.actions.declare_file(ctx.label.name + "_args_file")
ctx.actions.write(
    output = args_file,
    content = "\n".join(["-g", "-source", "1.5"] + ctx.files.srcs),
)
ctx.actions.run(
    mnemonic = "SomeCompiler",
    executable = "bin/some_compiler_wrapper",
    inputs = inputs,
    outputs = outputs,
    arguments = [ "-max_mem=4G",  "@%s" % args_file.path],
    execution_requirements = {
        "supports-workers" : "1", "requires-worker-protocol" : "json" }
)

Bu tanım doğrultusunda, bu işlemin ilk kullanımı /bin/some_compiler -max_mem=4G --persistent_worker komut satırının yürütülmesiyle başlar. İstek işlevi şu şekilde görünür: Foo.java

NOT: Protokol arabellek spesifikasyonunda "yılan büyük/küçük harf" kullanılmasına rağmen (request_id), JSON protokolünde "deve büyük/küçük harf" kullanılır. (requestId). Bu belgede, JSON örneklerinde büyük harf, alan hakkında konuşurken yılan durumu veya protokolden bağımsız olarak.

{
  "arguments": [ "-g", "-source", "1.5", "Foo.java" ]
  "inputs": [
    { "path": "symlinkfarm/input1", "digest": "d49a..." },
    { "path": "symlinkfarm/input2", "digest": "093d..." },
  ],
}

Çalışan, bu mesajı stdin üzerinde yeni satırla sınırlandırılmış JSON biçiminde alır (requires-worker-protocol JSON olarak ayarlandığından). Ardından çalışan eylemi gerçekleştirir. ve stdout'unda Bazel'e JSON biçimli bir WorkResponse gönderir. Ardından Bazel bu yanıtı ayrıştırır ve manuel olarak WorkResponse proto'ya dönüştürür. Alıcı: yerine ikili kodlanmış protobuf kullanarak ilişkili çalışanla iletişim kurmak JSON, requires-worker-protocol şu şekilde proto olarak ayarlanır:

  execution_requirements = {
    "supports-workers" : "1" ,
    "requires-worker-protocol" : "proto"
  }

requires-worker-protocol'ü yürütme koşullarına eklemezseniz Bazel, varsayılan olarak işçi iletişiminde protobuf'i kullanır.

Bazel, WorkerKey öğesini hafızalardan ve paylaşılan işaretlerden türetir; dolayısıyla bu yapılandırmaya göre max_mem parametresinin değiştirilmesine izin verilirken ayrı bir çalışan ortaya çıkmasını sağlar. Çok fazla varyasyon kullanılırsa bu durum aşırı bellek tüketimine yol açabilir.

Her işleyici şu anda yalnızca tek bir isteği işleyebilir. Deneysel çoklu işleyici özelliği, temel araç çoklu iş parçacıklıysa ve sarmalayıcı bunu anlayacak şekilde ayarlandıysa birden fazla iş parçacığı kullanılmasına olanak tanır.

Bu GitHub deposunda, Java ve Python'da yazılmış örnek işleyici sarmalayıcılarını görebilirsiniz. JavaScript veya TypeScript ile çalışıyorsanız @bazel/worker paketi ve nodejs worker örneği faydalı olabilir.

Çalışanlar korumalı alanı nasıl etkiler?

Varsayılan olarak worker stratejisinin kullanılması, local stratejisine benzer şekilde işlemi bir korumalı alanda çalıştırmaz. Bu ayarı, Tüm çalışanları korumalı alan içinde çalıştırmak için --worker_sandboxing işareti. yalnızca olması gereken giriş dosyalarını görür. Araç yine de istekler arasında dahili olarak bilgi sızdırabilir (örneğin, önbellek. dynamic stratejisini kullanmak için çalışanların korumalı alana yerleştirilmesi gerekir.

Derleyici önbelleklerinin çalışanlarla doğru şekilde kullanılmasına olanak tanımak için bir özet aktarılır her giriş dosyasıyla birlikte dönüştürmenizi sağlar. Böylece derleyici veya sarmalayıcı, dosyayı okumak zorunda kalmadan girişin hâlâ geçerli olup olmadığını kontrol edebilir.

İstenmeyen önbelleğe almaya karşı koruma sağlamak için giriş özetlerini kullanırken bile, korumalı alan çalışanları, önceki isteklerden etkilenen diğer dahili durumları saklayabileceğinden, saf korumalı alana kıyasla daha az katı korumalı alan sunar.

Çoklu çalışanlar yalnızca çalışan uygulaması bunu destekliyorsa korumalı alana alınabilir ve bu korumalı alan, --experimental_worker_multiplex_sandboxing işaretiyle ayrı olarak etkinleştirilmelidir. Daha fazla bilgi için tasarım dokümanındaki ayrıntıları inceleyin.

Daha fazla bilgi

Kalıcı çalışanlar hakkında daha fazla bilgi için bkz:

• Orijinal kalıcı çalışanlar blog yayını
• Haskell uygulama açıklaması
• Mike Morearty'nin blog yayını
• Bazel ile Kullanıcı Arabirimi Geliştirme: Angular/TypeScript ve Kalıcı Çalışanlar Asana eşliğinde
• Bazel stratejileri hakkında bilgi
• bazel-discuss posta listesinde bilgilendirici çalışan stratejisi tartışması