SLURM "srun" - "sbatch" ve parametreleri


95

SLURM'ler srunile sbatchkomutlar arasındaki farkın ne olduğunu anlamaya çalışıyorum . Aşağıdaki sorulara özel cevaplar yerine genel bir açıklamadan memnun olacağım, ancak burada bir başlangıç ​​noktası olabilecek ve aradığım şey hakkında bir fikir verebilecek bazı belirli kafa karışıklıkları var.

Belgelere göre , srunsbatchgöndermek içindir ve daha sonra icra edilmek üzere iş göndermek içindir, ancak pratik fark benim için net değil ve davranışları aynı görünüyor. Örneğin, her biri 2 CPU'lu 2 düğüme sahip bir kümem var. Eğer yürütürsemsrun testjob.sh & arka arkaya 5x bir işlemci irade yürütme olarak, kullanılabilir hale gelinceye kadar, bu güzel beşinci iş sıraya olacaktır sbatch testjob.sh.

Soruyu daha somut hale getirmek için, başlamak için iyi bir yer olabileceğini düşünüyorum: Biriyle yapabileceğim, diğeriyle yapamayacağım şeyler nelerdir ve neden?

Her iki komutun argümanlarının çoğu aynıdır. En alakalı olanlardır --ntasks, --nodes, --cpus-per-task, --ntasks-per-node. Bunlar birbirleriyle nasıl ilişkilidir ve srunvs için nasıl farklılık gösterir sbatch?

Belirli bir fark olduğunu sruneğer hataya neden olur testjob.shçalıştırılabilir izni ie sahip değildir chmod +x testjob.shoysa sbatchmutlu o çalışacaktır. Durumun böyle olmasına neden olan "kaputun altında" neler oluyor?

Belgelerde ayrıca komut dosyalarının sruniçinde yaygın olarak kullanılanlardan bahsedilir sbatch. Bu, şu soruyu doğurur: Birbirleriyle nasıl etkileşim kurarlar ve her birinin "kanonik" kullanım durumu nedir? Özellikle, srunkendi başına kullanır mıydım?

Yanıtlar:


110

Belgeler diyor ki

srun is used to submit a job for execution in real time

süre

sbatch is used to submit a job script for later execution.

Her ikisi de hemen hemen aynı parametre setini kabul eder. Temel fark, srunetkileşimli ve engelleyici olmasıdır (sonucu terminalinizde alırsınız ve bitene kadar diğer komutları yazamazsınız)sbatch toplu işlem ve engellemesiz (sonuçlar bir dosyaya yazılır ve başka komutlar gönderebilirsiniz) derhal).

srunArka planda &işaretiyle birlikte kullanırsanız , srunetkileşimli olan ancak engellemeyen 'engelleme' özelliğini kaldırmış olursunuz . Yine de etkileşimlidir, bu da çıktının terminalinizi karıştıracağı ve srunsüreçlerin terminalinize bağlı olduğu anlamına gelir . Bağlantıyı keserseniz, onlar üzerindeki kontrolünüzü kaybedersiniz veya öldürülürler ( stdouttemelde kullanıp kullanmadıklarına bağlı olarak). Ve işleri göndermek için bağladığınız makine yeniden başlatılırsa öldürülürler.

Eğer kullanırsanız sbatch, işinizi göndermek ve Slurm tarafından ele alınır; hiçbir sonuç olmadan terminalinizin bağlantısını kesebilir, öldürebilirsiniz vb. İşiniz artık çalışan bir sürece bağlı değil.

Biriyle yapabileceğim, diğeriyle yapamayacağım şeyler nelerdir ve neden?

Kullanılabilir olan sbatchve olmayan bir özellik srun, iş düzenlemeleridir . srunBir sbatchkomut dosyası içinde kullanılabileceği gibi , yapamayacağınız hiçbir şey yoktur sbatch.

Bunlar birbirleriyle nasıl ilişkilidir ve srun ile sbatch arasında nasıl farklılık gösterir?

Tüm parametreler --ntasks, --nodes, --cpus-per-task, --ntasks-per-nodeher iki komutları aynı anlama sahiptir. Bu, dikkate değer istisna dışında neredeyse tüm parametreler için geçerlidir --exclusive.

Bunun böyle olmasına neden olan "kaputun altında" neler oluyor?

srunkomut dosyasını hemen uzak ana bilgisayarda yürütürken sbatch, komut dosyasını dahili bir depolamaya kopyalar ve ardından iş başladığında hesaplama düğümüne yükler. Gönderme komut dosyanızı gönderdikten sonra değiştirerek bunu kontrol edebilirsiniz; değişiklikleri (bkz dikkate alınmayacaktır bu ).

Birbirleriyle nasıl etkileşime girerler ve her birinin "kanonik" kullanım durumu nedir?

Genellikle sbatchbir iş göndermek için ve srunSlurm'un dediği gibi iş adımları oluşturmak için gönderim komut dosyasında kullanırsınız. srunsüreçleri başlatmak için kullanılır. Programınız paralel bir MPI programı ise, sruntüm MPI süreçlerini oluşturmaya özen gösterir. Değilse, srunprogramınızı --ntasksseçenek tarafından belirtildiği kadar çalıştırır . Programınızın paralel olup olmamasına, uzun çalışma süresine sahip olup olmadığına, tek bir yürütülebilir dosyadan oluşup oluşmadığına vb. Bağlı olarak birçok kullanım durumu vardır. Aksi belirtilmedikçe, srunvarsayılan olarak sbatchveya sallocçalıştırdığı ilgili seçenekleri devralır. altında ( buradan ).

