lsb.queues

構文

#INCLUDE "path-to-file"

説明

別のファイルから現在の場所に構成設定を挿入します。 このディレクティブは、構成の一部の制御を他のユーザーまたはユーザー・グループ専用にするために使用します。そのためには、特定のユーザーまたはユーザー・グループに対して組み込みファイルの書き込みアクセスを提供し、異なるクラスター内の構成ファイル設定の整合性を確保します ( LSF マルチクラスター機能を使用している場合)。

詳細については、共有設定ファイルの内容を参照してください。

デフォルト

定義されていません。

説明

Windowsユーザーアカウントまたはユーザーグループを指定するには、ドメイン名を大文字で含めます（ドメイン名\ユーザー名またはドメイン名\ユーザー・グループ）。

デフォルト

定義されていません。 このキューを操作するには、クラスター管理者でなければなりません。

構文

APS_PRIORITY=WEIGHT[[factor, value] [subfactor, value] ...] ...] LIMIT[[factor, value] [subfactor, value] ...] ...] GRACE_PERIOD[[factor, value] [subfactor, value] ...] ...]

説明

サブファクターの重みが定義されているが、親ファクターの重みが定義されていない場合、親ファクターの重みは 1 に設定されます。

WEIGHT および LIMIT 係数は浮動小数点値です。 GRACE_PERIOD の 値 は、秒 (値s)、分 (値m)、または時間 (値h) で指定します。

APS_PRIORITY の最大値は 1000000.00です。

猶予期間のデフォルトの単位は時間です。

指定する因子とサブファクターの名前を以下に示します。

GRACE_PERIOD[[MEM,10h] [JPRIORITY, 10m] [QPRIORITY,10s] [RSRC, 10]]

因子またはサブファクターの WEIGHT、 LIMIT、および GRACE_PERIOD に 0 (ゼロ) を指定することはできません。

APS キューは、キュー間フェア・シェア (FAIRSHARE_QUEUES) を構成できません。 QUEUE_GROUP パラメーターは、LSF 7.0で廃止された PARTISHARE_QUEUES の代わりに使用されます。

延期された (bstop) ジョブおよびマイグレーションされたジョブ (bmig) は、常に保留中のジョブの前にスケジュールされます。 マイグレーションされたジョブの場合、LSF は既存のジョブ優先順位情報を保持します。

LSB_REQUEUE_TO_BOTTOM および LSB_MIG2PEND が lsf.confで構成されている場合、マイグレーションされたジョブはその APS 情報を保持します。 LSB_REQUEUE_TO_BOTTOM および LSB_MIG2PEND が構成されている場合、マイグレーションされたジョブは、APS 値に基づいて他の保留中のジョブと競合する必要があります。 APS 値をリセットするには、 bmigではなく brequeueを使用します。

デフォルト

未定義

構文

BACKFILL=Y | N

説明

キューのバックフィル・スケジューリングを有効にするには、このパラメーターを Y に設定します。

BACKFILL と PREEMPTION を一緒に指定すると、競合が発生する可能性があります。 PREEMPT_JOBTYPE = BACKFILL が lsb.params ファイルに設定されている場合は、バックフィル・キューを優先使用可能にすることができます。 そうしないと、バックフィル・キューをプリエンプタブルにすることができません。 BACKFILL が有効になっている場合は、 PREEMPTION = PREEMPTABLEも指定しないでください。

BACKFILL は、割り込み可能なバックフィル・キューに必要です (INTERRUPTIBLE_BACKFILL=seconds)。

MAX_SLOTS_IN_POOL、 SLOT_RESERVE、および BACKFILL が同じキューに対して定義されている場合、キュー内のジョブは、同じキュー内の他のジョブによって予約されているスロットではバックフィルできません。

デフォルト

定義されていません。 バックフィルはありません。

説明

Fix Pack 15以降、管理者は CGROUP_CPU_SHARES_FACTOR パラメータを使用して、 cpu.shares および cpu.weight Linux cgroup (v1 または v2) インターフェイスのデフォルト値のパーセンテージを指定できるようになりました。これにより、CPU負荷の低いジョブは、他の実行中のすべてのジョブと同じCPU占有率またはCPUウェイトを受けるのではなく、他のジョブのCPU占有率またはCPUウェイトの何分の一かを受けることができます。 cpu.shares と cpu.weight の初期値は、設定されていればこの CGROUP_CPU_SHARES_FACTOR の値でスケーリングされる。 CGROUP_CPU_SHARES_FACTOR の値は、アプリケーション・プロファイルとキュー・レベルで指定することができる。 複数のレベルで定義されている場合、 LSF 、最も小さい値が使用される。 パラメータ CGROUP_CPU_SHARES_FACTOR を使用するには、設定 lsf.conf ファイル内の LSB_CGROUP_CPU_SHARES_OLD_DEFAULT パラメータが「」または nN 「」に設定されているか、デフォルト値である未定義のままになっていることを確認してください。

この値はパーセンテージを表すので、100未満の正の整数を指定する。 例えば、 CGROUP_CPU_SHARES_FACTOR=25 は、 cpu.shares と cpu.weight の値の25%のCPUシェア率を示す。

デフォルト

未定義

構文

CHKPNT=chkpnt_dir [chkpnt_period] [chkpnt_period ]

説明

チェックポイント・ディレクトリーは、チェックポイント・ファイルが作成されるディレクトリーです。 環境変数を使用しないで、絶対パスまたは CWD に対する相対パスを指定してください。

オプションのチェックポイント期間を分単位で指定します。

チェックポイントを指定できるのは、チャンク・ジョブの実行中のメンバーのみです。

チェックポイント関連の構成がキューとアプリケーション・プロファイルの両方に指定されている場合、アプリケーション・プロファイルの設定はキュー・レベルの構成をオーバーライドします。

マルチクラスター・ジョブのチェックポイント機能を使用可能にするには、送信ジョブと受信ジョブの両方のキュー ( lsb.queuesの場合は CHKPNT)、または実行依頼クラスターと実行クラスターの両方のアプリケーション・プロファイル ( lsb.applicationsの場合は CHKPNT_DIR、CHKPNT_PERIOD、CHKPNT_METHOD) にチェックポイント・ディレクトリーを定義します。 LSF は、実行クラスタに指定されているディレクトリを使用します。

マルチクラスター・ジョブのチェックポイント機能を有効にするには、サブミット・キューと実行キューの両方でチェックポイント機能を有効にする必要があり、実行クラスター上のアプリケーション・プロファイルまたはキューの設定によってチェックポイント・ディレクトリーが決定されます。 ジョブが専用ホストで実行される場合、チェックポイント機能はサポートされません。

チェックポイント・ディレクトリーのファイル・パスには、UNIX および Linuxの場合は 4000 文字まで、Windows の場合は 255 文字まで (ディレクトリー名とファイル名を含む) を含めることができます。

デフォルト

未定義

構文

COMMITTED_RUN_TIME_FACTOR=番号

説明

ユーザーの動的優先順位の計算では、この係数によって、計算におけるコミットされた実行時間の相対的な重要度が決まります。 ジョブの実行依頼時に bsub の -W オプションが指定されず、キューに対して RUNLIMIT が設定されていない場合、コミットされたランタイムは考慮されません。

未定義の場合、同じ名前の lsb.params パラメーターからのクラスター全体の値が使用されます。

有効値

0.0 から 1.0 までの任意の正数

デフォルト

定義されていません。

構文

CONTAINER=podman[image(image_name) options(podman_run_options)]

CONTAINER=docker[image(image_name) options(docker_run_options) container_io() job_pre_post()]

CONTAINER=nvidia-docker[image(image_name) options(docker_run_options)]

CONTAINER=shifter[image(image_name) options(container_options)]

CONTAINER=singularity[image(image_name) options(container_options)]

