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ı işleyici, Bazel sunucusu tarafından başlatılan ve gerçek araç (genellikle bir derleyici) etrafında sarmalayıcı olarak işlev gören veya aracı kendisi olan uzun süreli bir işlemdir. Aracın kalıcı çalışanlardan yararlanabilmesi için
bir derleme dizisini teşvik ediyor ve sarmalayıcının
arasında bir bağlantı oluşturun. Aynı
çalışan,--persistent_worker
ve projeyi uygun şekilde başlatmaktan ve
çalışmasının yanı sıra çıkışta çalışanları devre dışı bırakmak da mümkün. 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, başlangıç masraflarını azaltan, daha fazla JIT derlemesine olanak tanıyan ve örneğin işlem yürütmedeki soyut söz dizimi ağaçlarının önbelleğe alınmasını sağlayan bir yürütme stratejisidir. Bu strateji bu iyileştirmeleri uzun süreli bir bahsedeceğim.
Kalıcı çalışanlar Java, Scala, Kotlin ve daha birçok dil için uygulanır.
NodeJS çalışma zamanı kullanan programlar, işleyici protokolünü uygulamak için @bazel/worker yardımcı kitaplığını kullanabilir.
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 local
öğesinin bir
worker
stratejisinden yararlanın:
bazel build //my:target --strategy=Javac=worker,local
Yerel strateji yerine işçi stratejisinin kullanılması, uygulamaya bağlı olarak derleme hızını önemli ölçüde artırabilir. Java için derlemeler 2-4 kat daha hızlı olabilir. Artımlı derlemede bu süre bazen daha da uzayabilir. Bazel derleniyor: yaklaşık 2,5 kat daha hızlıdır. Daha fazla bilgi için "Çalışan sayısını seçme" bölümüne ekleyin.
Yerel derlemenizle eşleşen bir uzak derleme ortamınız da varsa
isterseniz, deneysel ortamı kullanmak için
dinamik strateji,
Böylece hem uzaktan yürütme hem de işçi yürütme. 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'ları iyi kullanma ile aldığınız JIT derleme ve önbellek isabetlerinin miktarı arasında bir denge vardır. Daha fazla çalışan olduğunda, daha fazla hedef, JIT'siz kod çalıştırma ve soğuk önbellekleri kullanmayla ilgili başlangıç maliyetlerini karşılar. Derlemeniz gereken az sayıda hedef varsa tek bir çalışan, derleme hızı ile kaynak kullanımı arasında en iyi dengeyi sağlayabilir (örneğin, 8586 numaralı soruna bakın).
worker_max_instances
işareti, her bir işlem için maksimum çalışan örneği sayısını belirler
anımsatıcılar ve işaret grubu (aşağıya bakın). Bu nedenle, karma bir sistemde
varsayılan değeri koruyarak çok fazla
bellek kullanabilirsiniz. Artımlı derlemeler için
daha az avantaj sunar.
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ştirmelerini gösteren grafik.
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. Bir çalışan dahil olmak üzere daha az bellek kullanır.
Artımlı derleme genellikle daha da fazla fayda 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, artımlı derleme süresini gölgeleyebilecek bazı Java dışı paketleme işlemleri de vardır.
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.
Bu hız, yapılan değişikliğe bağlıdır. Yukarıdaki durumda, yaygın olarak kullanılan bir sabit değiştiğinde 6 kat hızlanma ö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. Her bir kısaltma ve başlangıç işareti kombinasyonu bir WorkerKey
olarak birleştirilir ve her WorkerKey
için en fazla worker_max_instances
çalışan oluşturulabilir. İşlem yapılandırmasının, kurulum işaretlerini nasıl belirtebileceği hakkında bilgi edinmek için sonraki bölüme bakın.
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, her zaman kritik yolda olan işlemlere öncelik vermenize yardımcı olabilir. İstekleri yürüten iki veya daha fazla yüksek öncelikli çalışan varsa
diğer çalışanların çalışması engellenir. Bu işaret birden fazla kez kullanılabilir.
Başarılı
--worker_sandboxing
flag, her çalışan isteğinin tüm istekleri için ayrı bir korumalı alan dizini kullanmasını sağlar.
giriş değerleridir. 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çindeki verbosity
alanına yansıtılır. Böylece, işleyici uygulamalarının daha ayrıntılı olması sağlanır.
Ç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. Daha fazla
birden fazla WorkerKey
varsa worker_max_instances
günlük dosyalarından yararlanma olanağı sağlar.
Android derlemeleri için Android Derleme Performansı sayfasında ayrıntıları inceleyin.
Kalıcı çalışanları hayata geçirme
Çalışan oluşturma hakkında daha fazla bilgi için kalıcı çalışan oluşturma sayfasına bakın.
Bu örnekte, JSON kullanan bir çalışan 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 arabelleği spesifikasyonunda "alt tireli" (request_id
) kullanılırken JSON protokolünde "üst tireli" (requestId
) kullanılır. Bu dokümanda, JSON örneklerinde üst tireli, protokolden bağımsız olarak alandan bahsederken ise alt tireli kullanılır.
{
"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. JSON yerine ikili kodlu protobuf kullanarak ilişkili işleyiciyle iletişim kurmak için requires-worker-protocol
, aşağıdaki gibi proto
olarak ayarlanır:
execution_requirements = {
"supports-workers" : "1" ,
"requires-worker-protocol" : "proto"
}
Yürütme şartlarına requires-worker-protocol
dahil etmezseniz
Bazel, çalışan iletişimini varsayılan olarak protobuf kullanacak şekilde ayarlar.
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.
İçinde bu GitHub deposunu Python'un yanı sıra Java'da da yazılmış örnek çalışan sarmalayıcılar 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?
worker
stratejisinin varsayılan olarak kullanılması, işlemi
korumalı alan, local
stratejisine benzer. --worker_sandboxing
işaretini, tüm işleyicileri korumalı alan içinde çalıştıracak şekilde ayarlayarak aracın her çalıştırmasında yalnızca olması gereken giriş dosyalarının gösterilmesini sağlayabilirsiniz. Araç, istekler arasında dahili olarak (ör. önbelleğe alma yoluyla) bilgi sızdırmaya devam edebilir. dynamic
stratejisini kullanmak için çalışanların korumalı alana yerleştirilmesi gerekir.
Derleyici önbelleklerinin işleyicilerle doğru şekilde kullanılmasına izin vermek için her giriş dosyasıyla birlikte bir özet gönderilir. Böylece derleyici veya sarmalayıcı, dosyayı okumak zorunda kalmadan girişin hâlâ geçerli olup olmadığını kontrol edebilir.
İstenmeyen önbelleğe almayı önlemek için giriş özetleri kullanılırken bile korumalı alana alınır çalışanlar saf korumalı alana göre daha az katı bir korumalı alan sunar, çünkü araç önceki isteklerden etkilenen diğer dahili durumları koruma
Ç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 aşağıdakilere bakın: