長すぎます。CPU集約的なワークロードは、Slurm sbatch / srunを介して起動した場合（手動で起動する場合ではない）のみ、他のプロセスの良い値を無視します。
ハードウェアパフォーマンスデータを定期的に収集するsystemdサービスを実行しています。サービスがデプロイされました。窒素（コア数）デーモンはすべて割り当てられた単一コアで実行するように固定されています。必要に応じてある程度予約できるようにするために、1サービス(およびサービスに固有のすべてのスレッド/デーモン) は、適切な値 -20 で始まります。
CPU集約的なタスク/ベンチマークを実行するとき。
stress --cpu $(nproc) --timeout 60s
私が提供するすべてのデーモンは200ms2未満で動作することができます（良い結果です）。
ただし、Slurm sbatch / srun 3を介して同じストレステストを送信すると、デーモンにCPUが不足します。デーモン（私が想定しているように）は予約されておらず、200ms未満の代わりに操作を実行するのに数秒かかります（10〜20倍のオーバーヘッドを増やす）。
デーモンはハードウェアレジスタにのみアクセスするため、他の要因（I / O、メモリ、共有リソースなど）によって制限されません。 cgroupに制限はありません。このシステムでは自動グループ化が無効になっています。
システム: 2x AMD EPYC 7713(64c), 256GB RAM, カーネル 4.18.0
質問：
ストレステストを手動で開始することと、Slurmを介して開始するものとの間の予約にはどのような違いがありますか？なぜそれらの1つは私のデーモンのスケジュールに影響しませんが、もう1つはCPUリソースが不足していますか？
1これがリアルタイム予約の問題であることを知っていますが、可能であればリアルタイム予約ポリシーに変更することを避けたいと思います。
2主にハードウェアパフォーマンスカウンタの設定/読み取り
3次のスクリプトを参照してください。
#!/bin/bash
#SBATCH --ntasks=1
#SBATCH --partition=ALL
#SBATCH --nodelist=myNode
#SBATCH --time=00:05:00
stress --cpu $(nproc) --timeout 60s