CONTAINER=apptainer[image(image_name) options(apptainer_options]

CONTAINER=enroot[image(image_name) options(enroot_start_options)]

説明

LSF が、このキューに実行依頼されるジョブに対してサポートされるコンテナーを使用できるようにします。 このパラメーターは、以下のキーワードを使用します。

ポッドマン | docker | nvidia-docker | シフトレバー | 特異性 apptainer| apptainer | 根付く

必須。 これらのキーワードのいずれかを使用して、このキューに実行依頼されるジョブに使用するコンテナーのタイプを指定します。

画像

必須。 このキーワードは、実行中のジョブで使用されるイメージ名を指定します。

Podman Docker NVIDIA Docker、Enrootのジョブについては、 $LSB_CONTAINER_IMAGE 環境変数を使用して、ジョブの送信時にユーザーがコンテナジョブのイメージ名を指定できるようにします。 ジョブの実行依頼時に、ユーザーは $LSB_CONTAINER_IMAGE 環境変数の値を指定することによって、指定されたリポジトリー・サーバー内にある特定のイメージ名を指定できます。

オプション

オプションです。 このキーワードは、コンテナーのジョブ実行オプションを指定します。

実行前スクリプトを実行できるようにするには、アットマーク (@) と、実行ホストがアクセスできる必要があるスクリプトの絶対ファイル・パスを指定します。 コンテナー・ジョブが実行される前に、 LSF は LSF 管理者特権を使用してこのスクリプトを実行します。 スクリプトの実行中に、ジョブの環境変数がスクリプトに渡されます。 スクリプトの実行が終了すると、出力がコンテナー始動オプションとして使用されます。 スクリプトは、この出力を 1 行で提供する必要があります。 コンテナー・ジョブの処理方法は、実行前スクリプトの結果によって異なります。

• 実行前スクリプトが失敗した場合、コンテナー・ジョブはスクリプトと同じ終了コードで終了します。 さらに、スクリプトの実行が失敗したためにジョブが終了したことをユーザーに通知する外部状況メッセージが送信されます。
• スクリプトの実行が成功したが、出力に 512 個を超えるオプションが含まれている場合、 LSF は最初の 512 個のオプションのみを保持し、残りのオプションは無視されます。
• スクリプトの実行が成功し、出力が有効な場合、出力はコンテナー・ジョブ実行オプションの一部になります。 オプション内のスクリプトからの出力の位置は、ユーザーがオプション・フィールドでスクリプトを構成した位置になります。

Docker および Dockerの場合、このキーワードは、 docker run コマンドの Docker実行オプションを指定し、そのオプションはジョブコンテナに渡されます。

注:

• Docker ジョブ実行オプションを指定する前に、これらのオプションがコマンド・ラインで docker run コマンドと連動することを確認してください。
• -- cgroup-parent および -- user (または -u) オプションは、 LSF 内部使用のために予約されています。 オプション・キーワード構成でこれらのオプションを使用しないでください。使用すると、ジョブは失敗します。

  実行前スクリプトを指定した場合に、このスクリプトの出力に -- cgroup-parent、 -- user、または -uが含まれていると、コンテナー・ジョブも失敗します。

• -w オプションと -- ulimit オプションは、 LSFに対して自動的に設定されます。 これらのオプションは、 LSF 設定をオーバーライドするため、オプション・キーワード構成では使用しないでください。
• -v オプションは、 LSF が必要とする作業ディレクトリー (現行作業ディレクトリー、ジョブ・スプール・ディレクトリー、 bsub -f コマンドの宛先ファイル、 tmp ディレクトリー、 LSF_TOP、およびチェックポイント・ディレクトリーなど) をオンデマンドでマウントするために、 LSF によって自動的に使用されます。
• options キーワード構成で -- rm オプションを構成して、ジョブの完了後にコンテナーを自動的に削除することができます。
• LSF が Docker コンテナーを作成するときに、 Docker コンテナーに自動的に名前を割り当てるようにすることができます。 この機能を有効にするには、 lsfdockerlib.py ファイルで ENABLE_CONTAINER_NAME パラメーターを True に設定します。

  コンテナー名には、以下の命名規則が使用されます。

  • 通常のジョブおよび blaunch パラレル・ジョブ・コンテナー: <cluster_name>.job.<job_id>
  • 配列ジョブと配列 blaunch パラレル・ジョブ・コンテナー: <cluster_name>.job.<job_id>.<job_index>
  • blaunch パラレル・ジョブ・タスク・コンテナー: <cluster_name>.job.<job_id>.task.<task_id>
  • 配列 blaunch パラレル・ジョブ・タスク・コンテナー: <cluster_name>.job.<job_id>.<job_index>.task.<task_id>
• 制限: -d オプションを使用すると、 LSF は、以下のように Docker ジョブの状況を誤って取得します。DONE.

シフター・コンテナーの場合、このキーワードは、ジョブ・コンテナーに渡される shifter コマンドのシフター・ジョブ実行オプションを指定します。

注:

• shifter コマンドがサポートするオプションを表示するには、コマンド行で shifter --help を実行します。
• シフター・ジョブ実行オプションを指定する前に、これらのオプションがコマンド行で shifter コマンドと連動することを確認してください。
• $LD_LIBRARY_PATH ディレクトリーは、Shifter が機能するために使用する setuid ビットに従ってクリーンアップされます。 したがって、 $LD_LIBRARY_PATH に依存するプログラム ( openmpiなど) の場合は、 udiRoot.conf ファイルの siteEnvAppend セクションに LD_LIBRARY_PATH を追加して、コンテナー内で setuid ビットを適切に設定できることを確認してください。

特異性コンテナーまたはアプリケーション・コンテナー・コンテナーの場合、このキーワードは、ジョブ・コンテナーに渡される singularity exec または or apptainer exec コマンドの「特異性」または「アプリケーション・コンテナー」ジョブ実行オプションを指定します。

注:

• コマンド行で singularity exec --help または apptainer exec --help を実行して、 singularity コマンドまたは apptainer コマンドがサポートするオプションを表示します。
• 「特異性」または「アプリケーション・コンテナー」のジョブ実行オプションを指定する前に、これらのオプションがコマンド行の singularity exec コマンドまたは apptainer exec コマンドで機能することを確認してください。
• $LD_LIBRARY_PATH ディレクトリーは、特異性または保持者が作業に使用する setuid ビットに従ってクリーンアップされます。 したがって、 $LD_LIBRARY_PATH に依存するプログラム ( openmpiなど) の場合、 LD_LIBRARY_PATH を ld.so.conf ファイルに追加して ldconfig コマンドを実行することにより、コンテナー内で setuid ビットを適切に設定できることを確認してください。

Podman コンテナーの場合、このキーワードは、ジョブ・コンテナーに渡される podman run コマンドの Podman ジョブ実行オプションを指定します。

注:

• Podman ジョブ実行オプションを指定する前に、これらのオプションがコマンド行で podman run コマンドと連動することを確認してください。
• -- user (または -u) オプションは、 LSF 内部使用のために予約されています。 オプション・キーワード構成でこれらのオプションを使用しないでください。使用すると、ジョブは失敗します。

  実行前スクリプトを指定した場合に、このスクリプトの出力に -- userまたは -uが含まれていると、コンテナー・ジョブも失敗します。

• -w オプションと -- ulimit オプションは、 LSFに対して自動的に設定されます。 これらのオプションは、 LSF 設定をオーバーライドするため、オプション・キーワード構成では使用しないでください。
• -v オプションは、 LSF が必要とする作業ディレクトリー (現行作業ディレクトリー、ジョブ・スプール・ディレクトリー、 bsub -f コマンドの宛先ファイル、 tmp ディレクトリー、 LSF_TOP、およびチェックポイント・ディレクトリーなど) をオンデマンドでマウントするために、 LSF によって自動的に使用されます。
• options キーワード構成で -- rm オプションを構成して、ジョブの完了後にコンテナーを自動的に削除することができます。
• 制限: -d オプションを使用すると、 LSF は、以下のように Docker ジョブの状況を誤って取得します。DONE.

Enroot コンテナーの場合、このキーワードは、ジョブ・コンテナーに渡される enroot start コマンドの Enroot ジョブ実行オプションを指定します。

注: Enroot ジョブ実行オプションを指定する前に、これらのオプションがコマンド行の enroot start コマンドで機能することを確認してください。

コンテナ_io()

オプションです。 Fix Pack 15では、 Docker ジョブに対して、 LSF が出力ファイルを Docker コンテナファイルシステムに書き込みます。 設定されている場合は、 job_pre_post() キーワードも指定する。

job_pre_post()

オプションです。 LSF Fix Pack 15の時点で、 Docker ジョブに設定されている場合、 Docker コンテナ内でユーザーレベルの実行前コマンドおよび実行後コマンドを実行できるようになります。 設定されている場合は、 container_io() キーワードも指定する。

例

Begin Queue
QUEUE_NAME = podmanq
CONTAINER = podman[image(repository.example.com:5000/file/path/ubuntu:latest)]
DESCRIPTION = Podman User Service
End Queue

Begin Queue
QUEUE_NAME = dockerq
CONTAINER = docker[image(repository.example.com:5000/file/path/ubuntu:latest)
container_io() job_pre_post()]
DESCRIPTION = Docker User Service
End Queue

Begin Queue
QUEUE_NAME = ndockerq
CONTAINER = nvidia-docker[image(repository.example.com:5000/file/path/ubuntu:latest)]
DESCRIPTION = NVIDIA Docker User Service
End Queue

Begin Queue
QUEUE_NAME = shifterq
CONTAINER = shifter[image(ubuntu:latest)]
DESCRIPTION = Shifter User Service
End Queue

Begin Queue
QUEUE_NAME = singq
CONTAINER = singularity[image(/file/path/ubuntu.img)]
DESCRIPTION = Singularity User Service
End Queue

Begin Queue
QUEUE_NAME = apptainerq
CONTAINER = apptainer[image(/share/apptainer/images/ubuntu_latest.sif)]
DESCRIPTION = Apptainer User Service
End Queue

Begin Queue
QUEUE_NAME = enrootq
CONTAINER = enroot[image(repository.example.com:5000/file/path/ubuntu:latest)]
DESCRIPTION = Enroot User Service
End Queue

Begin Queue
QUEUE_NAME = dockerqoptions
CONTAINER = docker[image(repository.example.com:5000/file/path/ubuntu:latest) options(@/share/usr/docker-options.sh)
container_io() job_pre_post()]
DESCRIPTION = Docker User Service with pre-execution script for options
End Queue

Begin Queue
QUEUE_NAME = ndockerqoptions
CONTAINER = nvidia-docker[image(repository.example.com:5000/file/path/ubuntu:latest) options(@/share/usr/ndocker-options.sh)]
DESCRIPTION = NVIDIA Docker User Service with pre-execution script for options
End Queue

Begin Queue
QUEUE_NAME = shifterqoptions
CONTAINER = shifter[image(ubuntu:latest) options(@/share/usr/shifter-options.sh)]
DESCRIPTION = Shifter User Service
End Queue

Begin Queue
QUEUE_NAME = singqoptions
CONTAINER = singularity[image(/file/path/ubuntu.img) options(@/share/usr/sing-options.sh)]
DESCRIPTION = Singularity User Service
End Queue

Begin Queue
QUEUE_NAME = apptainerq
CONTAINER = apptainer[image(/share/apptainer/images/ubuntu_latest.sif) options(@/share/usr/apptainer-options.sh)]
DESCRIPTION = Apptainer User Service
End Queue

Begin Queue
QUEUE_NAME = podmanqoptions
CONTAINER = podman[image(repository.example.com:5000/file/path/ubuntu:latest) options(@/share/usr/podman-options.sh)]
DESCRIPTION = Podman User Service with pre-execution script for options
End Queue

Begin Queue
QUEUE_NAME = dockerqoptions
CONTAINER = docker[image(repository.example.com:5000/file/path/ubuntu:latest) options(@/share/usr/podman-options.sh)
container_io() job_pre_post()]
DESCRIPTION = Docker User Service with pre-execution script for options
End Queue

Begin Queue
QUEUE_NAME = enrootqoptions
CONTAINER = enroot[image(repository.example.com:5000/file/path/ubuntu:latest) options(@/share/usr/enroot-options.sh)]
DESCRIPTION = Enroot User Service with pre-execution script for options
End Queue

• 順次ジョブの場合、ジョブの完了後にコンテナーを自動的に削除するには、 LSF に以下の CONTAINER パラメーター値を指定します。

  CONTAINER = docker[image(image-name) options(--rm)]

• パラレル・ジョブの場合、 blaunch を機能させるには、ネットワークと IPC がコンテナー間で機能する必要があります。 実行ユーザー ID とユーザー名のマッピング・ファイルは、 blaunch 認証のためにコンテナーにマウントする必要があります。

  したがって、 LSF に以下の CONTAINER パラメーター値を指定して、 blaunch が複数のコンテナーにわたって機能し、 blaunch 認証用のコンテナー・パスワード・ファイルを構成し、ジョブの完了後にコンテナーを自動的に削除できるように、コンテナー IPC およびネットワーク・パラメーターを構成します。

  CONTAINER=docker[image(image-name) options(--rm --network=host --ipc=host -v /path/to/my/passwd:/etc/passwd)]

  passwd ファイルは、UNIX および Linux のパスワード・ファイルの標準形式 (以下の形式など) でなければなりません。

  user1:x:10001:10001:::
  user2:x:10002:10002:::

• Podman Docker NVIDIA、Enrootのコンテナジョブに対して、ジョブの送信時にユーザーがイメージ名を指定できるようにするには、 image キーワードを指定する際に、 $LSB_CONTAINER_IMAGE 環境変数をイメージ名として使用します。
  例えば、 udockerGPU キューの CONTAINER パラメーターを定義する場合は、 $LSB_CONTAINER_IMAGE 環境変数をイメージ仕様に追加します。

  Begin Queue
  QUEUE_NAME = udockerGPU
  CONTAINER = docker[image(repository.example.com:5000/$LSB_CONTAINER_IMAGE) \
              options(--rm --net=host --ipc=host  -v --runtime=nvidia /gpfs/u/fred:/data )
              container_io() job_pre_post()]
  DESCRIPTION = Docker User Service
  End Queue

  以下のいずれかの方法を使用して $LSB_CONTAINER_IMAGE 環境を設定することにより、ジョブの実行依頼時にコンテナー・イメージ名 ( ubuntuなど) を指定します。

  • ご使用のシェル環境に応じて $LSB_CONTAINER_IMAGE 環境変数を指定します。
    • csh または tcshの場合:

      setenv LSB_CONTAINER_IMAGE ubuntu

    • sh、 ksh、または bashの場合:

      export LSB_CONTAINER_IMAGE=ubuntu

  • bsub -env オプションを使用します。

    bsub -env LSB_CONTAINER_IMAGE=ubuntu -q udocker a.out -in in.dat -out out.dat

  • esub スクリプトを使用して LSB_CONTAINER_IMAGE 環境変数を設定してから、 bsub コマンドで esub を呼び出します。
    例えば、 $LSF_SERVERDIR ディレクトリーに、以下の内容の esub.docker スクリプトを作成します。

    #!/bin/sh
    exec 1>&2
    echo "LSB_CONTAINER_IMAGE=∖"$1∖"" >> $LSB_SUB_MODIFY_ENVFILE

    以下のコマンドを実行して、 esub.docker スクリプトを呼び出すジョブをサブミットします。

    bsub -a "docker(ubuntu)" -q dockerq a.out -in in.dat -out out.dat

デフォルト

未定義

構文

CORELIMIT=整数

説明

このキューからのジョブに属するすべてのプロセスについて、プロセスごとのハード・コア・ファイル・サイズの制限を KB 単位で設定するには、このパラメーターを指定します ( getrlimit(2) を参照)。

デフォルト

無制限

構文

説明

キューに実行依頼されるすべてのジョブには、指定された CPU 頻度が必要です。 値は、単位 (GHz、MHz、または KHz) の正の浮動小数点数です。 単位が設定されていない場合、デフォルトは GHz です。

bsub -freq を使用してこの値を設定することもできます。

実行依頼値はアプリケーション・プロファイル値を上書きし、アプリケーション・プロファイル値はキュー値を上書きします。

デフォルト

未定義 (公称 CPU 周波数が使用される)

構文

CPULIMIT=[default_limit ] 最大リミット

ここで、 default_limit および maximum_limit は、以下の数式で定義されます。

[時:]分[/host_name |/host_model]

説明

ジョブが使用できる合計 CPU 時間を制限します。 このパラメーターは、ランナウェイ・ジョブ、またはリソースの使用量が多すぎるジョブを防止するのに役立ちます。

ジョブ全体の合計 CPU 時間が制限に達すると、そのジョブに属するすべてのプロセスに SIGXCPU シグナルが送信されます。 ジョブに SIGXCPUのシグナル・ハンドラーがない場合、ジョブは即時に強制終了されます。 SIGXCPU シグナルがアプリケーションによって処理、ブロック、または無視される場合、猶予期間が経過すると、LSF は SIGINT、 SIGTERM、および SIGKILL をジョブに送信してそれを強制終了します。

ジョブが動的にプロセスを作成する場合、これらのプロセスによって使用される CPU 時間は、ジョブの存続期間にわたって累積されます。

30 秒未満の間存在するプロセスは無視される可能性があります。

デフォルトでは、デフォルトの CPU リミットが指定されている場合、ジョブ・レベルの CPU リミットなしでキューに実行依頼されたジョブは、デフォルトの CPU リミットに達すると強制終了されます。

1 つの制限のみを指定した場合は、最大 (ハード) CPU 制限になります。 2 つの制限を指定する場合、最初の制限はデフォルト (ソフト) CPU 制限、2 番目の制限は最大 CPU 制限です。

CPU 時間にホストまたはホスト・モデルが指定されていない場合、LSF は、キュー・レベルで定義されているデフォルトの CPU 時間正規化ホスト ( lsb.queuesの DEFAULT_HOST_SPEC) が構成されていれば、それを使用します。 それ以外の場合は、クラスター・レベルで定義されているデフォルトの CPU 時間正規化ホスト ( lsb.paramsの DEFAULT_HOST_SPEC) が使用されます (構成されている場合)。 それ以外の場合は、CPU 係数が最大のホスト (クラスター内で最も速いホスト) が使用されます。

sbatchd は CPU 時間制限を超過したかどうかを定期的に検査するため、CPU 時間制限の下で実行される Windows ジョブは、その制限を SBD_SLEEP_TIME まで超過する可能性があります。

UNIX システムでは、プロセス・レベルでオペレーティング・システムによって CPU リミットを適用できます。

CPU リミットが、OS によって強制されるプロセスごとの制限であるか、 lsf.confで LSB_JOB_CPULIMIT を使用して LSF によって強制されるジョブごとの制限であるかを定義できます。

CPULIMIT が 30 分を超える場合、チャンク・ジョブ・キューに実行依頼されたジョブはチャンク化されません。

デフォルト

無制限

構文

CPU_TIME_FACTOR=番号

説明

ユーザーの動的共用優先順位の計算において、この係数は、ユーザーのジョブによって使用される累積 CPU 時間の相対的な重要度を決定します。

未定義の場合、同じ名前の lsb.params パラメーターからのクラスター全体の値が使用されます。

デフォルト

0.7

説明

複数の CSM ジョブ・オプションを区切るには、コロン (:) を使用します。 オプションは任意の順序で指定でき、何も必要ありません。 alloc_flags キーワードには、フラグの英数字ストリングを指定し、複数のフラグはスペースで区切ります。 ストリングにコロン (:) を含めることはできません。

例

CSM_REQ=jsm=n:step_cgroup=y:core_isolation 3:cn_mem=1024

デフォルト

定義されていません。

構文

DATALIMIT=[デフォルトリミット ] 最大リミット

説明

このキューからのジョブに属するすべてのプロセスについて、プロセスごとのデータ・セグメント・サイズの制限を KB 単位で設定するには、このパラメーターを設定します ( getrlimit(2) を参照)。

デフォルトでは、デフォルトのデータ制限が指定されている場合、ジョブ・レベルのデータ制限なしでキューに実行依頼されたジョブは、デフォルトのデータ制限に達すると強制終了されます。

1 つの制限のみを指定する場合は、最大 (ハード) データ制限になります。 2 つの制限を指定した場合、最初の制限はデフォルト、つまりソフト・データ制限になり、2 番目の制限は最大データ制限になります。

デフォルト

無制限

説明

DATA_TRANSFER=Y パラメーターは、 LSF データ・マネージャーを介してデータを転送するためのキューを使用可能にします。

クラスター内の 1 つのキューのみをデータ転送キューにすることができます。 データ・マネージャーによって実行依頼されたすべての転送ジョブは、このキューに入れられます。 lsf.datamanager ファイルが存在する場合は、少なくとも 1 つのキューで DATA_TRANSFER パラメーターを定義する必要があります。 このパラメーターを設定する場合は、対応する lsf.datamanager ファイルが存在している必要があります。

bsub を介してこのキューに実行依頼される通常のジョブは拒否されます。

bstop、 bresume、および bkill コマンドを使用して、データ転送キュー内の自分の転送ジョブを停止、再開、および強制終了します。 LSF 管理者およびキュー管理者は、さらに btop コマンドおよび bbot コマンドを使用して、キュー内の転送ジョブを移動することができます。 データ転送キュー内のジョブに対する他のすべてのコマンドはリジェクトされます。 bswitch コマンドを使用して、ジョブを他のキューからデータ転送キューに切り替えることはできません。

このパラメーターを変更すると、前のキューにあった LSF データ・マネージャー転送ジョブはそのキューに残り、通常どおりにスケジュールされて実行されます。 LSF データ・マネージャーには、成功または失敗が通知されます。

データ転送キューは、 lsb.params ファイルの DEFAULT_QUEUE パラメーターで定義されているデフォルト・キューのリストには表示できません。 データ転送キューに実行依頼されたジョブは、 lsb.params ファイルの DEFAULT_APPLICATION パラメーターで指定されたアプリケーションには接続されません。

デフォルト

N

構文

DEFAULT_EXTSCHED=外部スケジューラー・オプション (external_scheduler_options)

説明

bsub コマンドの -extsched オプションは DEFAULT_EXTSCHED オプションとマージされ、 -extsched オプションは DEFAULT_EXTSCHED によって設定されたすべての競合するキュー・レベル・オプションをオーバーライドします。

デフォルト

未定義

構文

DEFAULT_HOST_SPEC=ホスト名 | ホスト・モデル

説明

指定されたホストまたはホスト・モデルの CPU 係数は、CPU 時間正規化ホストがジョブ・レベルで指定されていない限り、キュー内のすべてのジョブの CPU 時間制限を正規化するために使用されます。

デフォルト

定義されていません。 キューは、 lsb.paramsで定義された DEFAULT_HOST_SPEC を使用します。 いずれのファイルにもDEFAULT_HOST_SPECが定義されていない場合、LSFはクラスタ内で最速の静的サーバーホストを使用します。

構文

DESCRIPTION=テキスト

説明

この待ち行列のサービス機能を明確に記述した記述を使用して, ユーザーが各ジョブの正しい待ち行列を選択するのに役立ててください。

テキストには、空白文字を含む任意の文字を含めることができます。 前の行をバックスラッシュ（\テキストの最大長は 512 文字です。

構文

DISPATCH_BY_QUEUE=Y|y|N|n

説明

スケジューリング・セッション全体が終了するのを待たずに、指定されたキューのスケジューリング決定をパブリッシュできるようにします。

キューの応答性を向上させるには、このパラメーターを設定します。 指定されたキュー内のジョブのスケジューリング決定は最終的なものであり、これらのジョブを同じスケジューリング・サイクル内で優先使用することはできません。

デフォルト

N

構文

DISPATCH_ORDER=QUEUE

説明

デフォルトでは、ユーザーは 親 キューと 子 キューの間で同じ優先順位を持ちます。 同じユーザーが複数のジョブをこれらのキューにサブミットする場合、ユーザー優先順位は、ユーザーが 親-子 セット全体でサブミットするすべてのジョブを考慮に入れて計算されます。

DISPATCH_ORDER=QUEUE が 親 キューに設定されている場合、ジョブは最初にキューの優先順位に従ってディスパッチされ、次にユーザーの優先順位に従ってディスパッチされます。 より優先順位の高いキューに保留中のジョブがある、より優先順位の低い共用優先順位を持つユーザーからのジョブは、優先順位の低いキューにあるジョブよりも前にディスパッチされます。 この動作により、より公平な共用優先順位を持つユーザーが、優先順位の低いキューからディスパッチされたジョブを取得することを回避できます。

同じ優先順位を持つキュー内のジョブは、ユーザーの優先順位に従ってディスパッチされます。

キュー間フェア・シェアの一部ではないキューは、任意の優先順位を持つことができます。キュー間フェア・シェア・キューの優先順位範囲外になるように制限されることはありません。

デフォルト

未定義

構文

DISPATCH_WINDOW=時間枠 ...

説明

このキューからのジョブは、ディスパッチ・ウィンドウの外部でディスパッチされません。

デフォルト

定義されていません。 ディスパッチ・ウィンドウは常に開いています。

説明

Dockerベースのコンテナー化ジョブをスケジューリングする場合、このパラメーターを y または Y に設定すると、 LSF は、要求された Docker イメージを既に持っている実行ホストを優先することができます。 これにより、ネットワーク帯域幅とジョブ開始時間が削減されます。これは、実行ホストがリポジトリーから Docker イメージをプルする必要がなく、実行ホスト上でジョブを即時に開始できるためです。

この機能が有効になっている場合、 LSF は Docker ジョブをスケジュールする際に Docker イメージのロケーション情報を考慮します。 Docker イメージ・アフィニティーは、以下の方法でホスト設定および order[] ストリング要求と対話します。

• ホスト設定が指定されている場合、ホスト設定が最初に適用されます。 同じ設定レベルのホストの中で、要求された Docker イメージを持つホストの優先順位が高くなります。
• order[] ストリングを指定すると、要求された Docker イメージを持つホストの優先順位が高くなります。 すべてが要求された Docker イメージを持つホストの中で、 order[] ストリングが受け入れられます。

このキューを処理するには、このパラメーターに CONTAINER パラメーターを定義する必要があります。

デフォルト

定義されていません。

構文

ELIGIBLE_PEND_TIME_LIMIT=[時:]分

説明

LSF は、キュー・レベルで適格な保留時間制限構成を IBM® Spectrum LSF RTM (LSF RTM) に送信します。これにより、ユーザー通知 (例えば、ジョブをサブミットしたユーザーと LSF 管理者への通知) やジョブ制御アクション (例えば、ジョブの強制終了) などのアラームおよびトリガー・アクションが処理されます。 LSF RTM は、ジョブの適格保留時間を適格保留時間制限と比較し、ジョブがこの指定された時間制限より長く適格保留状態である場合、 LSF RTM はアラームとアクションをトリガーします。 このパラメーターは LSF RTMなしで機能しますが、LSF はその他のアラーム・アクションを実行しません。

マルチクラスター・ジョブ転送モードでは、実行クラスター内のジョブの適格保留時間制限は無視されます。一方、実行依頼クラスターは、ローカル設定に従って、ジョブのキュー・レベル、アプリケーション・レベル、およびジョブ・レベルの適格保留時間制限をマージします。

適格な保留時間制限は、[hour:]minuteの形式です。 分は 59 より大きい数値で指定できます。 例えば、3 時間半を 3:30 または 210 のいずれかとして指定できます。

ジョブ・レベルの適格保留時間制限 (bsub -eptl) は、アプリケーション・レベルの制限 ( lsb.applicationsのELIGIBLE_PEND_TIME_LIMIT ) をオーバーライドし、アプリケーション・レベルの制限は、ここで指定されたキュー・レベルの制限をオーバーライドします。

デフォルト

定義されていません。

構文

ENABLE_GPU_HIST_RUN_TIME=y | Y | n | N

説明

Y に設定すると、フェア・シェア・スケジューリング優先順位の計算で、履歴 GPU ランタイムを使用できるようになります。

未定義の場合、同じ名前の lsb.params パラメーターからのクラスター全体の値が使用されます。

デフォルト

定義されていません。

構文

ENABLE_HIST_RUN_TIME=y | Y | n | N

説明

Y に設定すると、フェア・シェア・スケジューリング優先順位の計算にヒストリカル・ランタイムを使用できるようになります。

未定義の場合、同じ名前の lsb.params パラメーターからのクラスター全体の値が使用されます。

デフォルト

定義されていません。

構文

ESTIMATED_RUNTIME=[時:]分[/host_name | /host_model]

説明

このパラメーターは、キューに関連したジョブの推定実行時間を指定します。 LSF は、スケジューリングの目的でのみ ESTIMATED_RUNTIME 値を使用し、ジョブが定義済みの RUNLIMIT も超えない限り、この値を超えるジョブを強制終了しません。 ランタイム見積もりの形式は、RUNLIMIT パラメーターと同じです。

bsub -We によって指定されたジョブ・レベルのランタイム見積もり、またはアプリケーションの ESTIMATED_RUNTIME 設定によって、キュー内の ESTIMATED_RUNTIME 設定がオーバーライドされます。 キュー内の ESTIMATED_RUNTIME 設定は、クラスター全体の ESTIMATED_RUNTIME 設定をオーバーライドします。

デフォルト

未定義

構文

EXCLUSIVE=Y | | N CU[cu_type ]

説明

Y に設定すると、排他的キューを指定します。

CU、CU []、または CU [cu_type] に設定した場合、排他的キューと、タイプ cu_type ( lsb.paramsで定義) の計算単位専用のキューを指定します。 タイプが指定されていない場合は、デフォルトの計算単位タイプが使用されます。

bsub -x を使用して排他的キューに実行依頼されたジョブは、他の実行中のジョブがないホストにのみディスパッチされます。 bsub -R "cu[excl]" を使用して計算単位の排他的キューに実行依頼されたジョブは、他に実行中のジョブがない計算単位でのみ実行されます。

マルチクラスター・リソース・リース・モデルで共有されるホストの場合、ジョブが別のクラスターからのものであっても、実行中のジョブがあるホストにジョブはディスパッチされません。

デフォルト

N

構文

Podman求人： EXEC_DRIVER=context[user(user_name)] starter[/file_path_serverdir/podman-starter.py] controller[/file_path/to/serverdir/podman-control.py] monitor[/file_path/to/serverdir/podman-monitor.py]

Dockerのジョブ: EXEC_DRIVER=context[user(user_name path(/path/path1:/path/path2)] starter[/file_path_serverdir/docker-starter.py] controller[/file_path/to/serverdir/docker-control.py] monitor[/file_path/to/serverdir/docker-monitor.py]

根付いた雇用： EXEC_DRIVER=starter[/file_path_serverdir/enroot-starter.py]

説明

Enroot ジョブの場合はオプションです。 このキュー内の Podman または Docker コンテナー・ジョブの実行ドライバー・フレームワークを指定します。 このパラメーターは、以下のキーワードを使用します。

user

Docker ジョブの場合はオプションの 、Enroot ジョブの場合は無視されます。 このキーワードは、スクリプトを開始するためのユーザー・アカウントを指定します。 構成される値は、ユーザー ID ではなくユーザー名です。 Docker ジョブの場合、このユーザーは Docker ユーザー・グループのメンバーでなければなりません。 Podman ジョブの場合は、ユーザー名を「default」に設定する必要があります。

デフォルトでは、これは LSF 1 次管理者です。

注: これを root ユーザーにすることはできません。

LSF には、ジョブの開始 (docker-starter.py)、ジョブのリソースのモニター (docker-monitor.py)、およびジョブへのシグナルの送信 (docker-control.py) に使用される 3 つの実行ドライバー・スクリプトが含まれています。 これらのスクリプトは、 LSF_SERVERDIR ディレクトリーにあります。 EXEC_DRIVER パラメーターでスクリプト・ファイルを使用する前に、スクリプト・ファイルの所有者をコンテキスト・ユーザーに変更し、ファイル許可を 700 または 500 に変更します。

スターター・スクリプトは必須です。 Docker コンテナー・ジョブの場合、モニター・スクリプトと制御スクリプトは、 cgroupfs ドライバーが systemdの場合は必須ですが、 cgroupfs ドライバーが cgroupfsの場合はオプションです。 Podman コンテナー・ジョブの場合、モニター・スクリプトはオプションですが、制御スクリプトは必須です。 Enroot コンテナー・ジョブの場合、スターター・スクリプトは必須ですが、他のすべてのスクリプトは無視されます。

Podman、 Docker、または Enroot ジョブの CONTAINER パラメーターとの対話

Podman Docker、またはEnroot ジョブの場合、 EXEC_DRIVER パラメータは、 CONTAINER パラメータ内の以下のキーワードと相互作用します

• imageは、スクリプト名を指定するときにサポートされるイメージ名 ($LSB_CONTAINER_IMAGE 環境変数) を指定します。
• ランタイム・オプションとオプション・スクリプトを指定した options がサポートされます。

例

Begin Queue
QUEUE_NAME = podmanq
CONTAINER = podman[image(repository.example.com:5000/file/path/ubuntu:latest)
            options(--rm --network=host --ipc=host -v /path/to/my/passwd:/etc/passwd)]
EXEC_DRIVER = context[user(default)] starter[/path/to/driver/podman-starter.py]
              controller[/path/to/driver/podman-control.py]
              monitor[/path/to/driver/podman-monitor.py]
DESCRIPTION = Podman User Service
End Queue

Begin Queue
QUEUE_NAME = dockerq
CONTAINER = docker[image(repository.example.com:5000/file/path/ubuntu:latest)
            options(--rm --network=host --ipc=host -v /path/to/my/passwd:/etc/passwd)
            container_io() job_pre_post()]
EXEC_DRIVER = context[user(user-name) path(/path/one:/path/two)] starter[/path/to/driver/docker-starter.py]
              controller[/path/to/driver/docker-control.py]
              monitor[/path/to/driver/docker-monitor.py]
DESCRIPTION = Docker User Service
End Queue

Begin Queue
QUEUE_NAME = enrootq
CONTAINER = enroot[image(repository.example.com:5000/file/path/ubuntu:latest)
            options(--mount /mydir:/mydir2]
EXEC_DRIVER = starter[/path/to/driver/enroot-starter.py]
DESCRIPTION = Enroot User Service
End Queue

デフォルト

Podman ジョブおよび Docker ジョブの場合は未定義です。

starter[$LSF_SERVERDIR/enroot-starter.py] (Enroot ジョブの場合)

構文

EXTENDABLE_RUNLIMIT=BASE[minutes] INCREMENT[minutes] GRACE[minutes] REQUEUE[Y|N]

説明

このパラメーターを構成すると、キュー内の計画を持つジョブに拡張可能な実行制限ポリシーが適用されます。 計画を持つジョブがディスパッチされると、 LSF はそのジョブの初期ソフト実行制限を設定します。 ジョブがソフト実行制限に達すると、 LSF は、別のジョブがリソース上で計画された割り振りを持っているかどうかを考慮します。 そうでない場合、 LSF はジョブのソフト実行制限を拡張します。 それ以外の場合、 LSF はジョブのハード実行制限を設定します。 ジョブがハード実行制限に達すると、 LSF はそのジョブを終了または再キューイングします。

このパラメーターは、以下のキーワードを使用します。

BASE[分]

キュー内のジョブに適用される初期ソフト実行制限。 ジョブがソフト実行制限に達するたびに、割り振りプランナーは、他のジョブの計画を調べることによって、ジョブによって保持されているリソースがキュー内の別のジョブによって必要かどうかを検討します。 リソースが不要な場合、 LSF はジョブのソフト実行制限を拡張します。 それ以外の場合、 LSF はハード実行制限を設定します。

初期ソフト実行制限の整数値を指定します。

INCREMENT[分]

オプションです。 LSF がジョブのソフト実行制限を延長することを決定した場合、このキーワードは、 LSF がソフト実行制限を延長する時間を指定します。

ソフト実行制限拡張時間の整数値を指定してください。 デフォルト値は、 BASE[] キーワードの値です。

GRACE[分]

オプションです。 LSF がジョブのソフト実行制限を延長しないことを決定した場合、決定が行われた時点からこの分数だけハード実行制限が設定されます。

デフォルト値は 0 (ジョブは即時に終了または再キューイングされます) です。

REQUEUE[Y | N]

オプションです。 ジョブがハード実行制限に達したときに LSF が実行するアクションを指定します。 Nに設定すると、 LSF はジョブを終了します。 Y LSF に設定されている場合、ジョブを再キューイングします。

デフォルト値は N です (ジョブがハード実行制限に達すると、LSF はジョブを終了します)。

デフォルト

定義されていません。

指定された実行制限時間 ( RUNLIMIT パラメーターまたは -W オプションで指定) に達したジョブは、リソースが使用可能かどうかに関係なく、チェックポイントがとられ (チェックポイント指定可能な場合)、終了します。

構文

説明

キュー・レベルのユーザー・ベースのフェア・シェアを使用可能にし、オプションのシェア割り当てを指定します。 共用割り当てが指定されている場合には, 共用割り当てをもつユーザーだけがジョブを待ち行列に投入することができます。

互換性

キュー・レベルとホスト・レベルの両方でフェア・シェアを使用するようにクラスター内のホストを構成しないでください。 ただし、ユーザー・ベースのフェア・シェアとキュー・ベースのフェア・シェアを一緒に構成することができます。

デフォルト

定義されていません。 公平な共有はありません。

構文

FAIRSHARE_ADJUSTMENT_FACTOR=番号

説明

ユーザー動的共用優先順位の計算では、この係数によって、フェア・シェア・プラグイン (libfairshareadjust.*) で行われるユーザー定義の調整の相対的な重要度が決まります。

正の浮動小数点数は、フェア・シェア・プラグインを使用可能にし、加重係数として機能します。

未定義の場合、同じ名前の lsb.params パラメーターからのクラスター全体の値が使用されます。

デフォルト

定義されていません。

構文

FAIRSHARE_QUEUES=キュー名 [キュー名...]

説明

ノート

デフォルト

未定義

構文

FILELIMIT=整数

説明

このキューからジョブに属するすべてのプロセスについて、プロセスごとのハード・ファイル・サイズの制限を KB 単位で設定するには、このパラメーターを設定します ( getrlimit(2) を参照)。

デフォルト

無制限

構文

FWD_JOB_FACTOR=番号

説明

ユーザーの動的共用優先順位の計算において、この係数は、 LSF マルチクラスター機能の使用時にユーザーによって予約され、使用されている転送ジョブ・スロットの数の相対的な重要度を決定します。

未定義の場合、同じ名前の lsb.params パラメーターからのクラスター全体の値が使用されます。

デフォルト

定義されていません。

関連資料

構文

FWD_USERS=all [~user_name...] [~user_group...] | [user_name...] [user_group [~user_group...]...]

説明

ユーザー・グループが指定されている場合、グループ内の各ユーザーは、このキュー内のリモート・クラスターにジョブを転送できます。 ユーザー・グループを指定する場合は、ローカル・ユーザー・グループを使用します。

ユーザー名は有効なログイン名でなければなりません。 Windowsユーザーアカウントを指定するには、ドメイン名を大文字で含めます（ドメイン名\ユーザー名）。

ユーザー・グループ名は、LSF ユーザー・グループまたは UNIX および Windows ユーザー・グループにすることができます。 Windowsユーザーグループを指定するには、ドメイン名を大文字で含めます（ドメイン名\ユーザー・グループ）。

クラスター内のすべてのユーザーまたはユーザー・グループを指定するには、キーワード all を使用します。

all 指定またはユーザー・グループからユーザーを除外するには、NOT 演算子 (~) を使用します。 これは、多数のユーザーが存在するが、キュー定義から一部のユーザーまたはグループのみを除外したい場合に役立ちます。

NOT 演算子 (~) は、 all キーワードと一緒に使用するか、ユーザー・グループからユーザーを除外する場合にのみ使用できます。

デフォルト

all (すべてのユーザーがキュー内のリモート・クラスターにジョブを転送できます)

例

説明

ベンダー=amd | nvidia

GPU ベンダー・タイプを指定します。 LSF は、指定されたベンダー・タイプで GPU を割り振ります。

AMD GPU を要求するには amd を指定し、Nvidia GPU を要求するには nvidia を指定します。

デフォルトでは、 LSF は Nvidia GPU を要求します。

gmodel =モデル名[- mem _size]

特定のモデル名と、オプションでその合計 GPU メモリーを使用して GPU を指定します。 デフォルトでは、 LSF は同じモデルを使用して GPU を割り振ります (使用可能な場合)。

gmodel キーワードは、以下の形式をサポートします。

gmodel =モデル名

指定されたブランドとモデル名 (例えば、 TeslaK80) を持つ GPU を要求します。

gmodel =short_model_name

特定のブランド名 (例えば、Tesla、Quadro、NVS など) を使用して GPU を要求します。 またはモデル・タイプ名 (例えば、 K80、 P100)。

gmodel = モデル名 - メモリサイズ

指定されたブランド名と合計 GPU メモリー・サイズを持つ GPU を要求します。 GPU メモリー・サイズは、数値とその単位で構成されます。これには、 M、 G、 T、 MB、 GB、および TB (例えば、 12G) が含まれます。

各ホストで使用可能な GPU モデル名を見つけるには、 lsload –gpuload、 lshosts –gpu、または bhosts -gpu コマンドを実行します。 モデル名ストリングにスペース文字が含まれていません。 さらに、スラッシュ (/) 文字とハイフン (-) 文字は下線文字 (_) に置き換えられます。 例えば、GPU モデル名は "Tesla C2050 / C2070「 LSFで「TeslaC2050_C2070」に変換されます。

gmem=mem_value

ジョブに必要な各 GPU 上の GPU メモリーを指定します。 mem_value の形式は、他のリソース値と同じです (例えば、次のようになります)。memまたはswap) ジョブ・リソース要件の rusage セクション (-R)。

gtile=！ | タイル番号

ソケットごとの GPU の数を指定します。 ホスト上のソケットごとの GPU の数を明示的に定義する数値を指定するか、感嘆符 (!) を指定して LSF が自動的に数値を計算できるようにします。これにより、ホスト上のすべてのソケットで GPU が均等に分割されます。 LSF は、アフィニティー・ジョブの場合でも gtile 要件を保証します。 これは、 gtile 要件を満たすことができない場合に、 LSF が、割り振られた CPU に GPU のアフィニティーを割り振らない可能性があることを意味します。

アフィニティー・ジョブに対して gtile キーワードが指定されていない場合、 LSF は、GPU を割り振ったソケットに十分な GPU を割り振ろうとします。 最適なソケット上に十分な GPU がない場合、ジョブはこのホストに進むことができません。

非類似性ジョブに対して gtile キーワードが指定されていない場合、 LSF は同じソケットに十分な GPU を割り振ろうとします。 これが使用可能でない場合、 LSF は GPU を別個の GPU に割り振る可能性があります。

nvlink=はい

LSFバージョン 10.1 フィックスパック 11 で廃止されました。 代わりに glink キーワードを使用してください。 GPU 間の NVLink 接続に対するジョブ適用を有効にします。 LSF は、NVLink 接続を有効にして GPU を割り振ります。

glink=はい

GPU 間の特殊な接続に対するジョブ適用を有効にします。 LSF は、GPU ベンダーに固有の特殊な接続を使用して GPU を割り振る必要があります。

ジョブが AMD GPU を要求する場合、 LSF は xGMI 接続を使用して GPU を割り振る必要があります。 ジョブが Nvidia GPU を要求する場合、 LSF は NVLink 接続を使用して GPU を割り振る必要があります。

glink は、廃止された nvlink キーワードと一緒に使用しないでください。

デフォルトでは、これらの接続に十分な GPU がない場合、 LSF は特殊な接続なしで GPU を割り振ることができます。

mig= GI _size[/ CI _size]

Nvidia マルチインスタンス GPU (MIG) デバイス要件を指定します。

MIGジョブに要求されるGPUインスタンスサイズを指定します。 有効なGPUインスタンス・サイズは1、2、3、4、7です。

オプションとして、指定されたGPUインスタンスサイズとスラッシュ文字(/)の後に、要求された計算インスタンスサイズを指定します。要求されたコンピュート・インスタンス・サイズは、要求されたGPUインスタンス・サイズ以下でなければなりません。 さらに、Nvidia MIG は、GPU/ 計算インスタンス・サイズの組み合わせ (4/3、7/5、7/6) をサポートしていません。 これが指定されていない場合、デフォルトの計算インスタンス・サイズは 1 です。

デフォルト

未定義

関連資料

構文

GPU_RUN_TIME_FACTOR=番号

説明

ユーザーの動的共用優先順位の計算において、この係数は、ユーザーが実行中の GPU ジョブの合計 GPU 実行時間の相対的な重要度を決定します。

未定義の場合、同じ名前の lsb.params パラメーターからのクラスター全体の値が使用されます。

デフォルト

定義されていません。

構文

HIST_HOURS=時間

説明

動的ユーザー優先順位を計算するために、LSF は減衰因子を使用して実際の CPU 時間と実行時間をスケーリングします。 最近使用された 1 時間は、指定された時間数が経過した後の 0.1 時間に相当します。

減衰実行時間と履歴実行時間を使用して動的ユーザー優先順位を計算するために、LSF は同じ減衰係数を使用して、終了したジョブの累積実行時間と実行ジョブの実行時間をスケーリングします。これにより、最近使用された 1 時間は、指定された時間数が経過した後の 0.1 時間に相当します。

HIST_HOURS=0の場合、実行中のジョブによって累積される CPU 時間と実行時間は減衰しません。

未定義の場合、同じ名前の lsb.params パラメーターからのクラスター全体の値が使用されます。

デフォルト

定義されていません。

構文

HJOB_LIMIT=整数

説明

このパラメーターは、このキューが任意のホストで使用できるジョブ・スロットの最大数を定義します。 この制限は、存在する可能性のあるプロセッサーの数に関係なく、ホストごとに構成されます。

例

Begin Queue 
... 

HJOB_LIMIT = 1 

HOSTS=hostA hostB hostC 
... 

End Queue

デフォルト

無制限

説明

HOST_POST_EXEC コマンドは、ジョブの終了後にすべての実行ホストで実行されます。 ジョブ・ベースの実行後 POST_EXEC がキュー・レベル、アプリケーション・レベル、またはジョブ・レベルで定義された場合、 HOST_POST_EXEC コマンドは任意のレベルの POST_EXEC の後で実行されます。

サポートされるコマンド規則は、キュー・セクションの既存の POST_EXEC と同じです。 詳しくは、 POST_EXEC のトピックを参照してください。

デフォルト

定義されていません。

説明

HOST_PRE_EXEC コマンドは、ジョブの開始前にすべての実行ホストで実行されます。 ジョブ・ベースの実行前 PRE_EXEC がキュー・レベル/アプリケーション・レベル/ジョブ・レベルで定義された場合、 HOST_PRE_EXEC コマンドは任意のレベルの PRE_EXEC の前に実行されます。

サポートされるコマンド規則は、キュー・セクションの既存の PRE_EXEC と同じです。 詳しくは、 PRE_EXEC のトピックを参照してください。

デフォルト

定義されていません。

構文

HOSTLIMIT_PER_JOB=整数

説明

このパラメーターは、このキュー内のジョブが使用できるホストの最大数を定義します。 LSF は、スケジューリングの割り振りフェーズ中にホスト制限を検査します。 並列ジョブに対して要求されたホストの数がこの制限を超え、 LSF が要求スロットの最小数を満たすことができない場合、並列ジョブは保留になります。 ただし、再開された並列ジョブの場合、このパラメーターは、ジョブのホスト割り振りがこのパラメーターで指定されたジョブごとのホスト制限を超えても、ジョブの再開を停止しません。

デフォルト

無制限

構文

説明

計算単位、ホスト・グループ、またはホスト区画がリストに含まれている場合、ジョブは、ユニット、グループ、または区画内の任意のホストで実行できます。 ホスト・リストのすべてのメンバーは、単一のホスト・パーティションに属しているか、どのホスト・パーティションにも属していないかのいずれかでなければなりません。 そうしないと、ジョブ・スケジューリングが影響を受けることがあります。

一部の項目の後には、正符号 (+) と正数を付けて、そのホストにジョブをディスパッチする優先度を示すことができます。 数値が大きいほど、優先度が高いことを示します。 ホスト設定が指定されていない場合は、0 と見なされます。 複数の候補ホストがある場合、LSF は最も高い優先度を持つホストにジョブをディスパッチします。同じ優先度レベルのホストは負荷順に並べられます。

計算装置、ホスト・グループ、またはホスト区画に設定が割り当てられている場合、その装置、グループ、または区画内の各ホストは同じ設定になります。

明示的にリストされていないすべてのホストを含めるには、キーワード others を使用します。

リースをホストに含めるには、キーワード allremote hostgroup_name を使用します。

キュー内の all 指定からホストを除外するには、NOT 演算子 (~) を使用します。 これは、大規模なクラスターがあるが、キュー定義からいくつかのホストのみを除外する場合に役立ちます。

NOT 演算子は、 all キーワードと一緒にのみ使用できます。 キーワード others および noneと一緒に使用することは できません 。

NOT 演算子 (~) は、ホスト・グループを除外するために使用できます。

パラレル・ジョブの場合、最初の実行ホストで実行されるプロセスを処理するために必要なリソースまたはランタイム環境がホストにあることを確認するには、最初の実行ホスト候補を指定します。

1 つ以上のホスト、ホスト・グループ、または計算装置を最初の実行ホスト候補として指定するには、名前の後に感嘆符 (!) 記号を追加します。

ホスト交差がある場合の動作

bsub によって指定されたホスト設定-mキュー仕様と事前予約ホストをインテリジェントに組み合わせます。 ジョブは、ジョブのサブミット時に指定され、キューに属しているか事前予約があるホストで実行されます。

例 1

HOSTS=hostA+1 hostB hostC+1 hostD+3

この例では、以下の 3 つのレベルの設定を定義します。hostDできるだけ多く実行してください。そうでない場合は、hostAまたはhostC可能な場合。そうでない場合は、実行場所hostB. ジョブを実行してはなりませんhostBただし、他のすべてのホストがビジーであるために、さらに多くのジョブを受け入れることができない場合

例 2

HOSTS=hostD+1 others

ジョブの実行対象hostDできるだけ多く実行してください。そうしないと、使用可能な最小ロードのホストでジョブが実行されます。

例 3

HOSTS=all ~hostA

以下を除く、クラスター内のすべてのホストでジョブを実行します。hostA.

例 4

HOSTS=Group1 ~hostA hostB hostC

ジョブの実行対象hostB,hostC、および以下のすべてのホストGroup1以下を除くhostA.

例 5

HOSTS=hostA! hostB+ hostC hostgroup1!

以下のいずれかを使用して並列ジョブを実行hostAまたは定義されているホストhostgroup1最初の実行ホストとして使用します。 リソース要件のために最初の実行ホストがジョブ全体を実行できない場合は、残りのジョブを実行します。hostB.hostBビジーであるためジョブを受け入れることができない場合、またはhostBジョブ全体を実行するための十分なリソースがありません。残りのジョブを実行します。hostC.

例 6

HOSTS=computeunit1! hostB hostC

ホストを使用して並列ジョブを実行します。computeunit1最初の実行ホストとして使用します。 リソース要件のために最初の実行ホストがジョブ全体を実行できない場合は、以下の場所にある他のホストでジョブの残りを実行します。computeunit1次が続きますhostBそして最後にhostC.

例 7

HOSTS=hostgroup1! computeunitA computeunitB computeunitC

ホストを使用して並列ジョブを実行します。hostgroup1最初の実行ホストとして使用します。 追加のホストが必要な場合は、最初の実行ホストと同じ計算単位内の他のホストで残りのジョブを実行します。その後、残りの計算単位内のホストを、 lsb.hosts ComputeUnit セクションで定義された順序で実行します。

デフォルト

all (キューはクラスター内のすべてのホストを使用でき、すべてのホストの優先度は同等です)

構文

IGNORE_DEADLINE=Y

説明

Y に設定すると、LSF は締切制約スケジューリングを無視し、締切制約に関係なくすべてのジョブを開始します。

構文

IMPT_JOBBKLG=整数 |infinit

説明

このパラメーターは、キューで保留できるマルチクラスター・ジョブの最大数を表します。この制限に達すると、キューはリモート・クラスターからのジョブの受け入れを停止します。

キューが保留中のマルチクラスター・ジョブを無制限に受け入れるようにするには、キーワード infinit を使用します。

デフォルト

50

構文

IMPT_JOBLIMIT=整数 |infinit

説明

このパラメーターは、キュー内で開始できるマルチクラスター・リモート・ジョブの最大数を表します。制限に達すると、キューはキューからのリモート・ジョブのディスパッチを停止します。

ジョブの数には 0 または任意の正整数を指定してください。

キューがマルチクラスター・ジョブの開始を無制限に受け入れるようにするには、キーワード infinit を使用します。

デフォルト

infinit (キューは、マルチクラスター・ジョブ・タスクの開始を無制限に受け入れます。)

構文

IMPT_TASKBKLG=整数 |infinit

説明

実行依頼クラスターで、要求されたジョブ・タスクの合計数と受信キューにインポートされた保留タスクの数が IMPT_TASKBKLGより大きい場合、キューはリモート・クラスターからのジョブの受け入れを停止し、ジョブは受信キューに転送されません。

タスク数として 0 から 2147483646 までの整数を指定してください。

キューが保留中のマルチクラスター・ジョブ・タスクを無制限に受け入れるようにするには、キーワード infinit を使用します。

IMPT_TASKBKLG を 0 に設定すると、すべてのジョブが受信側キューに転送されなくなります。

デフォルト

infinit (キューは、保留中のマルチクラスター・ジョブ・タスクを無制限に受け入れます。)

構文

IMPT_TASKLIMIT=整数 |infinit

説明

実行依頼クラスターで、要求されたジョブ・タスクの総数と、受信キューにインポートされた開始タスクの数が IMPT_TASKLIMITより多い場合、キューはキューからのリモート・ジョブのディスパッチを停止し、ジョブは受信キューに転送されません。

ジョブ・タスクの数には任意の正整数を指定してください。

ジョブ・タスクが受信キューに転送されないようにするには、 IMPT_TASKLIMIT を 0 に設定します。

キューがマルチクラスター・ジョブ・タスクの開始を無制限に受け入れるようにするには、キーワード infinit を使用します。

デフォルト

infinit (キューは、マルチクラスター・ジョブ・タスクの開始を無制限に受け入れます。)

構文

INTERACTIVE=YES | NO | ONLY

説明

YES に設定すると、キューは対話式と非対話式の両方のバッチ・ジョブを受け入れます。

NO に設定すると、キューは対話式バッチ・ジョブを拒否します。

ONLY に設定すると、キューは対話式バッチ・ジョブを受け入れ、非対話式バッチ・ジョブを拒否します。

対話式バッチ・ジョブは、 bsub -Iを介して実行依頼されます。

デフォルト

はい。 キューは、対話式ジョブと非対話式ジョブの両方を受け入れます。

構文

INTERRUPTIBLE_BACKFILL=秒

説明

割り込み可能なバックフィル・ queue.It これは、クラスター内で最も優先順位の低いキューでなければなりません。

ジョブが backfilling.This 最小タイム・スライスは、特定のジョブ・プロパティーによって異なります。これは、ジョブの少なくとも 1 つの有効な反復より長くなければなりません。 異なるクラスのジョブがサイトにある場合は、複数のキューが作成される可能性があります。

キュー RUNLIMIT は、バックフィルの最大タイム・スライスに対応し、キューに実行依頼された新規ジョブの待機期間がユーザーに受け入れられるように構成する必要があります。 10 分の実行時間は一般的な値です。

割り込み可能なバックフィル・キューに対して REQUEUE_EXIT_VALUES を構成する必要があります。

キューで BACKFILL および RUNLIMIT を構成する必要があります。 BACKFILL および RUNLIMIT が構成されていない場合、キューは使用不可になります。

前提事項と制限事項:

デフォルト

定義されていません。 割り込み可能なバックフィルはありません。

構文

JOB_ACCEPT_INTERVAL=整数

説明

このパラメーター値は、 lsb.params MBD_SLEEP_TIME の値 (デフォルトでは 60 秒) で乗算されます。 この計算の結果は、ジョブをホストにディスパッチしてから、2 番目のジョブを同じホストにディスパッチするまでに待機する秒数です。

0 (ゼロ) に設定すると、ホストは各ディスパッチ・ターンで複数のジョブを受け入れることができます。 デフォルトでは、ホスト上で実行できるジョブの総数に制限はありません。したがって、このパラメーターを 0 に設定すると、非常に多くのジョブがホストに同時にディスパッチされる可能性があります。 これにより、これ以上プロセスを作成できないポイントまでシステムが過負荷になる可能性があります。 このパラメーターを 0 に設定することは推奨されません。

キュー・レベル (lsb.queues) で設定された JOB_ACCEPT_INTERVAL は、クラスター・レベル (lsb.params) で設定された JOB_ACCEPT_INTERVAL をオーバーライドします。

デフォルト

定義されていません。 キューは、 lsb.paramsで定義された JOB_ACCEPT_INTERVAL を使用します。デフォルト値は 1 です。

構文

JOB_ACTION_WARNING_TIME=[時:]分

説明

ジョブ処置警告時間は正規化されません。

ジョブ警告を有効にするには、ジョブ警告アクション ( JOB_WARNING_ACTION パラメーター) とともにジョブ・アクション警告時間を指定する必要があります。

bsub -wt オプションで指定された警告時間は、キュー内の JOB_ACTION_WARNING_TIME をオーバーライドします。 コマンド行オプションが指定されていない場合は、 JOB_ACTION_WARNING_TIME がデフォルトとして使用されます。

例

JOB_ACTION_WARNING_TIME=2
JOB_WARNING_ACTION=URG

ジョブが実行時限界または終了締切に達するか、キューの実行時間枠がクローズされる 2 分前に、URG シグナルがジョブに送信されます。

デフォルト

未定義

構文

説明

• アクションの構成行の内容は、次のように実行されます。/bin/sh -cコマンドでシェル機能を使用できます。
• コマンドの標準入力、出力、およびエラーは NULL デバイスにリダイレクトされるため、コマンドが正しく実行されるかどうかを直接判断することはできません。 UNIX でのデフォルトのヌル・デバイスは /dev/nullです。
• コマンドはジョブのユーザーとして実行されます。
• ジョブに設定されたすべての環境変数は、コマンド・アクションにも設定されます。 以下の追加の環境変数が設定されます。
  • LSB_JOBPGIDS: ジョブの現行プロセス・グループ ID のリスト
  • LSB_JOBPIDS: ジョブの現在のプロセス ID のリスト
• SUSPEND アクション・コマンドの場合、以下の環境変数も設定されます。
  • LSB_SUSPEN_REASONS- lsbatch.hで定義されている中断理由のビットマップを表す整数。 中断の理由により、ジョブを中断する理由に基づいて、コマンドがさまざまなアクションを実行できるようになります。
  • LSB_SUS_SUBREASONS-ジョブが中断される原因となったロード索引を表す整数。 中断理由 SUSPEN_LOAD_REASON (ロードによって中断状態) が LSB_SUSPEN_REASONS に設定されている場合、LSB_SUSPEN_SUBREASONS は、 lsf.hで定義されているロード索引値の 1 つに設定されます。 ジョブが中断される原因となった正確なロードしきい値を判別するには、カスタム・ジョブ制御で LSB_SUS_REASONS と LSB_SUS_SUBREASONS を一緒に使用します。
• SUSPEND コマンドに対して追加のアクションが必要な場合、そのアクションは適切なシグナルもアプリケーションに送信する必要があります。 それ以外の場合、ジョブは、LSF によって中断された後でも実行を継続することができます。 例:JOB_CONTROLS=SUSPEND[kill $LSB_JOBPIDS; コマンド]
• ジョブ制御コマンドが失敗した場合、 LSF は元のジョブ状況を保持します。
• IBM Spectrum LSF License Schedulerを使用するシグナル SIGTSTP で優先使用を設定する場合は、ライセンス・スケジューラーの優先使用が機能するように、 lsf.conf で LIC_SCHED_PREEMPT_STOP=Y を定義します。

デフォルト

UNIX の場合、デフォルトでは、SUSPEND は並列ジョブまたは対話式ジョブの場合は SIGTSTP を送信し、その他のジョブの場合は SIGSTOP を送信します。 RESUME は SIGCONT を送信します。 TERMINATE は、SIGINT、SIGTERM、および SIGKILL をこの順序で送信します。

Windows では、デフォルトのジョブ制御アクションを実行するために、UNIX シグナルに相当するアクションが実装されています。 ジョブ制御メッセージは SIGINT および SIGTERM シグナルを置き換えますが、処理できるのはカスタマイズされたアプリケーションのみです。 終了は、以下によって実装されます。TerminateProcess( )システム・コール。

構文

JOB_IDLE=番号

説明

値は、CPU 時間/ランタイムを表す 0.0 から 1.0 までの数値でなければなりません。 ジョブ・アイドル係数が指定されたしきい値より小さい場合、LSF は LSF_SERVERDIR/eadmin を呼び出して、ジョブ・アイドル例外のアクションを起動します。

ジョブがアイドル状態であることを mbatchd が報告する前の最小ジョブ実行時間は、 lsb.paramsで DETECT_IDLE_JOB_AFTER として定義されます。

有効値

0.0 から 1.0 までの任意の正数

例

JOB_IDLE=0.10

アイドル値 (CPU 時間/ランタイム) が 0.10より小さいジョブに対して、ジョブ・アイドル例外がトリガーされます。

デフォルト

定義されていません。 ジョブ・アイドル例外は検出されません。

構文

JOB_OVERRUN=実行時間

説明

ジョブが指定されたランタイムより長く実行されると、LSF は LSF_SERVERDIR/eadmin を呼び出して、ジョブ・オーバーラン例外のアクションを起動します。

例

JOB_OVERRUN=5

ジョブ・オーバーラン例外は、5 分より長く実行されているジョブに対してトリガーされます。

デフォルト

定義されていません。 ジョブ・オーバーラン例外は検出されません。

構文

JOB_SIZE_LIST=default_size [サイズ ...]

説明

bsub および bmodに対して -n オプションまたは -R オプションを使用してジョブ・サイズを要求するジョブを実行依頼または変更する場合、要求されるジョブ・サイズは、 JOB_SIZE_LIST が指定する値の 1 つ (このキューで許可されるジョブ・サイズ) と一致する単一の固定値でなければなりません。 要求されたジョブ・サイズがこのリストにない場合、 LSF はジョブをリジェクトします。 さらに、 bswitch を使用して、要求されたジョブ・サイズを持つ保留中のジョブを別のキューに切り替える場合、保留中のジョブの要求されたジョブ・サイズは、新しいキューの JOB_SIZE_LIST の値の 1 つとも一致している必要があります。

このリストの最初の値は、デフォルトのジョブ・サイズです。これは、ジョブがジョブを要求せずに実行依頼された場合に割り当てられるジョブ・サイズ要求です。 残りの値は、キューで許可されている他のジョブ・サイズであり、任意の順序で定義できます。

キューとアプリケーション・プロファイル (lsb.applications) の両方で定義されている場合、ジョブ・サイズ要求は両方の要件を満たす必要があります。 さらに、 JOB_SIZE_LIST は、同じレベルで定義されたすべての TASKLIMIT パラメーターをオーバーライドします。 ジョブ・サイズ要件は、ジョブ・サイズ・リストのないキューおよびアプリケーション・プロファイルには適用されません。また、他のレベルのジョブ実行依頼 (つまり、ホスト・レベルまたはクラスター・レベルのジョブ実行依頼) にも適用されません。

有効値

1 から 2147483646 までの正整数のスペース区切りリスト。

デフォルト

未定義

構文

JOB_STARTER=スターター [スターター] ["%USRCMD"] [スターター]

説明

starter は、ジョブを開始するために使用できる (つまり、ジョブを入力引数として受け入れることができる) 任意の実行可能ファイルです。 オプションで、追加のストリングを指定できます。

デフォルトでは、ユーザー・コマンドはジョブ・スターターの後に実行されます。 特殊ストリング %USRCMDを使用して、ジョブ・スターター・コマンド行でのユーザーのジョブの位置を表すことができます。 %USRCMD ストリングおよび追加のコマンドは、引用符 (" ") で囲む必要があります。

ジョブ・スターター・スクリプトが Windows 実行ホスト上で実行され、記号 (& や | など) が含まれている場合は、 lsf.conf で JOB_STARTER_EXTEND=preservestarter パラメーターを使用し、 lsb.queuesで JOB_STARTER=preservestarter を設定できます。 カスタマイズされた userstarter を使用することもできます。

例

JOB_STARTER=csh -c "%USRCMD;sleep 10"

% bsub myjob arguments

% csh -c "myjob arguments;sleep 10"

デフォルト

定義されていません。 ジョブ・スターターは使用されません。

説明

指定された分数の前にジョブが終了すると、LSF は LSF_SERVERDIR/eadmin を呼び出して、ジョブ・アンダーラン例外のアクションを起動します。

例

JOB_UNDERRUN=2

ジョブ・アンダーラン例外は、実行時間が 2 分未満のジョブに対してトリガーされます。

デフォルト

定義されていません。 ジョブ・アンダーラン例外は検出されません。

構文

JOB_WARNING_ACTION=シグナル

説明

ジョブ警告を有効にするには、ジョブ警告アクションをジョブ・アクション警告時間 ( JOB_ACTION_WARNING_TIME パラメーター) とともに指定する必要があります。

JOB_WARNING_ACTION が指定されている場合、LSF は、実際の制御アクションが実行される前に警告アクションをジョブに送信します。 これにより、ジョブ制御アクションによって終了される前に、ジョブ時間がその結果を保管することができます。

bsub -wa オプションで指定された警告アクションは、キュー内の JOB_WARNING_ACTION をオーバーライドします。 コマンド行オプションが指定されていない場合は、 JOB_WARNING_ACTION がデフォルトとして使用されます。

例

JOB_ACTION_WARNING_TIME=2
JOB_WARNING_ACTION=URG

ジョブが実行時限界または終了締切に達するか、キューの実行時間枠がクローズされる 2 分前に、URG シグナルがジョブに送信されます。

デフォルト

未定義

構文

読み込みインデックス=ロードスケジュール[/ロード停止]

指定io,it,ls,mem,pg,r15s,r1m,r15m,swp,tmp,ut、または非共有のカスタム外部ロード索引。 複数の負荷指標のしきい値を構成するには、複数の線を指定します。

指定io,it,ls,mem,pg,r15s,r1m,r15m,swp,tmp,ut、または列としての非共有カスタム外部ロード索引。 複数の負荷指標のしきい値を構成するには、複数の列を指定します。

説明

このloadSchedジョブがホストにディスパッチされる前に条件が満たされていなければなりません。 RESUME_COND が指定されていない場合、loadSchedまた, 中断されたジョブを再開する前に, 条件が満たされていなければなりません。

もしloadStop条件が満たされると、ホスト上のジョブは中断されます。

このloadSchedおよびloadStopしきい値を使用すると、単純な AND/OR ロジックを使用して条件を指定できます。 しきい値が構成されていないロード索引は、ジョブ・スケジューリングに影響しません。

ジョブがホストで実行されている唯一のバッチ・ジョブであり、マシンが対話式にアイドル状態である場合、LSF はジョブを中断しません。it>0).

このr15s,r1mおよびr15mCPU 実行キューの長さ条件は、 lsload -Eによって報告される有効なキューの長さと比較されます。これは、マルチプロセッサー・ホストの場合に正規化されます。 これらのパラメーターのしきい値は、シングル・プロセッサー・ホストに適したレベルに設定する必要があります。

例

MEM=100/10 

SWAP=200/30

mem>=100 && swap>=200 

mem < 10 || swap < 30

デフォルト

未定義

構文

LOCAL_MAX_PREEXEC_RETRY=整数

説明

この制限に達すると、ジョブのデフォルトの動作は、 lsb.params、 lsb.queues、または lsb.applicationsの LOCAL_MAX_PREEXEC_RETRY_ACTION パラメーターによって定義されます。

有効値

0 < max_preexec_retry < infinit_int

INFINIT_INT は、 lsf.hで定義されています。

デフォルト

定義されていません。 preexec の再試行回数に制限はありません

関連資料

lsb.params、 lsb.queues、および lsb.applicationsの LOCAL_MAX_PREEXEC_RETRY_ACTION 。

構文

LOCAL_MAX_PREEXEC_RETRY_ACTION=SUSPEND | EXIT

説明

このパラメーターは、( lsb.params、 lsb.queues、または lsb.applicationsの LOCAL_MAX_PREEXEC_RETRY で指定された) ローカル・クラスターで実行前コマンドを試行する最大回数に達したときのジョブのデフォルト動作を指定します。

• SUSPENDに設定すると、ローカル・ジョブまたは専用ジョブは中断され、その状況は PSUSP に設定されます。
• EXITに設定すると、ローカル・ジョブまたは専用ジョブが終了し、その状況が EXIT に設定されます。 ジョブは、最後の実行前失敗終了コードと同じ終了コードで終了します。

このパラメーターは、クラスター全体 (lsb.params)、キュー・レベル (lsb.queues)、およびアプリケーション・レベル (lsb.applications) で構成されます。 lsb.applications で指定されたアクションは lsb.queuesをオーバーライドし、 lsb.queues は lsb.params 構成をオーバーライドします。

デフォルト

定義されていません。 lsb.paramsで定義されていない場合、デフォルトのアクションは SUSPEND です。

関連資料

lsb.params、 lsb.queues、および lsb.applicationsの LOCAL_MAX_PREEXEC_RETRY 。

構文

MANDATORY_EXTSCHED=外部スケジューラー・オプション (external_scheduler_options)

説明

bsub コマンドの -extsched オプションは MANDATORY_EXTSCHED オプションとマージされ、MANDATORY_EXTSCHED オプションは -extschedによって設定された競合するジョブ・レベル・オプションをオーバーライドします。

デフォルト

未定義

構文

MAX_JOB_PREEMPT=整数

有効値

0 < max_job_preempt < infinit_int

INFINIT_INT は、 lsf.hで定義されています。

デフォルト

定義されていません。 優先使用回数は無制限です。

構文

MAX_JOB_REQUEUE=整数

有効値

0 < max_job_requeue < infinit_int

INFINIT_INT は、 lsf.hで定義されています。

デフォルト

定義されていません。 リキュー回数に制限はありません

構文

MAX_PREEXEC_RETRY=整数

説明

ジョブの実行前コマンドがすべての試行に失敗すると、ジョブは実行依頼クラスターに戻されます。

有効値

0 < max_preexec_retry < infinit_int

INFINIT_INT は、 lsf.hで定義されています。

デフォルト

5

構文

MAX_RSCHED_TIME=整数 | infinit

説明

MAX_RSCHED_TIME * MBD_SLEEP_TIME=timeout

リモート・タイムアウトを無効にするには、 infinit を指定します (マルチクラスター・ジョブのスケジュールが変更されることはないため、ジョブは常に正しい FCFS 順序でディスパッチされますが、マルチクラスター・ジョブは、より適切なキューにスケジュール変更される代わりに、受信ジョブ・キューで永久に保留される可能性があります)。

リモート・タイムアウト制限が事前予約ジョブに影響しない

事前予約を使用するジョブは、常にリモート・タイムアウトが無効になっているかのように動作します。

デフォルト

20 (デフォルトでは 20 分)

構文

MAX_TOTAL_TIME_PREEMPT=分

ここで、 minutes は壁時計時刻であり、正規化された時刻ではありません。

説明

lsb.applications に同じ名前のパラメーターを設定すると、このパラメーターはオーバーライドされます。このパラメーターを設定すると、 lsb.paramsにある同じ名前のパラメーターがオーバーライドされます。

有効値

1 より大きいか等しい任意の正整数

デフォルト

無制限

構文

MC_FORWARD_DELAY=[-]秒

説明

この値が正の場合、 LSF はジョブをリモート・クラスターに転送せず、指定された時間 (秒) だけローカル・ホストを試行します。

この値が負の場合、 LSF はジョブをリモート・クラスターに転送し、指定された時間 (秒) だけローカル・ホストを試行しません。

この指定された遅延時間は、 LSF がジョブを実行依頼してスケジュールした後に開始されます。 この時間が経過すると、このパラメーターは無効になり、 LSF はデフォルトのジョブ転送動作に戻ります。これにより、最初にローカル・ホストが試行され、その後、失敗した場合はジョブがリモート・クラスターに転送されます。

LSF が MAX_RSCHED_TIME パラメーター設定のためにリモート・クラスターからジョブを再呼び出しした場合、 LSF はこれらのステップを繰り返します。 LSF がジョブを再キューイング、中断、または再開した場合、あるいはスケジューラー・デーモンが再始動した場合にも、 LSF はこれらのステップを繰り返します。

有効値

任意の正または負の整数。 0 に設定すると、このパラメーターは無効になります。

デフォルト

0. このパラメーターは使用不可です。

構文

MEMLIMIT=[デフォルトリミット ] 最大リミット

説明

このキューからのジョブに属するすべてのプロセスについて、プロセスごとのハード・プロセス常駐セット・サイズ制限 (KB) を設定するには、このパラメーターを設定します ( getrlimit(2) を参照)。

プロセスに割り振ることができる物理メモリーの最大量 (常駐セット・サイズ、RSS) を設定します。

デフォルトでは、デフォルトのメモリー制限が指定されている場合、ジョブ・レベルのメモリー制限なしでキューに実行依頼されたジョブは、デフォルトのメモリー制限に達すると強制終了されます。

1 つの制限のみを指定した場合、それは最大 (ハード) メモリー制限になります。 2 つの制限を指定した場合、最初の制限はデフォルト、つまりソフト・メモリー制限になり、2 番目の制限は最大メモリー制限になります。

OS メモリー制限の適用

OS メモリー制限の適用は、MEMLIMIT のデフォルトの動作であり、追加の構成は必要ありません。 通常、OS 適用により、プロセスは最終的に完了まで実行できます。 LSF は、MEMLIMIT をシステム・スケジューラーおよびメモリー・アロケーターのガイドとして使用する OS に、MEMLIMIT を渡します。 余剰がある場合、システムはプロセスにより多くのメモリーを割り振る可能性があります。 メモリーが少ない場合、システムは、宣言された MEMLIMIT を超えたプロセスのスケジューリング優先順位 (再ナイス) からメモリーを取得し、スケジューリング優先順位を下げます。 RLIMIT_RSS for setrlimit()をサポートするシステムでのみ使用可能です。

LSF メモリー制限の適用

LSF メモリー制限の適用を有効にするには、 lsf.conf の LSB_MEMLIMIT_ENFORCE を yに設定します。 LSF メモリー制限の適用では、MEMLIMIT を超えてメモリーが割り振られると、実行中のプロセスを強制終了するためのシグナルが明示的に送信されます。

lsf.conf の LSB_JOB_MEMLIMIT を y に設定することで、LSF メモリー制限の適用を有効にすることもできます。 y に設定された LSB_JOB_MEMLIMIT と、y に設定された LSB_MEMLIMIT_ENFORCE の違いは、LSB_JOB_MEMLIMIT では、LSF によって適用されるジョブごとのメモリー制限のみが有効になることです。 OS によって適用されるプロセスごとのメモリー制限が無効になっています。 LSB_MEMLIMIT_ENFORCE を y に設定すると、LSF によって適用されるジョブごとのメモリー制限と OS によって適用されるプロセスごとのメモリー制限の両方が使用可能になります。

LSF が合計メモリー使用量を収集するすべてのシステムで使用可能です。

例

Begin Queue 

QUEUE_NAME  = default 

DESCRIPTION = Queue with memory limit of 5000 kbytes 

MEMLIMIT    = 5000 

End Queue

デフォルト

無制限

構文

MIG=分

説明

LSF は、指定された分数を超えて SSUSP 状態にあったジョブを自動的にマイグレーションします。 中断時に即時にジョブをマイグレーションするには、値 0 を指定します。 マイグレーションしきい値は、ホスト上で実行されているすべてのジョブに適用されます。

ジョブ・レベルのコマンド行マイグレーションしきい値は、アプリケーション・プロファイルおよびキュー内のしきい値構成をオーバーライドします。 アプリケーション・プロファイル構成は、キュー・レベルの構成をオーバーライドします。

ホスト・マイグレーションしきい値が指定され、それがジョブ、キュー、またはアプリケーションの値より小さい場合は、ホスト値が使用されます。

チャンク・ジョブのメンバーは移行できます。 WAIT 状態のチャンク・ジョブは、ジョブ・チャンクから削除され、PEND 状態になります。

リモート・クラスターに転送されるマルチクラスター・ジョブには影響しません。

デフォルト

定義されていません。 LSF は、チェックポイント指定可能ジョブまたは再実行可能ジョブを自動的にマイグレーションしません。

構文

NEW_JOB_SCHED_DELAY=秒

説明

値ゼロ (0) は、ジョブが遅延なしでスケジュールされることを意味します。 スケジューラーは、引き続き定期的に mbatchdからジョブを取り出します。 ジョブが取得されると、スケジューラーはそれらのジョブを遅延なしでスケジュールします。 これにより、ジョブ・スケジューリングの速度が少し上がる可能性がありますが、通信オーバーヘッドもいくらか発生します。 したがって、ワークロードが小さい場合は、優先度が高いキュー、緊急キュー、または対話式キューに対してのみ 0 に設定する必要があります。

NEW_JOB_SCHED_DELAY がゼロ以外の値に設定されている場合、スケジューラーは定期的に mbatchdから新規ジョブをフェッチし、その後、ジョブ・スケジューリング時間をジョブ・サブミット時間 + NEW_JOB_SCHED_DELAYに設定します。

デフォルト

0 秒

構文

NICE=整数

説明

デフォルト値 0 (ゼロ) は、UNIX 対話式ジョブのデフォルトのスケジューリング優先順位を維持します。 この値は、キューごとにバッチ・ジョブの実行時優先順位を調整して、他のバッチ・ジョブまたは対話式ジョブへの影響を制御します。 以下nice(1) 詳細についてはマニュアルページをご覧ください。

Windows 上の LSF はサポートしませんHIGHまたはREAL-TIME優先順位クラス。

この値は、 lsb.applicationsの NICE 設定によって上書きされます (定義されている場合)。

デフォルト

0 (ゼロ)

説明

NO_PREEMPT_INTERVAL=0 パラメーターを使用すると、ジョブの実行が開始または再開されるとすぐに、そのジョブを即時に優先使用することができます。

lsb.applications ファイル内の同じ名前のパラメーターは、このパラメーターをオーバーライドします。 このパラメーターは、 lsb.params ファイル内の同じ名前のパラメーターをオーバーライドします。

デフォルト

0

構文

PEND_TIME_LIMIT=[時:]分

説明

LSF は、キュー・レベルの保留時間制限構成を IBM Spectrum LSF RTM (LSF RTM) に送信します。これにより、ユーザー通知 (例えば、ジョブをサブミットしたユーザーと LSF 管理者への通知) やジョブ制御アクション (例えば、ジョブの強制終了) などのアラームおよびトリガー・アクションが処理されます。 LSF RTM は、ジョブの保留時間を保留時間制限と比較し、ジョブがこの指定された時間制限より長く保留されている場合、 LSF RTM はアラームとアクションをトリガーします。 このパラメーターは LSF RTMなしで機能しますが、LSF はその他のアラーム・アクションを実行しません。

マルチクラスター・ジョブ転送モードでは、実行クラスター内のジョブの保留時間制限は無視されます。一方、実行依頼クラスターは、ローカル設定に従ってジョブのキュー・レベル、アプリケーション・レベル、およびジョブ・レベルの保留時間制限をマージします。

保留時間制限は、[hour:]minuteの形式です。 分は 59 より大きい数値で指定できます。 例えば、3 時間半を 3:30 または 210 のいずれかとして指定できます。

ジョブ・レベルの保留時間制限 (bsub -ptl) は、アプリケーション・レベルの制限 ( lsb.applicationsのPEND_TIME_LIMIT ) をオーバーライドし、アプリケーション・レベルの制限は、ここで指定したキュー・レベルの制限をオーバーライドします。

デフォルト

定義されていません。

構文

PJOB_LIMIT=浮動

説明

このキューが任意のプロセッサーで使用できるジョブ・スロットの最大数。 この制限はプロセッサーごとに構成されるため、マルチプロセッサー・ホストは自動的により多くのジョブを実行します。

デフォルト

無制限

構文

PLAN = Y | N | "<key>[value] ..."

説明

LSF では、 PLAN=Yを使用するために ALLOCATION_PLANNER パラメーターが有効になっている必要があります。

クラスター・レベルおよびアプリケーション・レベルでも定義されます。 優先順位は、アプリケーション、キュー、グローバルです。 例えば、アプリケーション・レベルの設定は、キュー・レベルの設定をオーバーライドします。

以下のキーと値のペアがサポートされています。

デフォルト

N

説明

POST_EXEC コマンドは、ジョブの終了後に実行ホスト上で実行されます。 実行後コマンドは、アプリケーション・レベルおよびキュー・レベルで構成できます。 アプリケーション・レベルの実行後コマンドは、キュー・レベルの実行後コマンドの 前 に実行されます。

POST_EXEC コマンドは、ジョブと同じ環境変数値を使用します。デフォルトでは、ジョブを実行依頼するユーザーのユーザー・アカウントで実行されます。 別のユーザー・アカウント (特権操作の場合は root など) で実行後コマンドを実行するには、 lsf.sudoersでパラメーター LSB_PRE_POST_EXEC_USER を構成します。

ジョブがキューの REQUEUE_EXIT_VALUESの 1 つで終了すると、LSF はジョブを再びキューに入れ、環境変数 LSB_JOBPENDを設定します。 実行後コマンドは、再キューイングされたジョブが終了した後に実行されます。

実行後コマンドが実行されると、環境変数 LSB_JOBEXIT_STAT がジョブの終了状況に設定されます。 ジョブの実行環境をセットアップできない場合、 LSB_JOBEXIT_STAT は 0 (ゼロ) に設定されます。

コマンド・パスには、UNIX および Linuxの場合は最大 4094 文字、Windows の場合は最大 255 文字を使用できます。これには、%J (job_ID) および %I (index_ID) のディレクトリー、ファイル名、および拡張値が含まれます。

デフォルト

定義されていません。 実行後コマンドがキューに関連付けられていません。

説明

PRE_EXEC コマンドは、ジョブの開始前に実行ホスト上で実行されます。 PRE_EXEC コマンドがゼロ以外の終了コードで終了した場合、LSF はジョブをキューの先頭に再キューイングします。

PRE_EXEC コマンドは、ジョブと同じ環境変数値を使用し、ジョブを実行依頼するユーザーのユーザー・アカウントで実行されます。 別のユーザー・アカウント (特権操作の場合は root など) で実行前コマンドを実行するには、 lsf.sudoersでパラメーター LSB_PRE_POST_EXEC_USER を構成します。

コマンド・パスには、UNIX および Linuxの場合は最大 4094 文字、Windows の場合は最大 255 文字を使用できます。これには、%J (job_ID) および %I (index_ID) のディレクトリー、ファイル名、および拡張値が含まれます。

デフォルト

定義されていません。 実行前コマンドがキューに関連付けられていません。

説明

例: キュー間の優先使用の選択的な順序付けの構成

Begin Queue
QUEUE_NAME=high
PREEMPTION=PREEMPTIVE
PRIORITY=99
End Queue

Begin Queue
QUEUE_NAME=medium
PREEMPTION=PREEMPTIVE[normal low+1]
PRIORITY=10
End Queue

Begin Queue
QUEUE_NAME=normal
PREEMPTION=PREEMPTIVE[low]
PREEMPTABLE[high medium]
PRIORITY=5
End Queue

Begin Queue
QUEUE_NAME=low
PRIORITY=1
End Queue

説明

猶予期間中、優先使用はトリガーされませんが、他のスケジューリング・ポリシーによってジョブをスケジュールおよびディスパッチすることができます。

この機能により、優先使用の数を減らすためにシステムを柔軟に調整することができます。 パフォーマンスとジョブ・スループットを向上させるのに役立ちます。 優先順位の低いジョブが短い場合、優先順位の高いジョブが優先順位の低いジョブの終了をしばらく待つことができれば、優先使用を回避してクラスターのパフォーマンスを向上させることができます。 猶予期間が経過してもジョブがまだ保留中の場合は、優先使用がトリガーされます。

待ち時間は、保留状況のプリエンプティブ・ジョブの場合のみです。 中断されているプリエンプティブ・ジョブには影響しません。

この時間は、ジョブの実行依頼時刻からカウントされます。 サブミット時とは、 mbatchd がジョブを受け入れる時間を意味します。これには、新たにサブミットされたジョブ、再始動されたジョブ ( brestartによる)、またはリモート・クラスターから転送されたジョブが含まれます。

プリエンプティブ・ジョブが待機中の場合、保留中の理由は以下のとおりです。

プリエンプティブ・ジョブは、優先使用前の猶予期間を許可しています。

古いバージョンの bjobsを使用している場合、保留中の理由は以下のとおりです。

不明な保留理由コード < 6701>;

このパラメーターは、 lsb.params、 lsb.queues (指定変更 lsb.params)、および lsb.applications ( lsb.params と lsb.queuesの両方を指定変更) で定義されます。

badmin reconfig を実行して、変更を有効にします。

デフォルト

未定義 (パラメーターがどこにも定義されていない場合、優先使用は即時です)。

説明

LSF は、最高優先順位のキューから始めて、一度に 1 つのキューからジョブをスケジュールします。 複数のキューの優先順位が同じ場合、LSF は、これらのキューからのすべてのジョブを先着順でスケジュールします。

LSF キュー優先順位は、タイム・シェアリング・プロセスの UNIX スケジューラー優先順位システムから独立しています。 LSF では、NICE パラメーターを使用して、バッチ・ジョブの UNIX タイム・シェアリング優先順位を設定します。

デフォルト

1

構文

PROCESSLIMIT=[default_limit ] 最大リミット

説明

デフォルトでは、デフォルトのプロセス制限が指定されている場合、ジョブ・レベルのプロセス制限なしでキューに実行依頼されたジョブは、デフォルトのプロセス制限に達すると強制終了されます。

制限を 1 つしか指定しない場合は、プロセスの最大制限 (ハード制限) になります。 2 つの制限を指定した場合、最初の制限はデフォルト (ソフト) のプロセス制限、2 番目の制限は最大プロセス制限です。

デフォルト

無制限

構文

QJOB_LIMIT=整数

説明

このパラメーターは、このキューが使用できるジョブ・スロットの総数を指定します。

デフォルト

無制限

構文

QUEUE_GROUP=queue1, queue2 ...

説明

APS_PRIORITYを使用してキューで APS が有効になっている場合、 FAIRSHARE_QUEUES パラメーターは無視されます。 QUEUE_GROUP パラメーターは、 LSF 7.0で廃止された FAIRSHARE_QUEUESを置き換えます。

デフォルト

未定義

構文

QUEUE_NAME=ストリング

説明

最大 59 文字の ASCII ストリングを指定します。 文字、数字、下線 (_)、またはダッシュ (-) を使用できます。 ブランク・スペースは使用できません。 予約名を指定することはできませんdefault.

デフォルト

キューを定義するには、このパラメーターを指定する必要があります。 LSF によって自動的に作成されるデフォルト・キューは、次の名前になります。default.

説明

RC_ACCOUNT パラメーターを指定してジョブがキューにサブミットされると、ジョブを実行するために借用されたホストには、 RC_ACCOUNT パラメーターの値のタグが付けられます。 借用したホストを、 RC_ACCOUNT パラメーターの値が異なる (または RC_ACCOUNT パラメーターが定義されていない) 他のキューで使用することはできません。

借用したホストがクラスターに参加した後、 lshosts -s コマンドを使用して、ホストの RC_ACCOUNT パラメーターの値を表示します。

例

RC_ACCOUNT=project1

デフォルト

ストリング "default"-意味。キューに対してアカウントが定義されていません。

説明

RC_DEMAND_POLICY パラメーターによって定義されるデマンド・ポリシーには、 OR 関係の複数の条件を含めることができます。 条件は、 [ num_pend_jobs[,duration]]として定義されます。 キューに、少なくとも指定された所要時間 (分単位) で実行することが予期される、指定された数を超える適格な保留ジョブがあります。 num_pend_jobs オプションは必須で、所要時間はオプションです。 デフォルトの所要時間は 0 分です。

LSF は、ポリシーに対して適格な保留ジョブを考慮します。 不適格な保留中のジョブ (例えば、ジョブ依存関係がまだ満たされていない) は、ホストが使用可能であると考えられる場合でも、保留中のままになります。 ポリシーは、ジョブが必要とするタスクまたはスロットの数に関係なく、ジョブの適格性をカウントします。 各ジョブ・エレメントは 1 つのジョブとしてカウントされます。 サイズ変更可能ジョブに対する保留中の要求はカウントされませんが、 LSF は、サイズ変更可能ジョブに借用リソースを割り振ることができます。

LSF は、需要計算サイクルごとにポリシーを評価し、 num_pend_jobs オプションが満たされると期間を累積します。 mbschd デーモンは、再始動時、または過去 2 分間に条件が評価されなかった場合に、条件の期間をリセットします。 例えば、クラスター内に保留中のジョブがない場合、 mbschd はそれらの評価を 2 分間停止します。

例

RC_DEMAND_POLICY = THRESHOLD[ [ 5, 10] [1, 60] [100] ]

デフォルト

キューに定義されていない

説明

host_type フラグは、 lsf.conf ファイル内の LSB_RC_EXTERNAL_HOST_FLAG パラメーターで定義されているホスト・リソースのリストのメンバーであるブール・リソースです。

RC_HOSTS パラメーターがキューに定義されていない場合、そのデフォルト値は noneです。 LSB_RC_EXTERNAL_HOST_FLAG パラメーターが lsf.conf ファイルで定義されている場合でも、 RC_HOSTS=noneを明示的に定義するキューに対しては、借用が無効になります。

RC_HOSTS パラメーターがどのキューにも定義されていない場合は、どのジョブに対しても借用することはできません。

例

RC_HOSTS=awshost

デフォルト

none -リソース・プロバイダーからのホストの借用は無効になり、借用したホストをキューで使用することはできません。

構文

RCVJOBS_FROM=クラスタ名...| allclusters

説明

クラスター名をスペースで区切って指定します。 各リモート・クラスターの管理者は、そのクラスター内のどのキューがローカル・クラスターにジョブを転送するかを決定します。

LSF データ・マネージャー・データ転送キューを実行クラスター内のリモート送信ジョブ・キューとして使用可能にした場合 (つまり、実行クラスター内の lsb.queues ファイル内の SNDJOBS_TO パラメーターに実行クラスターからキューを追加した場合)、対応する実行依頼クラスター内の RCVJOBS_FROM パラメーターに実行クラスターを含める必要があります。

リモート・クラスターを指定するには、キーワード allclusters を使用します。

例

以下のキューは、クラスター 2、4、および 6 からのリモート・ジョブを受け入れます。

RCVJOBS_FROM=cluster2 cluster4 cluster6

LSF データ・マネージャーの例

実行クラスター clusterE の LSF データ・マネージャー転送キュー data_transfer が、 clusterE クラスターの以下の構成に従って、リモート送信ジョブ・キューとしてサブミット・クラスター clusterSの receive_q キューに設定されているとします。

Begin Queue
QUEUE_NAME=data_transfer
DATA_TRANSFER=Y
SNDJOBS_TO=receive_q@clusterS
HOSTS=hostS1 hostS2 # Transfer nodes in the execution cluster
End Queue

clusterS クラスターの以下の構成に示すように、実行クラスター clusterEからジョブを受け入れる (および実行クラスターにデータをプッシュする) には、実行クラスター clusterS 内の receive_q キューに対して RCVJOBS_FROM パラメーターを定義する必要があります。

Begin Queue
QUEUE_NAME=receive_q
RCVJOBS_FROM=clusterE
PRIORITY=40
HOSTS=hostS1 hostS2 # Transfer nodes in the submission cluster
RES_REQ=select[type==any]
End Queue

あるいは、実行クラスターを含むすべてのクラスターからジョブを受け入れるように RCVJOBS_FROM=allclusters を定義することもできます。

構文

RELAX_JOB_DISPATCH_ORDER=Y | y | N | n | ALLOC_REUSE_DURATION[ [ 最小 ] 最大] [SHARE[ [user ] [group ] [project ]] ]

説明

このパラメーターを有効にすると、LSF では、共通のリソース要件を持つ複数のジョブを同じ割り振りで連続して実行することができます。 ジョブが終了するたびに、LSF はそのジョブを、同じリソース要件を持つ保留中のジョブに素早く置き換えようとします。 制限に違反しないようにするために、LSF は、同じユーザーに属し、共通の他の属性を持つ保留中のジョブを選択します。

LSF は、ジョブ間の標準スケジューリング・ロジックのほとんどをバイパスするため、リソース割り振りを再使用すると、クラスターの使用率を向上させることができます。 この改善は、複数の短いジョブ (つまり、数秒から数分の間に実行されるジョブ) を持つクラスターで最も顕著に見られます。

標準のジョブ優先順位付けポリシーが近似されるようにするために、各割り振りが再使用可能な時間の長さに制限があります。 LSF は、高いレベルのリソース使用率を達成するために、この時間制限を自動的に設定します。 デフォルトでは、この再利用時間は 30 分を超えることはできません。 最大再使用時間とオプションの最小再使用時間 ( ALLOC_REUSE_DURATIONを使用) を指定すると、LSF はこの指定された範囲内の時間制限を調整して、リソース使用率の最高レベルを達成します。

未定義の場合、同じ名前の lsb.params パラメーターからのクラスター全体の値が使用されます。

例

• RELAX_JOB_DISPATCH_ORDER=Y
  

  終了したジョブのリソース割り振りは、0 分から 30 分まで再利用できます。

• RELAX_JOB_DISPATCH_ORDER=ALLOC_REUSE_DURATION[45]

  終了したジョブのリソース割り振りは、0 分から 45 分まで再利用できます。

• RELAX_JOB_DISPATCH_ORDER=ALLOC_REUSE_DURATION[5 45]

  終了したジョブのリソース割り振りは、5 分から 45 分の間で再利用できます。

• RELAX_JOB_DISPATCH_ORDER=SHARE[user]

  終了したジョブのリソース割り振りは、0 分から 30 分まで再利用できます。 同じ共通属性を持つ保留中のジョブがない場合、別のユーザーに属する保留中のジョブもリソース割り振りを再利用できます。

• RELAX_JOB_DISPATCH_ORDER=SHARE[user group]

  終了したジョブのリソース割り振りは、0 分から 30 分まで再利用できます。 同じ共通属性を持つ保留中のジョブがない場合、異なるユーザーに属し、異なるフェア・シェア・グループに関連付けられている保留中のジョブも、リソース割り振りを再使用できます。

• RELAX_JOB_DISPATCH_ORDER=ALLOC_REUSE_DURATION[45] SHARE[user group]

  終了したジョブのリソース割り振りは、0 分から 45 分まで再利用できます。 同じ共通属性を持つ保留中のジョブがない場合、異なるユーザーに属し、異なるフェア・シェア・グループに関連付けられている保留中のジョブも、リソース割り振りを再使用できます。

デフォルト

定義されていません。

構文

REMOTE_MAX_PREEXEC_RETRY=整数

説明

このパラメーターは、実行クラスターに適用されます。

有効値

0 から INFINIT_INT

INFINIT_INT は、 lsf.hで定義されています。

デフォルト

5

構文

REQUEUE_EXIT_VALUES=[exit_code...] [EXCLUDE(exit_code...)]

説明

複数の終了コードを区切るには、スペースを使用します。 アプリケーション・レベルの終了値は、キュー・レベルの値をオーバーライドします。 ジョブ・レベルの終了値 (bsub -Q) は、アプリケーション・レベルおよびキュー・レベルの値をオーバーライドします。

"[all] [~number ...] | [number ...]"

予約キーワード all は、すべての終了コードを指定します。 通常、終了コードは 0 から 255 までです。 ティルド (~) を使用して、指定した終了コードをリストから除外します。

ジョブは、キューの先頭に再キューイングされます。 失敗した実行からの出力は保存されず、ユーザーは LSF から通知されません。

終了コードを EXCLUDE (exit_code) として定義して、排他的ジョブ・リキューを使用可能にし、ジョブが samehost 上で再実行されないようにします。 排他的ジョブ・リキューは、並列ジョブに対しては機能しません。

リモート実行クラスターに転送されたマルチクラスター・ジョブの場合、EXCLUDE キーワードを使用して実行依頼クラスターに指定された終了値は、非排他的なものとして扱われます。

ジョブがシグナルによって終了された場合は、ジョブを再キューイングすることもできます。

ジョブがシグナルによって強制終了された場合、終了値は 128 +signal_valueです。 128 とシグナル値の合計は、REQUEUE_EXIT_VALUES パラメーターの終了コードとして使用できます。

例えば、シグナル 9 (SIGKILL) で強制終了されたジョブを再実行したい場合、終了値は 128 + 9 = 137 になります。 以下のリキュー終了値を構成して、ジョブがシグナル 9 によって強制終了された場合に、そのジョブをリキューできるようにすることができます。

REQUEUE_EXIT_VALUES=137

Windows では、ジョブがシグナルによって強制終了されると、終了値は signal_value になります。 シグナル値は、パラメーター REQUEUE_EXIT_VALUES の終了コードとして使用できます。

例えば、シグナル 7 (SIGKILL) で強制終了されたジョブを再実行したい場合、終了値は 7 になります。 ジョブがシグナル 7 によって強制終了された後に再キューイングできるように、以下の再キューイング終了値を構成することができます。

REQUEUE_EXIT_VALUES=7

以下の再キューイング終了値を構成して、ジョブが強制終了された後に Linux と Windows の両方で再キューイングできるようにすることができます。

REQUEUE_EXIT_VALUES=137 7

mbatchd を再始動すると、ジョブが排他的リキュー出口コードで終了した前のホストを記憶しません。 この状況では、ジョブが以前に排他的終了コードで終了したホストに、そのジョブがディスパッチされる可能性があります。

割り込み可能バックフィル・キューの REQUEUE_EXIT_VALUES を構成する必要があります (INTERRUPTIBLE_BACKFILL=seconds)。

例

REQUEUE_EXIT_VALUES=30 除外 (20)

終了コード 30 のジョブは再キューイングされ、終了コード 20 のジョブは排他的に再キューイングされ、その他の終了コードのジョブは再キューイングされないことを意味します。

デフォルト

定義されていません。 ジョブは再キューイングされません。

構文

RERUNNABLE=yes | no

説明

yes に設定すると、自動ジョブ再実行 (再始動) が有効になります。

RERUNNABLE が noに設定されている場合、再実行は無効になります。 引数 yes および no は大/小文字を区別しません。

マルチクラスター・ジョブの場合、実行依頼キューの設定が使用され、実行キューの設定は無視されます。

チャンク・ジョブのメンバーは再実行できます。 実行ホストが使用不可になると、再実行可能なチャンク・ジョブ・メンバーがジョブ・チャンクから削除され、別の実行ホストにディスパッチされます。

デフォルト

いいえ

構文

RESOURCE_RESERVE=MAX_RESERVE_TIME[整数]

説明

ジョブがジョブ・スロットおよびメモリーを予約できるディスパッチ・ターンの数 (MAX_RESERVE_TIME) を指定します。

SLOT_RESERVE パラメーターをオーバーライドします。 RESOURCE_RESERVE と SLOT_RESERVE の両方が同じキューに定義されている場合、クラスターの再構成時にエラーが表示され、SLOT_RESERVE は無視されます。 リソース予約と並列バッチ・ジョブ (schmod_parallel および schmod_reserve) の両方の LSF スケジューラー・プラグイン・モジュール名が lsb.modules ファイルで構成されている場合、パラレル・ジョブのジョブ・スロット予約は RESOURCE_RESERVE によって使用可能になります。 schmod_parallel 名は、 lsb.modulesの schmod_reserve の前に なければなりません 。

MAX_RESERVE_TIME が満了するまでに開始できる十分なメモリーまたはジョブ・スロットが累積されていない場合、ジョブは予約済みのすべてのジョブ・スロットまたはメモリーを解放して、他の保留中のジョブを実行できるようにします。 予約時間が満了すると、ジョブは 1 つのスケジューリング・セッション用にメモリーまたはスロットを予約できないため、他のジョブがディスパッチされる可能性があります。 1 つのスケジューリング・セッションの後、ジョブは、MAX_RESERVE_TIME で指定された別の期間に使用可能なメモリーとジョブ・スロットを再度予約できます。

BACKFILL がキュー内に構成されており、実行制限が bsub 上の -W またはキュー内の RUNLIMIT で指定されている場合、バックフィル・ジョブは、キュー内の他のジョブによって予約されている累積メモリーを使用することができます。ただし、バックフィル・ジョブが、予約を使用しているジョブの予測開始時刻より前に終了できる場合に限ります。

並列ジョブにのみ適用されるスロット予約とは異なり、メモリーの予約とメモリーのバックフィルは、順次ジョブと並列ジョブに適用されます。

例

RESOURCE_RESERVE=MAX_RESERVE_TIME[5]

この例では、ジョブに最大 5 つのディスパッチ・ターンがあり、十分なジョブ・スロットまたはメモリー (デフォルトでは 5 分) を予約することを指定しています。

デフォルト

定義されていません。 ジョブ・スロットもメモリーも予約されていません。

構文

RES_REQ=res_req (res_req)

説明

通常どおりにリソース要件ストリングを指定します。 リソース要件ストリングを使用すると、負荷しきい値を使用するよりも柔軟な方法で条件を指定できます。 リソース要件ストリングは、単純 (ジョブ全体に適用)、複合 (指定された数のスロットに適用)、または代替リソース (2 つ以上の単純または複合 (あるいはその両方) の代替) を含むことができます。 代替リソースの場合、最初のリソース要件を満たす最初のリソースが見つからない場合は、次のリソース要件が試行され、要件が満たされるまで以下同様です。

複合リソース要件と代替リソース要件は、ジョブ・レベル、アプリケーション・レベル、およびキュー・レベルの間でリソース要件がどのようにマージされるかを決定するための同じ一連の規則に従います。

キューに対して複合リソース要件または代替リソース要件が設定されている場合、それが指定された唯一のリソース要件でない限り、無視されます (リソース要件はジョブ・レベルまたはアプリケーション・レベルで設定されません)。

キューに対して単純なリソース要件が設定され、複合リソース要件がジョブ・レベルまたはアプリケーション・レベルで設定されている場合、キュー・レベルの要件は、単純なリソース要件の場合と同様にマージされます。 ただし、キューに定義されているジョブ・ベースのリソースは、マージされた複合リソース要件の最初の用語にのみ適用されます。

選択セクション内のリソース要件ストリングは、より厳密な構文に準拠している必要があります。 厳密なリソース要件構文は、 select セクションにのみ適用されます。 他のリソース要件セクション (order、 rusage、 same、 span、 cu 、または affinity) には適用されません。 LSF は、 rusage セクションに使用できないリソースが含まれているリソース要件ストリングを拒否します。

単純なリソース要件の場合は、以下のようになります。selectすべてのレベルのセクションが満たされ、すべてのレベルの 同じ セクションが結合されている必要があります。 ジョブ・レベルの cu、 order、および span セクションは、キュー・レベルのセクションを上書きするアプリケーション・レベルのセクションを上書きします。 複数の rusage 定義がマージされ、ジョブ・レベルの rusage がアプリケーション・レベルより優先され、アプリケーション・レベルがキュー・レベルより優先されます。

単純なリソース要件rusageセクションで追加の要求を指定できます。 これを行うには、以下を使用します。OR(||) 追加を分離する演算子rusageストリング。 複数フェーズの rusage リソース要件では、複数の -R オプションを使用できません。

単純なリソース要件の場合、ジョブ・レベルの affinity セクションはアプリケーション・レベルをオーバーライドし、アプリケーション・レベルのアフィニティー・セクションはキュー・レベルをオーバーライドします。

このorderジョブ・レベルで定義されたセクションは、アプリケーション・レベルまたはキュー・レベルで指定されたすべてのリソース要件を上書きします。 このorderアプリケーション・レベルで定義されたセクションは、キュー・レベルで指定されたすべてのリソース要件を上書きします。 The defaultorderストリング:r15s:pg.

RES_REQ がキュー・レベルで定義されていて、ロードしきい値が定義されていない場合、個々のロード索引の保留理由は bjobsによって表示されません。

このspanの場合には, 待ち行列レベルで定義されたセクションは無視されます。spanセクションは、ジョブ・レベルまたはアプリケーション・プロファイルでも定義されます。

デフォルト

select [type == local] order [r15s:pg]。 このパラメーターが定義されていて、ホスト・モデルまたはブール・リソースが指定されている場合、デフォルトのタイプは anyです。

構文

RESRSV_LIMIT=[res1= {min1,} max1] [res2= {min2,} max2] ...

ここで、 res は利用可能なリソース名、 min はオプションの最小値、 max は最大許容値です。 max と min は両方とも 0 から 2147483647 までの浮動小数点数でなければならず、 min は maxより大きくすることはできません。

説明

キュー・レベルの RES_REQ rusage 値 ( lsb.queuesで設定) は、 RESRSV_LIMITで設定された範囲内になければなりません。そうしないと、キュー・レベルの RES_REQ は無視されます。 マージ RES_REQrusageジョブ・レベルおよびアプリケーション・レベルの値は、 RESRSV_LIMITの範囲内でなければなりません。そうでない場合、ジョブは拒否されます。

bmod -R を使用して実行中のジョブの rusage 値に加えられた変更は、 RESRSV_LIMITの最大値を超えることはできませんが、最小値より小さくすることはできます。

RES_REQ と RESRSV_LIMIT の両方が lsb.queues でコンシューム可能リソースに対して設定されている場合、キュー・レベル RES_REQ は、マージされた RES_REQ のハード・リミットとして機能しなくなります。rusageジョブ・レベルおよびアプリケーション・レベルからの値。 この場合、 RESRSV_LIMIT によって設定された制限のみを満たす必要があり、キュー・レベルの RES_REQ がデフォルト値として機能します。

マルチクラスターの場合、ジョブは、実行依頼クラスター内の送信ジョブ・キューに設定された RESRSV_LIMIT 範囲を満たす必要があります。 ジョブが転送されると、実行クラスター内の受信ジョブ・キューに設定された RESRSV_LIMIT 範囲に対してリソース要件も検査されます。

デフォルト

定義されていません。

max が定義されていて、オプションの min が定義されていない場合、 min のデフォルトは 0 です。

構文

RESUME_COND=res_req (res_req)

使用 -selectロードしきい値を指定するためのリソース要件ストリングのセクション。 他のすべてのセクションは無視されます。

説明

LSF は、ホスト上のロードが指定された条件を満たす場合、このキュー内の中断された (SSUSP) ジョブを自動的に再開します。 条件は、ロード索引と静的ブール・リソースのみをサポートします。

RESUME_COND が定義されていない場合、ジョブの再開を制御するために loadSched しきい値が使用されます。 RESUME_COND が定義されている場合、ジョブの再開時に loadSched しきい値は無視されます。

デフォルト

定義されていません。 loadSched しきい値は、ジョブの再開を制御するために使用されます。

構文

RUN_JOB_FACTOR=番号

説明

ユーザーの動的共用優先順位の計算では、この要因によって、ユーザーが予約して使用しているジョブ・スロットの数の相対的な重要度が決まります。

未定義の場合、同じ名前の lsb.params パラメーターからのクラスター全体の値が使用されます。

デフォルト

定義されていません。

構文

RUN_TIME_DECAY=Y | y | N | n

説明

ユーザーの動的共用優先順位の計算では、この要因によって、実行時間が減分されるかどうかが決まります。

未定義の場合、同じ名前の lsb.params パラメーターからのクラスター全体の値が使用されます。

制約事項

ジョブの実行時間中に badmin reconfig 、または mbatchd を再起動すると、減衰した実行時間が再計算されます。

実行時の減衰を使用して中断されたジョブが再開されると、減衰時間は経過時間に基づきます。

デフォルト

未定義

構文

RUN_TIME_FACTOR=番号

説明

ユーザーの動的共用優先順位の計算では、この要因によって、ユーザーが実行中のジョブの合計実行時間の相対的な重要度が決まります。

未定義の場合、同じ名前の lsb.params パラメーターからのクラスター全体の値が使用されます。

デフォルト

定義されていません。

構文

RUN_WINDOW=時間枠 ...

説明

ウィンドウが閉じると、LSF はキューで実行中のジョブを中断し、キューからのジョブのディスパッチを停止します。 ウィンドウが再オープンすると、LSF は延期されたジョブを再開し、追加のジョブのディスパッチを開始します。

デフォルト

定義されていません。 キューは常にアクティブです。

構文

RUNLIMIT=[デフォルトリミット ] 最大リミット

ここで、 default_limit および maximum_limit は以下のとおりです。

[時:]分[/host_name |/host_model]

説明

デフォルトでは、指定された最大実行制限より長い実行状態 (ただし、実行前または実行後ではない) のジョブは、LSF によって強制終了されます。 オプションで、独自の終了ジョブ・アクションを指定して、このデフォルトをオーバーライドすることができます。

最大実行限界より小さいジョブ・レベル実行限界 (bsub -W) で実行依頼されたジョブは、ジョブ・レベル実行限界に達すると強制終了されます。 最大実行限界より大きい実行限界で投入されたジョブは, 待ち行列によって拒否されます。

1 つの制限のみを指定した場合は、最大またはハードの実行制限になります。 2 つの制限を指定する場合、最初の制限はデフォルト (ソフト) の実行制限、2 番目の制限は最大実行制限です。

実行制限は、[hour:] 分の形式です。 分は 59 より大きい数値で指定できます。 例えば、3 時間半を 3:30 または 210 のいずれかとして指定できます。

指定する実行制限は、正規化された実行時間です。 これは、ジョブが CPU の高速または低速のホストに送信される場合でも、ジョブがほぼ同じ量の処理を行うようにするために行われます。 正規化された実行時間が指定されると、実行ホスト上の実際の時間は、指定された時間に正規化ホストの CPU 係数を乗算し、実行ホストの CPU 係数で除算した時間になります。

lsb.paramsで ABS_RUNLIMIT=Y が定義されている場合、ランタイム制限はホスト CPU 係数によって正規化されません。 絶対壁時計時刻は、実行制限が構成されているキューに実行依頼されたすべてのジョブに使用されます。

オプションで、LSF に定義されているホスト名またはホスト・モデル名を指定できます。 ' を挿入する必要があります/「 実行制限とホスト名またはモデル名の間。 (ホスト・モデル情報を取得するには、 lsinfo(1) を参照してください。)

ホストまたはホスト・モデルが指定されていない場合、LSF は、キュー・レベル ( lsb.queuesでは DEFAULT_HOST_SPEC) で定義されているデフォルトのランタイム正規化ホストを使用します。それ以外の場合、LSF は、クラスター・レベル ( lsb.paramsでは DEFAULT_HOST_SPEC) で定義されているデフォルトの CPU 時間正規化ホストを使用します。

マルチクラスター・ジョブの場合、他の CPU 時間正規化ホストが定義されておらず、実行依頼ホストに関する情報が使用できない場合、LSF は CPU 係数が最大のホスト (クラスター内で最も速いホスト) を使用します。

RUNLIMIT が 30 分を超える場合、チャンク・ジョブ・キューに実行依頼されたジョブはチャンク化されません。

INTERRUPTIBLE_BACKFILL を使用して構成されたキューには RUNLIMIT が必要です。

デフォルト

無制限

構文

SLA_GUARANTEES_IGNORE=Y| y | N | n

説明

SLA_GUARANTEES_IGNORE=Y は、キュー内のジョブが、保証されたすべてのリソースにアクセスできるようにします。 その結果、一部の保証が適用されない場合があります。 キューにこのパラメーターが設定されていない場合、このキュー内のジョブは SLA ジョブの優先使用をトリガーできません。 SLA ジョブが (例えば、 bstopによって) 中断された場合でも、パラメーターが設定されていないキュー内のジョブは、中断されたジョブによって解放されたスロットを使用できます。

デフォルト

未定義 (N)。 キューは、ジョブのディスパッチ時にリソースの保証に従う必要があります。

構文

SLOT_RESERVE=MAX_RESERVE_TIME[整数]

説明

キーワード MAX_RESERVE_TIME と、ジョブがジョブ・スロットを予約できる MBD_SLEEP_TIME サイクルの数を大括弧で囲んで指定します。 MBD_SLEEP_TIME は lsb.paramsで定義されます。デフォルト値は 60 秒です。

予約の有効期限が切れる前に開始できるだけの十分なジョブ・スロットが累積されていない場合、ジョブは予約されているすべてのジョブ・スロットを解放して、他のジョブを実行できるようにします。 この場合、ジョブは 1 つのスケジューリング・セッション用にスロットを予約できないため、他のジョブがディスパッチされる可能性があります。 1 つのスケジューリング・セッションの後、ジョブは、SLOT_RESERVE によって指定された別の期間にジョブ・スロットを再度予約することができます。

SLOT_RESERVE は RESOURCE_RESERVE パラメーターによってオーバーライドされます。

RESOURCE_RESERVE と SLOT_RESERVE の両方が同じキューに定義されている場合は、ジョブ・スロット予約とメモリー予約が有効になり、クラスターの再構成時にエラーが表示されます。 SLOT_RESERVE は無視されます。

リソース予約と並列バッチ・ジョブ (schmod_parallel および schmod_reserve) の両方の LSF スケジューラー・プラグイン・モジュール名が lsb.modules ファイルで構成されている場合、パラレル・ジョブのジョブ・スロット予約は RESOURCE_RESERVE によって使用可能になります。 schmod_parallel 名は、 lsb.modulesの schmod_reserve の前に なければなりません 。

キュー内に BACKFILL が構成されていて、ジョブ・レベル (bsub -W)、アプリケーション・レベル ( lsb.applicationsの RUNLIMIT)、またはキュー・レベル ( lsb.queuesの RUNLIMIT) で実行制限が指定されている場合、またはアプリケーション・レベル ( lsb.applicationsの RUNTIME) で推定実行時間が指定されている場合、バックフィル並列ジョブは、他のジョブによって予約されているジョブ・スロットを使用することができます。

順次ジョブと並列ジョブの両方に適用されるメモリー予約とは異なり、スロット予約は並列ジョブにのみ適用されます。

例

SLOT_RESERVE=MAX_RESERVE_TIME[5]

この例では、開始するのに十分なジョブ・スロットを予約するために、並列ジョブに最大 5 サイクルの MBD_SLEEP_TIME (デフォルトでは 5 分) を指定します。

デフォルト

定義されていません。 予約されているジョブ・スロットはありません。

構文

SNDJOBS_TO=[queue@]cluster_name[+preference] ...

説明

リモート・キュー名は、 queue_name@cluster_name[+preference]の形式でスペースで区切って指定します。

lsb.queues HOSTS がリモート (借用) リソースを指定する場合、このパラメーターは無視されます。

キュー設定は、転送されたジョブを受信する対応する実行クラスター・キューごとに、実行依頼クラスターの SNDJOBS_TO 内のキュー・レベルで定義されます。

LSF データ・マネージャー・データ転送キューを、実行クラスター内のリモート送信ジョブ・キューとして使用可能にすることができます。

実行クラスター内のデータ転送キューに SNDJOBS_TO パラメーターを使用してリモート・キューを指定する場合は、 FILE_TRANSFER_CMD パラメーターのパスが実行依頼クラスター内に存在している必要があります。 さらに、サブミット・クラスター内の対応するリモート・キューは、データ転送ジョブを受信するように構成する必要があります (つまり、サブミット・クラスター内のリモート・キューの RCVJOBS_FROM パラメーター値にこの実行クラスターが含まれているか、または allclustersに設定されている必要があります)。 これにより、実行依頼クラスターがデータ・ファイルを実行クラスターにプッシュして戻すことができます。

例

SNDJOBS_TO=queue2@cluster2+1 queue3@cluster2+2

LSF データ・マネージャーの例

実行クラスター clusterE 上の以下の構成では、 LSF データ・マネージャー転送キュー data_transfer が、実行依頼クラスター clusterS内の receive_q キューに対するリモート送信ジョブ・キューとして設定されています。

Begin Queue
QUEUE_NAME=data_transfer
DATA_TRANSFER=Y
SNDJOBS_TO=receive_q@clusterS
HOSTS=hostS1 hostS2 # Transfer nodes in the execution cluster
End Queue

また、 clusterS クラスターの以下の構成に示すように、実行クラスター clusterEからジョブを受け入れる (および実行クラスターにデータをプッシュする) ために、 clusterS 実行クラスター内の receive_q キューに対して RCVJOBS_FROM パラメーターを定義する必要があります。

Begin Queue
QUEUE_NAME=receive_q
RCVJOBS_FROM=clusterE
PRIORITY=40
HOSTS=hostS1 hostS2 # Transfer nodes in the submission cluster
RES_REQ=select[type==any]
End Queue

あるいは、実行クラスターを含むすべてのクラスターからジョブを受け入れるように RCVJOBS_FROM=allclusters を定義することもできます。

構文

STACKLIMIT=整数

説明

このパラメーターは、このキューからのジョブに属するすべてのプロセスについて、プロセスごとのハード・スタック・セグメント・サイズの制限を KB 単位で設定する場合に指定します ( getrlimit(2) を参照)。

デフォルト

無制限

構文

STOP_COND=res_req (res_req)

使用 -selectロードしきい値を指定するためのリソース要件ストリングのセクション。 他のすべてのセクションは無視されます。

説明

キューに STOP_COND が指定されていて、負荷しきい値がない場合、個々の負荷指標の中断理由は bjobsによって表示されません。

例

STOP_COND= select[((!cs && it < 5) || (cs && mem < 15 && swp < 50))]

この例では、「cs」は、ホストがコンピューター・サーバーであることを示すブール・リソースであると想定します。 コンピューター・サーバー上で実行されているジョブの停止条件は、スワップ・メモリーの可用性に基づいています。 他の種類のホストで実行されているジョブの停止条件は、アイドル時間に基づきます。

構文

SUCCESS_EXIT_VALUES=[exit_code...］

説明

lsb.applications の SUCCESS_EXIT_VALUES で定義されたアプリケーション・レベルの成功終了値は、 lsb.queuesで定義された構成をオーバーライドします。 LSB_SUCCESS_EXIT_VALUES 環境変数で指定されたジョブレベルの成功終了値は、 lsb.queues と lsb.applications の設定を上書きする。

ゼロ以外の値で正常に終了した特定のキューにジョブを実行依頼して、 LSF がゼロ以外の終了コードをジョブ障害として解釈しないようにするには、 SUCCESS_EXIT_VALUES を使用します。

SUCCESS_EXIT_VALUES と REQUEUE_EXIT_VALUES で同じ終了コードが定義されている場合、sbatchdは成功終了値より先にrequeue終了値を処理するため、この終了コードを持つジョブはDONEとマークされる代わりに再キューされる。

マルチクラスター・ジョブ転送モードでは、 LSF はリモート・クラスターの SUCCESS_EXIT_VALUES を使用します。

マルチクラスター・リソース・リース環境では、 LSF はコンシューマー・クラスターの SUCCESS_EXIT_VALUES を使用します。

exit_code は 0 から 255 までの値でなければなりません。 複数の終了コードを区切るには、スペースを使用します。

SUCCESS_EXIT_VALUES に対して行った変更は、実行中のジョブには影響しません。 badmin reconfig および mbatchd restart を実行して変更を適用した場合でも、保留中のジョブのみが新しい SUCCESS_EXIT_VALUES 定義を使用します。

デフォルト

定義されていません。

構文

SWAPLIMIT=整数

説明

この制限は、ジョブに含めることができるプロセスの数に関係なく、ジョブ全体に適用されます。

ジョブが SWAPLIMIT または PROCESSLIMIT を超えたときに取られるアクションは、SIGQUIT、SIGINT、SIGTERM、および SIGKILL を順に送信することです。 CPULIMIT の場合、SIGXCPU は SIGINT、SIGTERM、および SIGKILL の前に送信されます。

デフォルト

無制限

構文

TASKLIMIT=[最小リミット [デフォルトリミット ]] 最大リミット

説明

キュー・レベル TASKLIMIT は、アプリケーション・レベル TASKLIMIT およびジョブ・レベル TASKLIMITよりも高い優先順位を持っています。 アプリケーション・レベル TASKLIMIT の優先順位がジョブ・レベル TASKLIMITより高くなっています。 ジョブ・レベルの制限は、アプリケーション・プロファイルとキューの最大制限と最小制限の範囲内でなければなりません。

オプションで、ジョブ・タスクの最小数とデフォルト数を指定します。

すべての制限は、以下の関係を満たす 1 以上の正数でなければなりません。

1 < = minimum < = デフォルト < = maximum

キュー内の RES_REQ がブロック・サイズ (span[block=value])の複合リソース要件として定義されている場合、 TASKLIMIT のデフォルト値はブロックの倍数でなければなりません。

例えば、以下の構成が受け入れられます。

キュー・レベルの RES_REQ="1*{type==any } + {type==local span[block=4]}"

TASKLIMIT = 5 9 13

例えば、この構成は受け入れられません。 badmin reconfigの実行中にエラー・メッセージが表示されます。

キュー・レベルの RES_REQ="1*{type==any } + {type==local span[block=4]}"

TASKCLIMIT = 4 10 12

マルチクラスター・ジョブ転送モデルでは、ローカル・クラスターは、ジョブを転送する前にリモート・クラスター上の受信キューの TASKLIMIT を考慮します。 リモート・クラスター内の受信側キューの TASKLIMIT 定義が、リモート・キューに対するジョブのタスク要件を満たすことができない場合、ジョブはクラスター内のそのリモート・キューに転送されません。

デフォルト

無制限。デフォルトのタスク数は 1 です。

構文

TERMINATE_WHEN=[LOAD] [PREEMPT] [WINDOW]

説明

TERMINATE_WHEN ジョブ制御アクションがチャンク・ジョブに適用されると、 sbatchd は実行中のチャンク・ジョブ・エレメントを強制終了し、残りの待機エレメントを保留状態にして後でスケジュール変更します。

例

Begin Queue
QUEUE_NAME           = night
RUN_WINDOW     = 20:00-08:00 EDT
TERMINATE_WHEN = WINDOW
JOB_CONTROLS   = TERMINATE[kill -KILL $LS_JOBPGIDS; mail - s "job $LSB_JOBID 
                 killed by queue run window" $USER < /dev/null]
End Queue

タイム・ゾーンの指定はオプションです。 時間帯を指定しない場合、 LSF はローカル・システムの時間帯を使用します。

構文

THREADLIMIT=[デフォルトリミット ] 最大リミット

説明

システムは、SIGINT、SIGTERM、および SIGKILL というシグナルを、ジョブに属するすべてのプロセスに順に送信します。

デフォルトでは、デフォルトのスレッド制限が指定されている場合、ジョブ・レベルのスレッド制限なしでキューに実行依頼されたジョブは、デフォルトのスレッド制限に達すると強制終了されます。

制限を 1 つしか指定しない場合は、最大 (ハード) スレッド制限になります。 2 つの制限を指定する場合、最初の制限はデフォルト、つまりソフト・スレッド制限であり、2 番目の制限は最大スレッド制限です。

デフォルト制限と最大制限は両方とも正の整数でなければなりません。 デフォルトの制限は最大制限より小さくなければなりません。 デフォルトの制限は、最大制限より大きい場合は無視されます。

例

THREADLIMIT=6

デフォルトのスレッド制限は指定されません。 値 6 は、デフォルトおよび最大スレッド限度です。

THREADLIMIT=6 8

最初の値 (6) は、デフォルトのスレッド限度です。 2 番目の値 (8) は、最大スレッド限度です。

デフォルト

無制限

構文

THREADLIMIT=スレッド数

説明

ジョブのスレッド制限値は、ジョブの一部となり得る同時実行スレッド数を制限するもので、 THREADLIMIT パラメータで定義される。 この制限を超えると、ジョブは終了します。 リミット値は正の整数でなければならない。

ジョブのスレッド制限値を計算するために THREADLIMIT_PER_TASK パラメータを使用すると、ジョブのタスク数に基づいてより洗練されたスレッド制限を使用できます。 指定された場合、 THREADLIMIT_PER_TASK の値にジョブのタスク数を乗じることで、 LSF はジョブのスレッド制限を計算する。 こうすることで、ジョブのスレッド制限はジョブキュー全体の固定値ではなくなる。

THREADLIMIT_PER_TASK パラメーターは、ジョブのスレッド制限を計算するためだけに使用され、各タスクのスレッド数を制限することはない。

THREADLIMIT_PER_TASK パラメータは、同じキューに対して THREADLIMIT パラメータと一緒に設定することはできません。 同じキューに両方の値を指定した場合、 THREADLIMIT_PER_TASK の値のみが使用され、 THREADLIMIT の値は無視される。

例

THREADLIMIT_PER_TASK=10

デフォルト

未定義

構文

UJOB_LIMIT=整数

説明

このパラメーターは、各ユーザーがこのキューで使用できるジョブ・スロットの最大数を指定します。

UJOB_LIMIT は、 TASKLIMIT または bsub -n によって設定された範囲 (いずれかが使用されている場合) 以上でなければなりません。そうでない場合、ジョブは拒否されます。

デフォルト

無制限

説明

USE_PAM_CREDS は、 Linux システムでのみサポートされます。 実行ホストで PAM が構成されておらず、このパラメーターが有効になっている場合、ジョブは失敗します。

USE_PAM_CREDS が y または limitsに設定されている場合、 LSF は、ジョブが PAM を使用して Linux ホストにディスパッチされるときに、PAM 制限をキューに適用できます。 LSF ジョブは、PAM セッション内では実行されません。

limits キーワードは、 session キーワードと一緒に定義できます。

LSF の制限が PAM の制限よりも厳しい場合は、 LSF の制限が使用されます。そうでない場合は、PAM の制限が使用されます。 PAM 制限は、 limits.conf ファイルに定義されているシステム・リソース制限です。

並列ジョブの場合、PAM セッションは、 USE_PAM_CREDS=y または USE_PAM_CREDS=limits が定義されている場合にのみ、最初の実行ホストで起動されます。 USE_PAM_CREDS=session または USE_PAM_CREDS=limits session が定義されている場合、すべてのタスクで PAM セッションが起動されます。

ジョブ sbatchd デーモンは lsf サービスを検査し、ジョブまたはタスク RES デーモンは lsf-<clustername> サービスを検査します。

MEMLIMIT_TYPE=Processをオーバーライドします。

LSB_JOB_CPULIMIT=yによってオーバーライドされます (CPU リミットの場合のみ)。

LSB_JOB_MEMLIMIT=yによってオーバーライドされます (メモリー制限の場合のみ)。

lsb.applications の USE_PAM_CREDS 値は、 lsb.queuesの USE_PAM_CREDS 値をオーバーライドします。

デフォルト

n. USE_PAM_CREDS は使用不可です。

構文

USERS=all [~user_name...] [~user_group...] | [user_name...] [user_group [~user_group...]...]

説明

LSF クラスタ管理者は、自動的にユーザーリストに含まれます。 LSF クラスター管理者は、このキューにジョブを実行依頼するか、任意のユーザーのジョブをこのキューに切り替える (bswitch) ことができます。

ユーザー・グループが指定されている場合には, そのグループの各ユーザーがこの待ち行列にジョブを投入することができます。 FAIRSHARE もこのキューに定義されている場合は、両方のパラメーターで定義されたユーザーのみがジョブを実行依頼できます。したがって、LSF 管理者は、共用割り当てに含まれていないキューを使用できません。

ユーザー名は有効なログイン名でなければなりません。 Windowsユーザーアカウントを指定するには、ドメイン名を大文字で含めます（ドメイン名\ユーザー名）。

ユーザー・グループ名は、LSF ユーザー・グループまたは UNIX および Windows ユーザー・グループにすることができます。 Windowsユーザーグループを指定するには、ドメイン名を大文字で含めます（ドメイン名\ユーザー・グループ）。

クラスター内のすべてのユーザーまたはユーザー・グループを指定するには、キーワード all を使用します。

all 指定またはユーザー・グループからユーザーを除外するには、NOT 演算子 (~) を使用します。 これは、多数のユーザーが存在するが、キュー定義から一部のユーザーまたはグループのみを除外したい場合に役立ちます。

NOT 演算子 (~) は、 all キーワードと一緒に使用するか、ユーザー・グループからユーザーを除外する場合にのみ使用できます。

デフォルト

all (すべてのユーザーがジョブをキューに実行依頼できます)

例

• USERS=user1 user2
• USERS=all ~user1 ~user2
• USERS=all ~ugroup1
• USERS=groupA ~user3 ~user4

例

Begin Queue
... 
#if time(8:30-18:30 EDT)   
INTERACTIVE  = ONLY  # interactive only during day shift #endif
#endif
... 
End Queue

タイム・ゾーンの指定はオプションです。 時間帯を指定しない場合、 LSF はローカル・システムの時間帯を使用します。 LSF は、すべての標準時間帯の省略形をサポートします。