너무 길어요.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을 통해 시작하는 것 사이의 예약에는 어떤 차이가 있나요? 왜 그 중 하나는 내 데몬의 일정에 영향을 주지 않는 반면 다른 하나는 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