This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
cluster:208 [2021/10/18 17:41] hmeij07 [Changes] |
cluster:208 [2022/06/01 12:42] hmeij07 [gpu testing] |
||
---|---|---|---|
Line 382: | Line 382: | ||
--- // | --- // | ||
+ | |||
+ | ===== gpu testing ===== | ||
+ | |||
+ | * test standalone slurm v 21.08.1 | ||
+ | * n33-n37 each: 4 gpus, 16 cores, 16 threads, 32 cpus | ||
+ | * submit one at a time, observe | ||
+ | * part=test, n 1, B 1:1:1, cuda_visible=0, | ||
+ | * " | ||
+ | * all on same gpu | ||
+ | * part=test, n 1, B 1:1:1, cuda_visible not set, no node specified, n33 only | ||
+ | * " | ||
+ | * all gpus used? nope, all on the same one 0 | ||
+ | * redoing above with a '' | ||
+ | * even distribution across all gpus, 17th submit reason too | ||
+ | * part=test, n 1, B 1:1:1, cuda_visible not set, no node specified, n[33-34] avail | ||
+ | * while submitting 34 jobs, one at a time (30s delay), slurm fills up n33 first (all on gpu 0) | ||
+ | * 17th submit goes to n34, gpu 1 (weird), n33 state=alloc, | ||
+ | * 33th job, " | ||
+ | * 34th job, " | ||
+ | * all n33 and n34 jobs on single gpu without cuda_visible set | ||
+ | * how that works with gpu util at 100% with one jobs is beyond me | ||
+ | * do all 16 jobs log the same wall time? Yes, between 10.10 and 10.70 hours. | ||
+ | |||
+ | * ohpc v2.4 slurm v 20.11.8 | ||
+ | * part=test, n 1, B 1:1:1, cuda_visible=0, | ||
+ | * hit a bug, you must specify cpus-per-gpu **and** mem-per-gpu | ||
+ | * then slurm detects 4 gpus on allocated node and allows 4 jobs on a single allocated gpu | ||
+ | * twisted logic | ||
+ | * so recent openhpc version but old slurm version in software stack | ||
+ | * trying standalone install on openhpc prod cluster | ||
+ | |||
===== Changes ===== | ===== Changes ===== | ||
Line 406: | Line 437: | ||
** GPU-CPU cores ** | ** GPU-CPU cores ** | ||
- | Noticed this with debug level on in slurmd.log | + | Noticed this with debug level on in slurmd.log. No action taken. |
< | < | ||
Line 430: | Line 461: | ||
</ | </ | ||
- | ** Weight | + | ** Partition |
- | Weight nodes by the memory per logical core: jobs will be allocated the nodes with the lowest weight which satisfies their requirements. So CPU jobs will be routed last to gpu queues because they have the highest weight (=lowest priority). | + | If set you can list more than one queue... |
+ | < | ||
+ | srun --partition=exx96, | ||
+ | </ | ||
+ | |||
+ | The above will fill up n79 first, then n78, then n36... | ||
+ | |||
+ | ** Node Weight Priority ** | ||
+ | |||
+ | Weight nodes by the memory per logical core: jobs will be allocated the nodes with the lowest weight which satisfies their requirements. So CPU jobs will be routed last to gpu queues because they have the highest weight (=lowest priority). | ||
+ | < | ||
hp12: 12/8 = 1.5 | hp12: 12/8 = 1.5 | ||
tinymem: 32/20 = 1.6 | tinymem: 32/20 = 1.6 | ||
Line 442: | Line 483: | ||
amber128: 128/16 = 8 | amber128: 128/16 = 8 | ||
mwgpu = 256/16 = 16 | mwgpu = 256/16 = 16 | ||
+ | </ | ||
+ | |||
+ | Or more arbitrary (based on desired cpu node comsumption of cpu jobs. No action taken. | ||
+ | |||
+ | < | ||
+ | tinymem | ||
+ | mw128 20 | ||
+ | mw256fd | ||
+ | mwgpu 40 + HasMem256 feature | ||
+ | amber128 | ||
+ | exx96 80 | ||
+ | </ | ||
+ | |||
+ | ** CR_CPU_Memory ** | ||
+ | |||
+ | Makes for a better 1-1 relationship of physical core to '' | ||
+ | |||
+ | Deployed. My need to set threads=1 and cpus=(quantity of physical cores)...this went horribly wrong it resaulted in sockets=1 setting and threads=1 for each node. | ||
+ | --- // | ||
+ | |||
+ | We did set number of cpus per gpu (12 for n79) and minimum memory settings. Now we experience 5th job pending with 48 cpus consumed. When using sbatch set -n 8 because sbatch will override defaults. | ||
+ | |||
+ | < | ||
+ | srun --partition=test | ||
+ | </ | ||
+ | |||
\\ | \\ | ||
**[[cluster: | **[[cluster: | ||