Özellikle srun'u tek başına kullanır mıydım?

Küçük testler dışında hayır. Yaygın bir kullanım, srun --pty bashbir hesaplama işinde bir kabuk elde etmektir .


5
Cevabınız için teşekkür ederim, bu umduğum her şeyden daha iyi. Bir takip, çünkü bu benim orijinal kafa karışıklığımdan biriydi: neden srungönderi metninin içini aramakla uğraşayım? Belki de bir "iş adımı" nın anlamı konusunda kafam karışmıştır. Örneğin, runjob.shiçeren bir komut dosyam varsa, #!/bin/bash srun myjob.sh(a) sbatch runjob.sh- (b) sbatch myjob.sh- (c) srun myjob.sh- (d) arasında pratik bir fark var srun runjob.shmı? (Sonuncusu aptalca ama merak ediyorum)
dkv

3
srun'un bir gönderim komut dosyası içinde nasıl kullanıldığına dair fikirler için yakın zamanda verdiğim eğitim oturumunun slaytlarına göz atabilirsiniz: cism.ucl.ac.be/Services/Formations/slurm/2016/slurm.pdf
damienfrancois

4
Görünüşe göre slaytlardaki tüm örnekler (CECI sayfasındaki öğretici gibi) gönderim betiğinin sruniçinde kullanılıyor sbatch. Ancak, srungönderim betiğinde bulunmayan komutların aynı şekilde çalışacağını buldum . Yukarıda bahsettiğim dört çağrı arasında gerçekten bir fark var mı?
dkv

8
Tüm örnekleriniz yalnızca (1) ayırma bir CPU içinse ve (2) program tamamen sıralıysa aynı şekilde çalışacaktır. Farklılıkları görmek için birden fazla görev isteyin. Diğer bir fark ise, sbatch'te srun kullanmazsanız, sstat komutunun herhangi bir yararlı bilgi döndürmeyeceğidir
damienfrancois


5

Bu aslında soruyu tam olarak yanıtlamıyor, ancak ileride birisi için yararlı olabilecek bulduğum bazı bilgiler:


Bir itibaren ilgili iplik buldum benzer soru ile:

Özetle, sbatch ve salloc kaynakları işe ayırırken, srun bu kaynaklar arasında paralel görevler başlatır. Bir iş tahsisi içinde çağrıldığında, srun, tahsis edilen kaynakların bir kısmı veya tamamı üzerinde paralel görevler başlatacaktır. Bu durumda srun, varsayılan olarak altında çalıştığı sbatch veya salloc'un ilgili seçeneklerini devralır. Daha sonra (genellikle) varsayılan olarak aldıklarını geçersiz kılacak farklı seçenekler sunabilirsiniz. Bir iş içindeki her srun çağrısı, bir iş adımı olarak bilinir.

srun, bir iş tahsisinin dışında da çağrılabilir. Bu durumda srun, kaynakları ister ve bu kaynaklar verildiğinde, bu kaynaklar genelinde görevleri tek bir iş ve iş adımı olarak başlatır.

-B ve -exclusive seçenekleriyle ilgili daha ayrıntılı bilgi veren nispeten yeni bir web sayfası var.

doc / html / cpu_management.shtml


SLURM SSS sayfasından ek bilgiler .

Srun komutunun iki farklı çalışma modu vardır. İlk olarak, mevcut bir iş içinde çalıştırılmazsa (yani salloc veya sbatch tarafından oluşturulan bir Slurm iş tahsisi içinde değilse), o zaman bir iş tahsisi oluşturur ve bir uygulama oluşturur. Mevcut bir ayırma içinde çalıştırılırsa, srun komutu yalnızca uygulamayı oluşturur. Bu soru için, yalnızca ilk çalışma modunu ele alacağız ve sbatch ve srun komutlarını kullanarak bir iş tahsisi oluşturmayı karşılaştıracağız.

Srun komutu, birinin çıktıyı izlediği etkileşimli kullanım için tasarlanmıştır. Uygulamanın çıktısı, tipik olarak kullanıcının terminalinde srun komutunun çıktısı olarak görülür. Sbatch komutu, daha sonra çalıştırılmak üzere bir komut dosyası göndermek için tasarlanmıştır ve çıktısı bir dosyaya yazılır. İş tahsisinde kullanılan komut seçenekleri neredeyse aynıdır. Seçeneklerdeki en göze çarpan fark, sbatch komutunun iş dizileri konseptini desteklerken srun'un desteklememesidir. Bir diğer önemli fark, hata toleransındadır. Kesikli işleri içeren hatalar tipik olarak işin yeniden sıralanması ve tekrar yürütülmesi ile sonuçlanırken, srun ile ilgili hatalar tipik olarak kullanıcının uygun bir şekilde yanıt vereceği beklentisiyle bir hata mesajının üretilmesine neden olur.


Burada başka bir alakalı konuşma

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.