学校HPC集群

学校高性能计算平台共两百余台机器，纳入SLURM调度的171台，合计12352个CPU核，调度器统计内存90余TB，外挂23PB并行文件系统。硬件分批采购，代际混合。

120台为早期CPU节点，双路32核Xeon 8358P，单机64核 / 500G内存，承载日常主要算力。数台胖节点为四路24核Xeon 8360H，单机96核 / 2T内存，供大内存作业使用。最新批次为GPU节点，单机96核 / 1T内存、8张H20，另有一台配2块4090。另有2台国产K100异构节点，自五月末起持续offline。

平台另有二十余台GPU机器未纳入SLURM节点列表；登录、管理、监控类机器同样不计入调度器口径，sinfo不显示。

主要用户方向为生物信息与计算化学，module avail提供87个模块，blast、bwa、vasp、gromacs占多数。

登录节点仅承担登录与作业提交，计算须下发至计算节点。调度系统版本SLURM 23.11.10，以下数据均在登录节点实测采集。

节点详情

1
2
3
4
sinfo -s                             # 分区概览：节点数、状态分布
sinfo -N -o "%N %P %c %m %G %t"      # 逐节点：核数、内存、加速卡、状态
squeue -o "%.8i %.8P %.18j %.8t %.10M %R"    # 自己的作业
sacct -u $USER --starttime=now-2hours        # 自己的历史作业与资源用量

sinfo -s输出：

1
2
3
4
5
6
7
8
9
10
11
PARTITION AVAIL  TIMELIMIT   NODES(A/I/O/T) NODELIST
cpu96        up   infinite          1/4/0/5   fat[01-05]
cpu64*       up   infinite        25/95/0/120 node[01-120]
test96       up   infinite          0/2/0/2   node[121-122]
soy-com      up   infinite          0/22/0/22   sri-com-[01-22]
sri-com      up   infinite      13/1/0/14     sri-com-[23-36]
sri-mem      up   infinite          0/2/0/2   sri-mem-[01-02]
sri-ghz      up   infinite          0/2/0/2   sri-ghz-[01-02]
sri-gpu      up   infinite          0/1/0/1   sri-gpu-01
sri-gnm      up   infinite          0/1/0/1   sri-gnm-01
dcu          up   infinite          0/0/2/2   dk-gpu[01-02]

带星号的cpu64为默认分区，不指定-p时作业落入此分区。中间四列为allocated / idle / other / total。

分区

分区 节点数 CPU型号 单机核数 单机内存 加速卡
cpu64（默认） 120 Xeon Platinum 8358P 64 500G —
cpu96 5 Xeon Platinum 8360H 96 2T —
test96 2 Xeon Platinum 8558P 96 250G —
soy-com 22 Xeon Platinum 8558P 96 500G —
sri-com 14 — 96 500G —
sri-mem 2 — 96 2T —
sri-ghz 2 — 32 500G —
sri-gpu 1 — 96 1T H20 × 8
sri-gnm 1 — 96 500G 4090 × 2
dcu 2 — 48 250G 国产K100 × 2

十个分区合计171台、12352核。cpu64中118台为500G内存，其余两台384G。

sri-*一组绑定专属QoS，普通账号提交返回Invalid qos specification，CPU型号无法读取；dcu两台offline，同样无法读取。

cpu64的120台为主力：空闲95台时可直接提交；25台在跑时backfill仍可插入空闲窗口。调度器记录内存500G，节点内free -g实测503G。

DCU两台装国产K100，sinfo中为down*，scontrol show node给出的原因为Not responding，自五月底持续至今。另两台带加速卡的节点——sri-gpu的H20与sri-gnm的4090——位于上述受限QoS组内。

系统代际存在差异：早期CPU节点为CentOS 8.2 / 内核4.18，后加的GPU与内存节点为RHEL 9.5 / 内核5.14。/hpc/software下gcc覆盖4.8.5至14.1.0，glibc保留2.29与2.36两套，对应两代系统各留一版。自行编译的二进制跨分区搬运存在兼容风险。

作业提交

交互式调试用srun：

1
srun -p cpu64 -N1 -n1 --time=00:30:00 --pty bash

实测分配到node08，grep -m1 'model name' /proc/cpuinfo为Xeon Platinum 8358P。进入后nproc返回1而非64——srun该步仅分配1个CPU，确认整机规格需读/proc/cpuinfo或使用lscpu。

正式任务写脚本交sbatch：

1
2
3
4
5
6
7
8
9
10
11
#!/bin/bash
#SBATCH -J quant-backtest
#SBATCH -p cpu96
#SBATCH --cpus-per-task=32
#SBATCH --mem=256G
#SBATCH --time=08:00:00
#SBATCH -o /hpc/home/%u/logs/%j.out
#SBATCH -e /hpc/home/%u/logs/%j.err

cd ~/quant
python backtest.py

申请加速卡加一行#SBATCH --gres=gpu:1，具体型号见分区Gres字段。

集群SelectTypeParameters为CR_CORE，调度按核数分配，内存不参与资源分配——作业不写--mem亦可运行，节点AllocMem恒为0。以两个1核作业验证，运行期间所在节点AllocMem均为0。同节点多作业之间互不可见实际内存占用，先占满内存的作业会影响其余作业，故提交时须显式指定--mem。sacct中ReqMem显示500000M，为未填该字段时按节点总内存回填的显示值，不代表实际申请整机。

数组作业上限MaxArraySize为1001，单次最多提交1001个子任务，更大规模需分批提交。

调度器按什么排

PriorityType = priority/multifactor，SchedulerType = sched/backfill。前者按作业年龄、份额、队列权重计算优先级，后者负责插空——作业若能在一个空闲窗口内跑完，即可提前启动。

该组合利于短作业，反向亦然：为一个5分钟的任务写--time=72:00:00，backfill找不到足够长的窗口，作业只能排队。

所有分区时间上限均为infinite，MaxTime无系统级限制，时限交由使用者自行声明，长时作业可长期占用节点。

squeue -a在普通账号下不显示其他用户作业：实测squeue -a -h | wc -l返回0，同一时刻sinfo显示25个节点处于alloc状态。判断集群负载只能依据sinfo的节点状态分布。

存储：23P与5000亿inode

df -hT中容量最大的一行：

1
2
Filesystem      Type      Size  Used Avail Use% Mounted on
/hpc             dpc        23P  1.1P   22P   5% /hpc

23PB并行文件系统，已用1.1PB。文件系统类型为dpc，属分布式存储客户端挂载，与本地盘行为不同——小文件随机读性能与顺序读写相差量级，登录节点禁用du / find即源于此。

inode容量见df -i /hpc：总量5000亿，已用2.33亿。元数据按目录树铺开、查询需走网络，是该量级的成因。

另两个挂载点：

  • /usr/local/globle/softs为NFS，191G、59%已用，存放slurm二进制与公共软件，所有节点共享同一份。
  • /dev/shm为252G内存盘。数据管道中间结果置于此处，读写不落盘；重启即清空。

家目录位于/hpc/home/<用户名>。以本账号为例，占用接近48TB，主要为从ModelScope拉取的49个模型，其余为量化日线数据。

环境与启动速度

公共软件通过module加载，module avail挂载87个：生信类（blast、bwa、hmmer、canu、megahit、gtdbtk、metawrap）、计算化学类（vasp、gromacs、amber、autodock）、gcc/4.8.5至gcc/14.1.0、openmpi 3.1至5.0.5、cuda/11.7与12.4、Python 3.7/3.8、R三个版本、singularity两个版本。使用前module load gcc/14.1.0 openmpi/5.0.5即可，优于在home内自行编译。

Python环境采用miniconda，按用途拆为四个：myenv放通用工具，quant放baostock相关依赖，agent与agent-gpu分开的原因是GPU侧依赖锁定在另一cuda版本。

zsh启动时间做过专项优化。原始耗时约15秒，成因是oh-my-zsh及插件每次登录重新source，而home挂在分布式存储上，网络文件系统随机读延迟高。处理办法是把omz与历史文件缓存到/dev/shm，并将"重新加载配置"改写为跳过omz重复加载的函数。优化后约0.8秒，多终端窗口并发打开时差异明显。

长任务用tmux托管

登录节点直接运行长任务，网络断开即进程终止，改用tmux托管：

1
2
3
tmux new -s pull        # 建会话
# Ctrl-b d 脱离
tmux attach -t pull     # 重新接上

集群tmux版本为2.7。小时级以上的任务交sbatch；tmux用于托管数据拉取循环与监控进程。