Linux 集群 CPU 频率检测：区分高负载与硬件超频

Linux 集群 CPU 频率检测：区分高负载与硬件超频引言在管理 Linux 计算集群时，我们经常会在 pestat 输出中看到一些节点的 CPU 负载异常高。例如下面的 pestat 输出显示了多个节点的状态： Hostname Partition Node Num_CPU CPUload Memsize Freemem Joblist State Use/Tot (15min) (MB) (MB) JobID User ... node1 multi+ alloc 48 48 49.07* 191895 158367 436066 mxy ... node2 multi+ alloc 48 48 49.00* 191898 157115 436116 mxy ... node10 single mix 8 128 111.63* 515641 408900 434722 gxf1212 ... node11 multi+ mix 122 128 97.99* 515641 461935 436055 xucx ... node12 multi mix 114 128 112.52* 515641 452336 435966 shizq ... node22 multi mix 126 128 114.80* 515621 452780 432502 wangtk ... 注意到 node10 的 15 分钟平均负载达到 111.63，但实际上只分配了 8 个 CPU 核心（128 个核心中的 8 个），而 node22 的负载为 114.80，分配了 126 个核心。这种现象常常引发关于“超频”的疑问。本文将系统性地分析 CPU 负载与频率监控的完整方法论，帮助管理员准确诊断集群状态。两种不同的“超频”概念在深入技术细节之前，我们需要明确区分两个经常被混淆的概念：软件层面的高负载这是指系统的 Load Average（平均负载）异常高，超出了正式分配的计算核心数。例如某个节点有 128 个 CPU 核心，但 SLURM 只分配了 8 个核心给作业，而系统负载却达到了 111.63。这并不等于“有 111 个核心正在满载计算”，而是表示在统计窗口内，处于可运行状态或不可中断睡眠状态（常见于 I/O 等待）的任务平均数很高。造成软件层面高负载的常见原因包括失控进程进入死循环、用户运行高并行度程序（如使用 make -j 128 进行编译）、大量线程同时争抢 CPU、I/O 阻塞导致大量任务处于 D 状态，以及 Docker 或 Singularity 容器、日志轮转、备份任务等额外工作负载。严格来说，僵尸进程本身不会继续消耗 CPU，也通常不是高 load average 的直接原因；如果看到大量僵尸，更应排查其父进程管理是否异常。硬件层面的超频这是传统意义上的概念，指通过调整 BIOS/UEFI 或使用软件，人为将 CPU 运行频率提升到出厂默认频率以上。本文后续部分将重点讨论如何检测这种情况。 CPU 硬件频率检测流程检测 CPU 是否存在硬件超频的核心思路是对比 CPU 的当前运行频率、内核当前策略上限，以及厂商公开规格中的基础频率和最大 boost 频率。如果观测到的频率长期超过厂商规格上限，才值得怀疑 BIOS/UEFI 或平台策略存在非常规设置；如果只是高负载，而频率仍在规格内，则通常不属于硬件超频问题。完整检测流程图 flowchart TD A[开始检测 CPU 硬件超频] --> B{获取 CPU 基础信息} B --> B1["lscpu 查看型号与基础频率"] B --> B2["查阅官方规格 获取最大睿频理论值"] B1 --> C{获取当前实时频率} C --> C1["cpupower frequency-info 查看驱动与策略"] C --> C2["watch -n 1 cat /proc/cpuinfo 实时监控频率"] C --> C3["turbostat x86 平台专业级监控"] C2 --> D["核心判断逻辑"] B2 --> D D --> E{当前频率持续高于厂商规格上限?} E -- 是 --> F["⚠️ 可能存在超频或读数异常"] E -- 否 --> G["✅ 频率仍在规格或策略范围内"] F --> H["深入排查"] H --> H1["检查 BIOS 设置"] H --> H2["排查超频软件"] G --> I["检测完成"] 关键检测命令详解步骤一：获取 CPU 型号与官方规格首先需要知道 CPU 的“出厂设定”： lscpu | grep -E "Model name:|CPU MHz:|CPU max MHz:|CPU min MHz:" 输出示例： Model name: Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz CPU MHz: 2500.000 CPU max MHz: 3500.0000 CPU min MHz: 800.0000 关键字段说明：Model name 中的 @ 2.00GHz 一般对应厂商标称基础频率；CPU max MHz 和 CPU min MHz 是 lscpu 从内核接口读取到的本机可见频率范围，常可作为本机策略或驱动视角下的参考上限与下限；CPU MHz 则是当前某个 CPU 的瞬时或近似瞬时频率读数。它们对排障很有用，但不应直接替代厂商规格表。 ⚠️ 重要提示：lscpu 显示的 CPU max MHz 来自内核当前暴露的信息，它可能受驱动、BIOS/UEFI、电源策略和平台实现影响，因此不一定等于厂商宣传页上的最大 boost 频率。最可靠的方法仍然是根据 CPU 型号去厂商官网查询正式规格。步骤二：监控当前实时频率查看 CPU 在负载下的实际运行频率有多种方法。使用 cpupower 工具可以查看详细的频率信息，包括 driver（当前 cpufreq 驱动）、hardware limits（内核当前看到的频率范围）、available frequency steps（可用的频率档位，若驱动支持）、boost state support（平台是否支持 boost，以及当前是否启用）以及 current CPU frequency。需要注意，current CPU frequency 的精度和含义依赖具体驱动与硬件接口，不能把它当作绝对精确的硬件测量值。 sudo cpupower frequency-info 动态监控所有核心（最直观的方法）是使用 watch 命令实时刷新显示频率： watch -n 1 "grep \"^[c]pu MHz\" /proc/cpuinfo" 这种方法直观、方便，而且 watch 的手册页也把它作为动态频率观察示例。但 /proc/cpuinfo 中的 cpu MHz 本质上是内核导出的软件读数，适合快速巡检，不适合拿来做极严格的频率取证。使用 turbostat（专业级监控工具）可以获取更详细的性能数据： sudo turbostat --quiet --show Core,CPU,Busy%,Bzy_MHz,CPU%c7 --interval 2 其中 Bzy_MHz 列显示每个逻辑 CPU 在忙碌时的平均运行频率。turbostat 是 x86 平台的专业工具，在 Intel 平台上最常见；在 AMD 平台上通常也可使用，但具体字段可用性会受内核、处理器型号和权限影响。实战案例分析案例 1：node10 节点分析环境信息： Model name: AMD EPYC 7713 64-Core Processor CPU MHz: 1500.000 CPU max MHz: 2000.0000 CPU min MHz: 1500.0000 cpupower 输出： analyzing CPU 0: driver: acpi-cpufreq hardware limits: 1.50 GHz - 2.00 GHz available frequency steps: 2.00 GHz, 1.70 GHz, 1.50 GHz current policy: frequency should be within 1.50 GHz and 2.00 GHz. The governor "conservative" may decide which speed to use within this range. current CPU frequency: 1.50 GHz (asserted by call to hardware) Error while evaluating Boost Capabilities on CPU 0 -- are you root? 实时监控结果：watch -n 1 "grep \"^[c]pu MHz\" /proc/cpuinfo" 显示各核心均为 1.50 GHz。诊断结论根据 AMD 官方规格，EPYC 7713 的基础频率为 2.0 GHz，最大 boost 频率可达 3.675 GHz。这里最稳妥的判断顺序是三步： lscpu 显示 CPU MHz = 1500、CPU max MHz = 2000，说明当前内核看到的瞬时频率为 1.50 GHz，本机可见上限为 2.00 GHz。 cpupower frequency-info 显示 hardware limits: 1.50 GHz - 2.00 GHz，且当前策略为 conservative，current CPU frequency 也为 1.50 GHz。 /proc/cpuinfo 动态监控时，各核心频率持续稳定在 1.50 GHz，没有出现任何高于 2.00 GHz 的读数。因此，“现有证据只能支持 node10 没有发生硬件超频”。更准确地说，这台机器当前运行在 1.50 GHz 的低频状态，而不是跑到了超出规格的高频状态。至于为什么这颗 7713 没有表现出更高的 boost 频率，则是另一个问题。当前输出只能说明 Linux 通过 acpi-cpufreq 暴露给用户空间的范围是 1.50 至 2.00 GHz，不能仅凭这一点就断言“boost 一定被彻底禁用”。更合理的说法是：这个节点目前处于较保守的频率策略下，或者平台没有把更高 boost 档位暴露给当前的 cpufreq 接口。案例 2：node22 节点分析环境信息： Model name: AMD EPYC 7763 64-Core Processor CPU MHz: 2450.000 CPU max MHz: 2450.0000 cpupower 输出： hardware limits: 1.50 GHz - 2.45 GHz current CPU frequency: 2.45 GHz Error while evaluating Boost Capabilities turbostat 输出： Busy% Bzy_MHz 100.00 3099 100.00 3123 100.00 3145 ... 在满负载核心上，Bzy_MHz 多次出现在约 3.05 至 3.15 GHz 的区间。诊断结论根据 AMD 官方规格，EPYC 7763 的基础频率为 2.45 GHz，最大 boost 频率约 3.5 GHz。这里同样按证据链来判断： lscpu 显示 CPU MHz = 2450、CPU max MHz = 2450、CPU min MHz = 1500。 cpupower frequency-info 显示 hardware limits: 1.50 GHz - 2.45 GHz，当前调速器仍为 conservative，current CPU frequency 为 2.45 GHz。 /proc/cpuinfo 动态监控时，各核心持续稳定在 2.45 GHz，没有看到高于 2.45 GHz 的读数。但 turbostat 在高负载下给出的 Bzy_MHz 多次达到约 3.1 GHz，明显高于 2.45 GHz，但仍低于 AMD 官方标称的最大 boost 频率 3.5 GHz。因此，现有证据支持的结论是：node22 没有发生硬件超频，而且实际上已经进入了正常的 boost 区间。换句话说，lscpu、cpupower 和 /proc/cpuinfo 这几处在这台老内核机器上更像是在报告 cpufreq 接口可见的基础档或策略档，而 turbostat 则揭示了核心忙碌时的实际平均运行频率。需要强调的是，AMD 官网给出的 3.5 GHz 是厂商标称的最大 boost 频率，而不是此时 Linux acpi-cpufreq 接口已经向用户空间暴露出来的可用上限。node22 的 turbostat 结果说明：当前 Linux 可见的 cpufreq 上限未体现出厂商标称的 boost 档位，但 boost 本身并不一定没开。两个节点的对比对比项 node10 node22 CPU 型号 AMD EPYC 7713 AMD EPYC 7763 官方基础频率 2.0 GHz 2.45 GHz 当前运行频率 1.5 GHz 2.45 GHz cpupower 可见范围 1.50-2.00 GHz 1.50-2.45 GHz turbostat 观测暂无补充数据忙碌核心约 3.05-3.15 GHz 频率状态低于基础频率的低频运行实际可进入高于基础频率的正常 boost 区间 Boost 暴露情况 cpufreq 未显示高于基础频率的 boost 上限 cpufreq 未显示 boost 上限，但 turbostat 已观察到 boost 硬件超频 ❌ 否 ❌ 否总结与建议检测要点总结检测 CPU 超频的核心在于区分两类不同概念：软件高负载与硬件超频是两回事，前者通常意味着可运行任务或 I/O 等待任务太多，后者才是实际运行频率超过硬件规格。更稳妥的判定流程是：先看 lscpu，再看 cpupower frequency-info 的驱动、策略和可见频率范围，最后用 /proc/cpuinfo 或 turbostat 做动态复核。尤其是在老内核加 acpi-cpufreq 的组合下，lscpu 和 cpupower 可能看不到完整 boost 档位，这时应优先相信 turbostat 给出的忙碌频率，再去和厂商规格比较。只要观测频率没有超过厂商规格上限，就不能把它判定为超频。关键命令组合： # 快速检查 lscpu | grep -E "Model name:|CPU max MHz:" # 详细监控 sudo cpupower frequency-info watch -n 1 "grep \"^[c]pu MHz\" /proc/cpuinfo" 管理建议根据不同的应用场景和管理需求，我们提供以下管理建议：场景类型建议措施说明性能敏感的应用检查 BIOS 设置、平台电源策略与 cpufreq 驱动类型；确认是否启用了 boost 相关能力；再评估是否需要将 CPU 调速器从 conservative 改为 performance 最大化 CPU 性能输出稳定性和能效优先当前配置是合理的，牺牲部分峰值性能换取稳定性；定期监控系统负载，确保没有失控进程适合长期稳定运行集群统一管理建议对同类节点使用一致的 BIOS 和电源策略；建立基准测试，验证不同配置下的实际性能差异便于运维和管理如果还要继续追问“为什么没有 boost” 上面的命令已经足够支持“不是超频”这个结论。如果后续还想解释“为什么没看到 3.5 GHz 或 3.675 GHz”，则建议补充以下命令，进一步区分是 BIOS 设置、驱动类型，还是 cpufreq 策略导致的： cat /sys/devices/system/cpu/cpufreq/policy0/scaling_driver cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor cat /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq cat /sys/devices/system/cpu/cpufreq/boost 如果系统支持，还可以继续看： dmesg | grep -i amd_pstate dmesg | grep -i cpufreq sudo turbostat --quiet --show Core,CPU,Busy%,Bzy_MHz --interval 2 对于 node22，uname -r 显示的是 3.10.0-957.el7.x86_64，dmesg 中可见的是 acpi_cpufreq，而没有 amd_pstate。这说明它运行在较老的内核和传统 cpufreq 驱动栈上，这也正好解释了为什么 cpupower 没有把 boost 能力展示完整，而 turbostat 仍然能观察到约 3.1 GHz 的实际忙碌频率。因此，这些命令不是为了重新证明“有没有超频”，而是为了回答另一个更细的问题：为什么当前平台没有把更高 boost 档位完整暴露出来，或者为什么不同工具看到的频率上限不一致。参考资源 Linux Kernel CPU Frequency Scaling：https://www.kernel.org/doc/html/latest/admin-guide/pm/cpufreq.html Linux Kernel amd-pstate 文档：https://docs.kernel.org/admin-guide/pm/amd-pstate.html lscpu 手册页：https://man7.org/linux/man-pages/man1/lscpu.1.html uptime 手册页：https://man7.org/linux/man-pages/man1/uptime.1.html proc_loadavg 手册页：https://man7.org/linux/man-pages/man5/proc_loadavg.5.html procps 手册页（僵尸进程与进程状态）：https://man7.org/linux/man-pages/man1/procps.1.html AMD EPYC 处理器官方规格：https://www.amd.com/en/products/cpu/amd-epyc-7003-series cpupower 手册页：https://man7.org/linux/man-pages/man1/cpupower-frequency-info.1.html watch 手册页：https://man7.org/linux/man-pages/man1/watch.1.html turbostat 手册页：https://man.archlinux.org/man/turbostat.8.en

Techniques · 2026-03-16

Slurm 作业插队指南：QOS 优先级配置从入门到实战

Slurm 作业“插队”指南：QOS 优先级配置从入门到实战本文基于实验室集群的真实运维经验整理，介绍如何通过 QOS（Quality of Service）机制管理作业优先级。核心概念 QOS、Partition、Account 的关系 Slurm 调度涉及四个核心概念： Partition（分区）：节点的逻辑分组，可限定允许的 Account 和 QOS Account（账户）：项目或课题组标识，用于计费和权限控制 QOS（服务质量）：影响优先级和资源限制的关键机制 Association（关联）：User-Account-Partition-QOS 的组合，必须存在才能提交作业关键公式：作业总优先级 = PriorityWeightAge × Age因子 + PriorityWeightFairshare × Fairshare因子 + PriorityWeightQOS × (QOS Priority / 系统最高QOS Priority) + PriorityWeightPartition × Partition优先级 + PriorityWeightTRES × TRES因子 Priority=0 说明：Slurm 默认的 normal QOS 就是 Priority=0，这是基准值。作业可以正常运行，但不会从 QOS 获得额外优先级加成（QOS 因子为 0）。正值提升优先级，负值降低优先级。环境检查确认集群启用了 multifactor 调度： scontrol show config | grep -i Priority 实际输出示例（your_cluster）： PriorityType = priority/multifactor PriorityWeightAge = 200 PriorityWeightFairShare = 100 PriorityWeightPartition = 500 PriorityWeightQOS = 500 PriorityWeightTRES = gres/gpu=2000 关键参数：PriorityWeightQOS=500 和 PriorityWeightTRES=gres/gpu=2000 表示 GPU 资源权重最高。查看当前作业优先级各因子贡献： sprio -u username | head 实际输出示例： JOBID PARTITION USER PRIORITY SITE AGE FAIRSHARE PARTITION QOS TRES 123456 quick username 514 0 3 2 1 500 gres/gpu=9 123456 quick username 514 0 3 2 1 500 gres/gpu=9 解读：QOS 贡献了 500 分（使用 urgent QOS，Priority=200，归一化后 × 500），TRES 贡献 9 分（申请了 GPU）。创建 urgent QOS 检查现有 QOS sacctmgr show qos format=Name,Priority,MaxTRES,MaxWall,MaxJobsPU | column -t 实际输出示例： Name Priority MaxTRES MaxWall MaxJobsPU normal 0 - 64 multi 0 7-00:00:00 14 single 0 cpu=1,gres/gpu+ 7-00:00:00 100 quick 0 12:00:00 120 urgent 200 - - 可以看到 urgent QOS 的 Priority=200，明显高于其他 QOS 的 0。创建并设置参数 sacctmgr add qos urgent \ priority=200 \ MaxJobsPU=200 \ MaxSubmitPU=200 \ MaxWall=02:00:00 \ MaxTRESPU=gres/gpu=4 参数说明： priority=200：QOS 优先级值，会被归一化后参与计算 MaxJobsPU：Per User，每用户最多运行作业数 MaxSubmitPU：Per User，每用户最多提交作业数 MaxWall：最长运行时间 MaxTRESPU：Per User，每用户最多 GPU 数修改 QOS（可选）： # 调整优先级 sacctmgr modify qos urgent set priority=300 # 设置组级别限制（所有用户共享） sacctmgr modify qos urgent set GrpTRES=gres/gpu=32 GrpJobs=12 配置 Partition 白名单检查分区配置： scontrol show partition quick | egrep 'Allow|Default' 实际输出示例： AllowGroups=ALL AllowAccounts=project_a AllowQos=ALL 说明 quick 分区允许所有 QOS（AllowQos=ALL），但只允许 project_a 账户。如果分区的 AllowQos 不是 ALL 且缺少 urgent，需要添加： scontrol update PartitionName=urgent AllowQos=urgent,normal AllowAccounts=urgent,project_a 授权用户使用 urgent 添加权限并设置默认 # 授权用户 sacctmgr modify user where name=username set qos+=urgent # 设置默认 QOS和账户，最好做一下 sacctmgr modify user where name=username set DefaultQOS=urgent sacctmgr modify user name=username set DefaultAccount=urgent 验证授权 sacctmgr show assoc where user=username format=User,DefaultQOS,QOS 实际输出示例： User Def QOS QOS username urgent normal,urgent username urgent normal,urgent 说明用户已被授权使用 urgent QOS，且默认 QOS 为 urgent。提交测试作业并检查优先级： sbatch --partition=quick --qos=urgent --wrap="sleep 60" sprio -u username | head 应该看到 QOS 列出现 500 分（= PriorityWeightQOS × 归一化因子）。解决 Invalid account 错误问题诊断错误信息：Invalid account or account/partition combination specified 原因：Slurm 要求 (Account, Partition) 组合必须在 Association 表中存在。排查步骤 1. 检查默认账户 sacctmgr show user username format=User,DefaultAccount 如果默认账户不是 urgent，需要设置： sacctmgr modify user name=username set DefaultAccount=urgent 2. 检查 Association 是否存在 sacctmgr show assoc where user=username format=Cluster,Account,User,Partition,QOS 如果缺少 account=urgent, partition=urgent 的记录： sacctmgr add assoc user=username account=urgent partition=urgent 3. 检查分区允许的账户 scontrol show partition urgent | grep AllowAccounts 确保你的账户在允许列表中。作业提交与验证首次提交（显式指定所有参数） sbatch --partition=urgent --account=urgent --qos=urgent --time=10:00 --wrap="hostname" 简化提交（使用默认值）如果已设置 DefaultAccount=urgent 和 DefaultQOS=urgent： sbatch --partition=urgent --time=10:00 --wrap="hostname" 迁移已提交的 Pending 作业如果作业已提交到 quick 分区，想迁移到 urgent 分区提升优先级： # 错误做法（只改 Partition） scontrol update JobId=123456 Partition=urgent # 报错：Invalid account or account/partition combination specified # 正确做法（同时更新 Account 和 Partition） scontrol update JobId=123456 Account=urgent Partition=urgent 原因：urgent 分区只允许 urgent 账户（AllowAccounts=urgent），而原作业的账户是 project_a，必须一起更新才能匹配。批量迁移多个作业： for jobid in $(squeue -u $USER -t PD -h -o "%i"); do scontrol update JobId=$jobid Account=urgent Partition=urgent done 验证迁移结果： scontrol show job 123456 | grep -E 'Account|Partition|Priority' 迁移成功后，优先级会显著提升（如从 520 → 1104）。检查 QOS 限制 sacctmgr show qos urgent format=Name,MaxTRES,MaxJobsPU,MaxWall 常见 Pending 原因： QOSMaxJobsPerUserLimit：超过 MaxJobsPU QOSMaxGRESPerUser：超过 MaxTRESPU 的 GPU 限制 QOSMaxWallDurationPerJobLimit：申请时间超过 MaxWall 故障排查流程 graph TB A[作业提交失败] --> B{错误类型} B -->|Invalid account| C[检查 DefaultAccount sacctmgr show user] B -->|Invalid QOS| D[检查 QOS 授权 sacctmgr show assoc] B -->|QOSMaxJobsPerUserLimit| E[检查作业数限制 squeue -u xxx -t R] C --> C1{DefaultAccount 正确?} C1 -->|否| C2[设置 DefaultAccount=urgent] C1 -->|是| C3[检查 Association 是否存在 account+partition] C3 --> C4[sacctmgr add assoc] D --> D1{QOS 列包含 urgent?} D1 -->|否| D2[sacctmgr modify user set qos+=urgent] D1 -->|是| D3[检查 QOS 是否存在 sacctmgr show qos] E --> E1[检查 MaxJobsPU 和当前运行作业数] E1 --> E2{超过限制?} E2 -->|是| E3[等待作业完成或 联系管理员] E2 -->|否| E4[检查其他限制 如 MaxTRES] 常见问题 Q1：sprio 显示 QOS 列为 0？可能原因： QOS 的 Priority=0（基准值，无额外加成） PriorityWeightQOS=0（系统未启用 QOS 权重）作业未使用目标 QOS 解决： # 检查并提升 QOS Priority sacctmgr show qos urgent format=Name,Priority sacctmgr modify qos urgent set priority=200 # 检查系统权重 scontrol show config | grep PriorityWeightQOS # 确认作业使用的 QOS scontrol show job 123456 | grep QOS Q2：设置了 DefaultQOS 但不生效？原因：分区的 DefaultQOS 会覆盖用户设置，或脚本中显式指定了其他 QOS。解决： scontrol show partition your_partition | grep DefaultQOS grep "qos" your_script.sh Q3：如何临时降低作业优先级？使用 low QOS 或修改 Nice 值： sbatch --qos=low --wrap="sleep 60" # 或 scontrol update JobId=123456 Nice=10000 Q4：查看 QOS 使用情况？ sacctmgr show qos format=Name,GrpJobs,GrpTRES,MaxJobsPU,MaxTRESPU -p squeue -o "%.10i %.9P %.8j %.8u %.2t %.10M %.6D" | head 实际输出示例： Name|GrpJobs|GrpTRES|MaxJobsPU|MaxTRESPU| normal|||64|gres/gpu=64| multi|500||14|gres/gpu=100| single|500||100|gres/gpu=150| quick|999||120|gres/gpu=200| urgent||||| JOBID PARTITION NAME USER ST TIME NODES 123456 multi ha-110_2 username R 43:46 1 123456 multi ha-110_2 username R 57:46 1 回滚与清理移除用户授权如果之前为使用 urgent 配置了专门的账户和 QOS，回滚时需要全部恢复： # 1. 移除默认 QOS sacctmgr modify user where name=username set DefaultQOS=normal # 2. 恢复默认账户（如果之前改过） sacctmgr modify user where name=username set DefaultAccount=project_a # 3. 取消 QOS 授权 sacctmgr modify user where name=username set qos-=urgent # 4. 验证清理结果 sacctmgr show assoc where user=username format=User,DefaultAccount,DefaultQOS,QOS 期望输出： User DefaultAccount Def QOS QOS username project_a normal normal 删除 QOS（谨慎）检查是否有用户在使用： sacctmgr show assoc format=User,QOS | grep urgent 确认无人使用后删除： sacctmgr delete qos where name=urgent 建议保留 urgent QOS 供未来复用，只需取消用户授权即可。总结 Slurm QOS 配置的关键步骤：确认 PriorityType=priority/multifactor 已启用创建 QOS 并设置 Priority 和资源限制配置 Partition 允许该 QOS 授权用户并设置默认 QOS 确保 (Account, Partition) 组合存在于 Association 使用 sprio 验证优先级变化掌握这些要点后，你可以灵活应对各种作业调度需求。

Techniques · 2025-12-02

【实战教程】使用 frp 实现内网穿透：从零搭建安全的远程访问方案

Techniques · 2025-11-02

【笔记整理|2024-07】Linux系统管理与HPC集群运维：从基础命令到SLURM作业调度

【笔记整理|2024-07】Linux系统管理与HPC集群运维：从基础命令到SLURM作业调度引言 Linux系统管理和HPC集群运维是计算科学研究的基石。无论是本地工作站还是大型计算集群，掌握Linux系统管理技能都是必不可少的。本文整理了从技术讨论中提取的Linux系统管理和HPC集群运维的关键知识和实用技巧，涵盖从基础命令到高级作业调度的各个方面。 Linux基础命令与系统管理系统信息查看了解系统基本信息是系统管理的第一步。有趣的知识： usr代表Unix System Resources，而不是user！用户与组管理 Linux系统中的用户和组管理是多用户环境下的基础操作。要在Linux系统中查看用户组，可以使用以下命令。usermod命令是一个用于修改用户属性的强大工具，其中包括将用户添加到现有用户组的功能。用户组管理的重要性：操作系统具有拥有完全权限的用户。然而，由于该用户不能与登录到系统的人员共享，因此他们临时与其他用户共享部分权限。 SSH密钥管理 SSH密钥是远程管理和自动化任务的核心。执行ssh-keygen命令生成密钥对。我们为每个人只存储一个SSH公钥。公钥可以与世界上的任何人共享（因此称为公钥）。只有您应该访问您的私钥。虚拟内存管理 Linux系统的虚拟内存管理对于保证大规模计算任务的稳定运行至关重要。在Linux中，当物理内存被耗尽时，会使用swap的虚拟内存（较慢）。当物理内存和虚拟内存都耗尽时就会出现程序跑不起来、启动这个进程会杀死另外一个进程的情况，以保证程序的良好运行。包管理不同的Linux发行版使用不同的包管理系统。面对如此多样的指令集结构，软件开发者想要为每一种架构都编译一份软件包十分困难。因此，在Linux生态中，源代码是最通用的软件分发形式。 Zlib包安装问题处理： zlib的官网打不开，apt-get install zlib也找不到软件包，貌似不在软件源里。解决方法是打开Ubuntu Software Center，搜索zlib，找到zlib1g-dev这个包，安装成功。使用APT安装Zlib： sudo apt install zlib1g # 如果需要开发文件（头文件和静态库） sudo apt install zlib1g-dev 模块管理系统在HPC环境中，模块管理系统是软件环境配置的关键。 module avail # 显示可以使用的模块 SLURM作业调度系统作业提交与资源管理 SLURM是最常用的HPC作业调度系统之一，合理配置作业参数可以显著提高计算效率。 #SBATCH --exclude=node4,node5,node7,node8,node9 节点选择策略： –nodelist只能指定一个节点，但#SBATCH –exclude=node[1-16]这种范围表示法是可行的。作业依赖与流程管理复杂的计算流程通常需要作业之间的依赖关系管理： SLURM依赖作业提交指南： https://bioinformaticsworkbook.org/Appendix/HPC/SLURM/submitting-dependency-jobs-using-slurm.html#gsc.tab=0 作业状态监控实时监控作业状态是集群管理的重要功能： sacct --starttime=2024-06-29 --format=JobID%10,User%20,Partition,Submit,Start,Elapsed,AllocTRES%50 -X 作业控制作业的暂停、恢复和取消是日常管理操作： scontrol suspend jobid 用户账户管理在SLURM集群中管理用户账户是系统管理员的职责： sacctmgr add user User=${u} Account=urgent 云计算与远程服务 AWS EC2使用 AWS EC2是常用的云计算平台，掌握基本操作非常重要，包括文件上传和下载等操作。环境变量配置合理配置环境变量可以简化日常操作： export TZ='Asia/Shanghai' 文件系统与数据管理文件压缩与解压数据压缩和归档是数据管理的必备技能。要清理pip的缓存，可以使用以下命令： pip cache purge # 清除所有缓存 pip cache remove <package_name> # 清除特定包的缓存 pip cache dir # 查看缓存路径参考： Zip文件操作指南文件搜索与过滤高效的文件搜索和过滤可以大大提高工作效率。要查找恰好包含两个连字符的目录名，需要将grep模式”锚定”以匹配整行。排除特定文件可以使用-X选项。 Git版本控制 Git是现代科研项目的标准版本控制工具。合理配置.gitignore规则可以避免提交不必要的文件。编译与开发环境编译系统理解理解编译系统的工作原理有助于解决编译问题。 gcc的编译其实是四个过程的集合，分别是预处理（preprocessing）、编译（compilation）、汇编（assembly）、链接（linking），分别由cpp、cc1、as、ld这四个程序完成，gcc是它们的封装。 C++编程技巧掌握C++编程技巧可以提高开发效率。在C++中，字符”*“是一个指针，包含变量的值。++i有时可以比i++更快，并且永远不会更慢。对于基本数据类型，编译器很可能会修复并优化掉任何不必要的复制。对于迭代器这更困难，对于用户定义类型可能完全不可能。 Makefile编写 Makefile是自动化编译的重要工具，可以将多个C++源文件分别编译成不同的可执行文件。 LaTeX排版系统 LaTeX是科学文档排版的标准工具。可以使用apt命令安装LaTeX： sudo apt install texlive-latex-extra sudo apt install texlive-xetex # XeLaTeX sudo apt install texlive-bibtex-extra # BibTeX支持中文字体支持问题：错误”LaTeX Error: File `ctexbook.cls’ not found”表示缺少CTEX包，该包是LaTeX中用于排版中文文档的文档类文件。参考： LaTeX安装指南系统诊断与性能优化系统监控工具系统监控是保证服务稳定运行的关键。参考： VS Code缓存清理软件安装问题解决解决软件安装过程中的常见问题，如”No rule to make target ‘X’“通常表示文件缺失。云原生与容器技术虚拟化技术虚拟化技术是现代云计算的基础。 Hypervisor（也称为虚拟机监视器或VMM）是创建和运行虚拟机（VM）的软件。虚拟化类型： Type 1 hypervisor：直接在主机硬件上运行以控制硬件并管理客户操作系统。例如VMware ESXi、Microsoft Hyper-V和Xen。 Linux发行版选择选择合适的Linux发行版对于特定应用场景很重要。 netinst版本是一个小型ISO镜像，仅包含启动安装所需的文件。DVD-1版本是一个大型ISO镜像，包含桌面环境、应用程序和其他软件。总结与最佳实践基础命令：掌握Linux基础命令是系统管理的基础，理解命令的内部工作原理有助于问题排查用户管理：合理配置用户和组权限，确保系统的安全性和可管理性 SSH密钥：妥善管理SSH密钥，建立安全的远程访问机制虚拟内存：合理配置swap空间，避免因内存不足导致的程序异常 SLURM调度：熟练掌握SLURM作业调度系统，优化计算资源使用版本控制：建立良好的Git使用习惯，确保研究过程的可追溯性编译环境：理解编译原理，能够独立解决编译和链接问题监控诊断：建立系统监控体系，及时发现和解决潜在问题通过这些系统管理和集群运维技能的掌握，可以为计算科学研究提供稳定、高效的计算环境支持。参考资源 SLURM依赖作业提交指南文件压缩操作指南 Linux系统监控指南 SLURM环境变量文档 LaTeX在Ubuntu上安装指南

Techniques · 2025-10-11

NVIDIA & CUDA 环境综合诊断命令集合 (简洁版)

好的，遵照您的要求，我们对推文进行最后的更新和完善。更新点1：简化网络连接步骤，直接提示在Live USB图形界面中联网。更新点2：增加关于 apt install cuda 的补充说明，解释它与驱动安装的关系。更新点3：在文末附上您提供的官方参考链接。更新点4 (新增)：增加一个全新的章节，详细复盘和讲解我们是如何根据报错信息一步步调试加密分区挂载问题的。 Linux系统「急诊室」：一次NVIDIA驱动引发的“引导风暴”终极复盘写在前面这是一篇写给Linux用户，尤其是Pop!_OS、Ubuntu等发行版使用者的深度故障排除指南。它源于一次真实的、由NVIDIA驱动安装中断引发的、持续数天的系统“急救”经历。我们将从最初的“无法启动”开始，层层剥茧，深入探索UEFI引导、LUKS全盘加密、LVM逻辑卷管理、initramfs启动机制以及 systemd-boot引导加载程序的每一个细节。本文的目标不仅是提供解决方案，更是希望通过复盘每一步的报错、诊断和思考过程，帮助您建立一套处理Linux复杂引导问题的系统性思维。第一幕：风暴之始 - 系统崩溃与初步诊断故事始于一次常规的CUDA安装。在通过NVIDIA官网教程添加apt源并安装CUDA的过程中，系统意外中断。重启后，熟悉的图形界面消失，我们被抛入了冰冷的“紧急模式” (emergency mode)。症状1：无尽的紧急模式循环系统提示 You are in emergency mode，并建议运行日志命令。但任何修复尝试，如 apt upgrade，都会在失败后让系统重新陷入这个模式。症状2：明确的引导错误日志中最核心的错误指向了引导分区： kernelstub: ERROR: Could not find a block device for the partition NoBlockDevError: Couldn't find the block device for /boot/efi 解读：kernelstub (Pop!_OS的引导管理工具) 无法找到EFI系统分区(ESP)。这是引导流程中的第一处“骨折”。如何识别我的分区？在进行任何修复前，首先要做的就是“知己知彼”，了解自己硬盘的分区结构。在紧急模式或Live USB的终端中，可以使用 lsblk -f 或 sudo parted -ls 命令。 EFI分区 (/boot/efi): 寻找一个大小在 500MB 到 1GB 左右、文件系统类型为 vfat (FAT32) 的分区。在 parted 的输出中，它通常带有 boot, esp 标记。在我们的案例中，它是 /dev/nvme0n1p1。加密的根分区: 这通常是硬盘上最大的那个分区。在 lsblk -f 的输出中，它的文件系统类型会显示为 crypto_LUKS。在我们的案例中，它是 /dev/nvme0n1p3。恢复分区: Pop!_OS特有的分区，大小通常为4GB左右，文件系统也是 vfat，parted 输出的标签为 recovery。在我们的案例中，它是 /dev/nvme0n1p2。第二幕：急救现场 - initramfs 的“瘫痪” 明确分区后，我们尝试在紧急模式下手动挂载EFI分区，但遭遇了更深层的失败。 FAT-fs (nvme0n1p1): IO charset iso8859-1 not found 这个错误说明，紧急模式这个微型系统自身已损坏，缺少了读写EFI分区所必需的基础内核模块。这意味着无法在紧急模式内部完成修复。有时，系统会直接进入一个功能更孱弱的 (initramfs) 命令行，并抛出致命错误： ALERT! UUID=... does not exist. Dropping to a shell! 这同样印证了 initramfs 镜像已损坏，它内部的引导脚本找不到正确的根分区地址，导致引导过程彻底中断。核心病因：所有这些症状都指向了同一个罪魁祸首——一次不完整的NVIDIA驱动/CUDA安装，生成了一个残缺的initramfs启动镜像。第三幕：侦探工作 - 调试复杂的加密分区在进入最终修复流程前，一个关键的步骤是在 Live USB 环境中成功挂载主系统分区。这个过程本身就是一次精彩的“侦探工作”，我们通过解读错误信息，层层揭开了硬盘的“加密-LVM”复合结构。第一次尝试：直接挂载我们首先尝试了最直接的 mount 命令： sudo mount /dev/nvme0n1p3 /mnt 随即遭遇了第一个线索： mount: /mnt: unknown filesystem type 'crypto_LUKS'. 线索解读：系统明确告诉我们，/dev/nvme0n1p3 不是一个可以直接挂载的文件系统，而是一个 crypto_LUKS 加密卷。就像一个上了锁的保险箱，我们不能直接打开，必须先用钥匙解锁。第二次尝试：解锁加密层根据线索，我们使用正确的“钥匙”——cryptsetup 工具来解锁： sudo cryptsetup luksOpen /dev/nvme0n1p3 unlocked_root 输入密码后，我们满怀信心地再次尝试挂载新出现的虚拟设备 /dev/mapper/unlocked_root，却得到了第二个线索： mount: /mnt: unknown filesystem type 'LVM2_member'. 线索解读：这个错误再次揭示了更深一层的结构。解锁后的设备依然不是最终的文件系统，而是一个 LVM2_member (LVM物理卷)。这说明“保险箱”里装的不是直接可用的文件，而是另一个“文件柜系统”（LVM）。最终方案：激活LVM并挂载有了这个线索，我们知道必须先让系统识别并激活这个“文件柜”，才能拿到最终的文件。 # 激活LVM逻辑卷 sudo vgchange -ay # 挂载LVM中的根分区逻辑卷 sudo mount /dev/mapper/data-root /mnt 这一次，挂载终于成功。通过像侦探一样跟随错误信息的指引，我们成功地手动完成了“解锁保险箱 -> 激活文件柜 -> 取出文件”的整个流程。第四幕：终极救援 - Live USB “无菌手术” 既然内部修复行通，我们就需要一个功能完备的外部“医疗队”——Live USB。 4.1 准备“手术工具” 在另一台电脑上，下载您当前Linux发行版的ISO镜像。使用 BalenaEtcher 等工具，将ISO镜像制作成一个可启动的U盘。将U盘插入故障电脑，开机时进入BIOS/UEFI菜单，选择从U盘启动。在启动选项中，选择 “Try Pop!_OS” 或 “Try Ubuntu”，进入临时的试用系统。进入桌面后，首先连接到您的 Wi-Fi 或有线网络，确保网络通畅。 4.2 进入“无菌操作区”（Chroot 环境）进入Live USB的桌面后，打开一个终端，我们将通过一系列命令，进入到您硬盘上那个“生病”的系统中。解锁LUKS加密卷 (使用Pop!_OS默认名称 cryptdata)： sudo cryptsetup luksOpen /dev/nvme0n1p3 cryptdata 激活LVM逻辑卷： sudo vgchange -ay 挂载系统分区： sudo mount /dev/mapper/data-root /mnt sudo mount /dev/nvme0n1p1 /mnt/boot/efi 绑定系统目录并进入Chroot： for i in dev dev/pts proc sys run; do sudo mount -B /$i /mnt/$i; done sudo chroot /mnt 执行成功后，您终端的提示符会改变。现在，您下达的所有命令都将直接作用于您硬盘上的系统。 4.3 “清创”与“移植”：修复核心问题在 chroot 环境中，我们将进行一次彻底的“外科手术”。彻底清除病灶（清除所有NVIDIA软件包）: apt-get purge --auto-remove -y '*nvidia*' '*cuda*' 移植“健康器官”（安装新驱动）: # 查找最适合您硬件的推荐驱动 ubuntu-drivers devices # 根据上一步的推荐结果，安装驱动（请将 535 替换为您看到的推荐版本） apt install nvidia-driver-535 生成全新的“免疫系统”（重建 initramfs）: 这是最关键的一步。它会把刚刚干净安装的NVIDIA驱动和所有正确的配置打包进一个新的启动环境中。 update-initramfs -u -k all 4.4 “唤醒病人”：收尾并重启退出 chroot 环境： exit 重新安装引导加载程序 (根据官方指南的最后一步)： sudo bootctl --path=/mnt/boot/efi install 重启电脑： sudo reboot 在电脑重启时，请务必拔掉您的 USB U盘。第五幕：疑难杂症处理（Q&A）问：chroot 中 update-initramfs 报错 Failed to retrieve NVRAM data？答：正常现象，chroot 环境无法访问主板固件。可以临时将 /etc/initramfs/post-update.d/zz-kernelstub 脚本移走，运行完命令后再移回。问：chroot 中 nvidia-smi 报错 Driver/library version mismatch？答：正常现象。chroot 共享的是 Live USB 的内核，与您主系统的驱动程序版本不匹配是必然的。判断驱动是否安装成功，应以 apt 和 update-initramfs 命令是否报错为准。问：修复后重启默认进入了 recovery 模式？答：说明主系统引导项已修复，但默认顺序不对。可以在 Recovery 环境中 sudo mount /dev/nvme0n1p1 /boot/efi，然后 sudo nano /boot/efi/loader/loader.conf，手动将 default 行改为 default Pop_OS-current.conf。补充说明：关于CUDA安装和驱动选择问：我可以直接 apt install cuda -y 吗？它会自动安装驱动吗？答：可以，这通常是一个更便捷的选择。 apt install cuda 或 apt install cuda-toolkit 在安装 CUDA 工具包时，会自动将一个经过NVIDIA官方测试、兼容该CUDA版本的专有驱动作为依赖项一并安装。这意味着您不需要在安装CUDA后再手动 apt install nvidia-driver-XXX。一步 apt install cuda 即可同时搞定工具包和兼容的专有驱动。在上面的修复流程中，您可以在 4.3节的第2步，将 ubuntu-drivers devices 和 apt install nvidia-driver-XXX 两条命令，直接替换为 apt install cuda -y。后续步骤不变。结语如果一切顺利，您将会看到熟悉的图形化解密界面，输入密码后，久违的桌面就会重新出现。这次看似复杂的修复过程，揭示了现代Linux系统启动的连锁效应：一个损坏的驱动程序，足以让整个精密的引导流程在第一步就宣告失败。通过Live USB和Chroot，我们获得了在系统外部进行“心脏搭桥手术”的能力，最终清除了病灶，恢复了系统的健康。希望这篇“急救”指南能为您提供解决此类棘手问题的信心和方法。参考资料 System76 Official Bootloader Repair Guide: https://support.system76.com/articles/bootloader/ 最后再给一个装驱动检查各种东西版本的命令集合吧： #!/bin/bash # NVIDIA & CUDA 环境综合诊断命令集合 (简洁版) echo "=============== HARDWARE ===============" # 检查显卡硬件、驱动及内核模块使用情况 lspci -k | grep -A 3 -i "VGA|3D|Display" echo "\n=============== KERNEL & OS ===============" # 查看当前运行内核、已安装内核及系统版本 uname -r ls /boot/vmlinuz-* lsb_release -a echo "\n=============== DRIVER MODULES ===============" # 检查NVIDIA内核模块加载状态 lsmod | grep nvidia # 检查DKMS编译状态 (非常关键) dkms status # 查看已加载驱动的版本 (如果模块已加载) cat /proc/driver/nvidia/version echo "\n=============== PACKAGES (APT) ===============" # 查看所有已安装的NVIDIA和CUDA相关软件包 dpkg -l | grep -i nvidia echo "---" dpkg -l | grep -i cuda # 查看关键包的软件源策略 echo "---" apt-cache policy nvidia-dkms-$(dpkg -l | grep -o 'nvidia-dkms-[0-9]\+' | head -n 1 | cut -d- -f3) apt-cache policy cuda-toolkit echo "\n=============== NVIDIA & CUDA STATUS ===============" # 检查NVIDIA驱动通信状态 nvidia-smi # 检查CUDA编译器版本 nvcc --version # 检查OpenGL渲染器 glxinfo | grep "OpenGL renderer" echo "\n=============== SYSTEM LOGS (LAST 20) ===============" # 从内核日志和系统日志中筛选最新的NVIDIA相关错误 dmesg | grep -i -E "nvidia|nvrm" | tail -n 20 echo "---" journalctl -b | grep -i -E "nvidia|nvrm" | tail -n 20 echo -e "\n诊断完毕。"

Techniques · 2025-10-08

CentOS 7 升级到 Rocky Linux 8/9 完整指南

Techniques · 2025-10-08

CentOS 7升级Rocky Linux 8无网络环境解决方案

Techniques · 2025-10-08

Ubuntu Virtual Memory (Swap) Setup Tutorial: Enhance System Performance

在 Ubuntu 中增加虚拟内存（Swap）教程在 Ubuntu 系统中增加虚拟内存（即交换空间，Swap）可以有效提升系统在内存不足时的性能。以下是详细的操作步骤：一、检查当前交换空间首先，您需要检查当前系统的交换空间情况。打开终端并运行以下命令： sudo swapon --show 如果命令没有输出，说明当前系统没有启用交换空间。如果有输出，则会显示现有交换文件或分区的信息（例如 /swapfile）。二、创建新的交换文件方法一：使用 fallocate 命令（推荐）运行以下命令创建一个新的交换文件： sudo fallocate -l 4G /swapfile_new -l 4G：指定交换文件大小为 4GB。您可以根据需求调整大小，例如使用 8G 表示 8GB。 /swapfile_new：新交换文件的路径。您可以自定义文件名，但需确保后续步骤中路径一致。方法二：使用 dd 命令（若 fallocate 不可用）如果 fallocate 命令不可用，可以使用 dd 命令创建交换文件： sudo dd if=/dev/zero of=/swapfile_new bs=1G count=4 bs=1G：每次写入 1GB 数据。 count=4：写入 4 次，生成 4GB 文件。三、设置交换文件的权限为了安全起见，设置交换文件的权限，使其仅限 root 用户访问： sudo chmod 600 /swapfile_new 四、格式化交换文件将创建的文件标记为交换空间： sudo mkswap /swapfile_new 五、启用交换文件运行以下命令启用新创建的交换文件： sudo swapon /swapfile_new 六、验证交换空间检查新增的交换空间是否生效： sudo swapon --show 您还可以查看内存使用情况以确认交换空间的变化： free -h 七、配置开机自动挂载为了使交换文件在系统重启后仍然有效，需要将其添加到 /etc/fstab 文件中：打开 /etc/fstab 文件进行编辑： sudo nano /etc/fstab 在文件末尾添加以下内容： /swapfile_new none swap sw 0 0 保存并退出编辑器（在 nano 中，按 Ctrl+O 保存，按 Ctrl+X 退出）。注意事项调整交换文件大小：根据系统需求和使用场景调整交换文件的大小。一般建议交换文件大小为物理内存的 1-2 倍，但具体大小取决于您的应用场景。权限管理：确保交换文件的权限设置正确，避免非授权访问。性能考量：虽然增加交换空间可以缓解内存不足的问题，但过度依赖交换空间可能会降低系统性能，因为磁盘 I/O 速度远低于内存。通过以上步骤，您可以成功增加 Ubuntu 系统的虚拟内存（Swap），从而提升系统的整体性能和稳定性。希望这份教程对您有所帮助！如果您在操作过程中遇到任何问题，欢迎随时提问。 Pandoc 生成 PDF 时字体问题解决方案教程一、问题概述在使用 Pandoc 将 Markdown 文件生成 PDF 时，如果指定使用 Times New Roman 字体，可能会遇到错误。这是因为 Times New Roman 是 Windows 系统的默认字体，在 Linux 或 macOS 上默认未安装。此外，对于中文支持，也需要确保系统中存在相应的中文字体。二、检查字体是否安装在 Linux 系统中打开终端，运行以下命令查看系统中已安装的字体： fc-list :lang=zh # 查看中文字体 fc-list | grep "Times New Roman" # 查找 Times New Roman 字体如果没有输出，说明系统中未安装该字体。在 macOS 系统中使用 Font Book 应用程序检查字体是否安装。在 Windows 系统中打开“字体”文件夹（通常在 C:\Windows\Fonts），查找“Times New Roman”字体。三、安装所需字体安装 Times New Roman 字体对于 Ubuntu/Debian 系统：运行以下命令安装 Microsoft 核心字体，其中包含 Times New Roman： sudo apt-get update sudo apt-get install ttf-mscorefonts-installer 在安装过程中，可能需要接受许可协议。安装完成后，运行以下命令刷新字体缓存： sudo fc-cache -fv 对于 CentOS/RHEL 系统：使用以下命令安装字体： sudo yum install curl curl-devel sudo rpm -Uvh http://li.nux.ro/download/fedora/epel/5/i386/epel-release-5-4.noarch.rpm sudo yum install ttf-mscorefonts-installer 对于 macOS 系统：从官方渠道下载并安装 Microsoft Office for Mac，它会附带安装 Times New Roman 字体。或者，您可以手动下载字体文件并安装。安装中文支持字体如果您需要在 PDF 中显示中文，还需要安装中文字体。例如，在 Ubuntu/Debian 系统上，可以安装 texlive-lang-chinese 包： sudo apt install texlive-lang-chinese 该包包含中文支持的宏包（如 ctex），是 Debian 官方维护的包，具有良好的兼容性。四、配置 Pandoc 使用正确字体在 Pandoc 命令中指定字体时，确保使用的字体名称与系统中实际存在的字体名称完全匹配。例如： pandoc input.md -o output.pdf --pdf-engine=xelatex --css style.css -V mainfont="Times New Roman" -V CJKmainfont="AR PL UMing CN" mainfont：指定西文字体。 CJKmainfont：指定中文字体。五、生成 PDF 的 Python 函数示例以下是一个使用 Pandoc 生成 PDF 的 Python 函数示例，确保路径和字体名称正确： import subprocess import logging from pathlib import Path log = logging.getLogger(__name__) def generate_pdf_with_pandoc(md_path: Path, css_path: Path, output_pdf_path: Path) -> bool: """ 使用 Pandoc 和 XeLaTeX 生成 PDF 文件。参数: md_path: 输入的 Markdown 文件路径。 css_path: CSS 文件路径（可选）。 output_pdf_path: 输出的 PDF 文件路径。返回: PDF 生成成功返回 True，失败返回 False。 """ log.info(f"Attempting PDF generation with Pandoc for {md_path}.") pandoc_cmd = [ 'pandoc', str(md_path), '-o', str(output_pdf_path), '--pdf-engine=xelatex', '--css', str(css_path), '-V', 'mainfont=Times New Roman', '-V', 'CJKmainfont=AR PL UMing CN' ] result = subprocess.run(pandoc_cmd, capture_output=True, text=True, encoding='utf-8') if result.returncode != 0: log.error(f"Pandoc failed. Stderr: {result.stderr}") return False log.info(f"Successfully generated PDF with Pandoc at {output_pdf_path}") return True 六、验证和测试验证字体安装：运行 fc-list 命令，检查是否列出了 Times New Roman 和中文字体。确保字体名称与 Pandoc 命令中指定的名称完全一致。测试 PDF 生成：使用上述 Python 函数或直接运行 Pandoc 命令生成 PDF。打开生成的 PDF 文件，检查字体显示是否正确。七、总结通过以上步骤，您可以解决 Pandoc 在生成 PDF 时找不到指定字体的问题。确保系统中安装了所需的字体，并在 Pandoc 命令中正确指定字体名称。对于中文支持，安装 texlive-lang-chinese 包是一个推荐的解决方案。希望这份教程能帮助您顺利完成 PDF 生成任务。如果您在操作过程中遇到任何问题或需要进一步的帮助，欢迎随时提问。

Techniques · 2025-10-08

【笔记整理|2023-09+2024年上半年】系统运维与故障排除实用指南

【笔记整理|2023-09+2024年上半年】系统运维与故障排除实用指南本文汇总了Linux系统运维、远程连接、桌面环境配置以及常见故障排除的实用技巧和解决方案。系统监控与性能诊断系统兼容性问题识别软件兼容性检查如果PyMOL和ChimeraX都有问题，通常是系统级别的问题，需要检查：显卡驱动是否正常 OpenGL支持是否完整系统库文件是否缺失键盘输入问题在某些终端环境下，VMD无法正常响应上下左右键，这通常与gnome terminal的设置有关。显示器相关问题每次关闭显示器后，dash to panel任务栏会消失，系统默认的会显示，这可能是扩展与电源管理的兼容性问题。远程连接解决方案 ToDesk使用体验 ToDesk在Linux环境下的特点：无法在Pop!_OS中自动调整布局，但能记住布局设置 Linux版本不支持复制粘贴功能与Windows版本功能有差异 AnyDesk配置管理安装问题解决 Fedora AnyDesk安装问题: https://discussion.fedoraproject.org/t/cannot-install-anydesk/73854 自启动管理 Ubuntu禁用AnyDesk自启动: https://devicetests.com/disable-anydesk-autostart-ubuntu 建议直接禁用自启动功能，按需启动。命令行工具技巧跨平台命令对比 Windows PowerShell替代方案在Windows系统中，没有与Linux系统中的tac命令完全相同的命令。可以使用PowerShell中的Get-Content命令和-Reverse参数来实现类似功能。 findstr命令使用 findstr命令类似于Unix系统中的grep，用于在文件中进行文本搜索： findstr "xxx" filename 文件批量处理 sed批量替换批量文件名处理时，Linux命令更高效： # 批量替换文件中的路径 sed -i 's/E:\\GitHub-repo\\notes\\research\\/https\:\/\/cdn.jsdelivr.net\/gh\/username\/notes\@master\/research\//g' *.md # 批量替换assets路径 sed -i 's/assets\\/assets\//g' *.md ZIP压缩操作 Linux ZIP命令教程: https://www.runoob.com/linux/linux-comm-zip.html 桌面环境配置与故障排除 GNOME扩展管理扩展兼容性问题检查GNOME版本兼容性： gnome-shell --version 某些扩展可能在特定版本的GNOME下存在兼容性问题。 Dash to Panel配置 Dash to Panel扩展: https://extensions.gnome.org/extension/1160/dash-to-panel/ 配置注意事项：检查GNOME Shell版本兼容性避免与其他任务栏扩展冲突注意电源管理对扩展的影响工作区管理动态工作区设置 # 禁用动态工作区，使用固定数量 gsettings set org.gnome.mutter dynamic-workspaces false 建议设置1-4个固定工作区，而不是使用默认的Home设置。窗口管理优化 Ubuntu单击任务栏图标最小化窗口: https://cn.linux-console.net/?p=17727 多显示器配置工作区管理在多显示器环境下的注意事项：不是在所有监视器上都显示工作区可以设置主显示器和辅助显示器的不同行为 Web服务故障排除端口占用问题 # 检查端口占用情况 sudo apt-get update # 释放被占用的端口端口释放指南: https://medium.com/@antonrosh/address-already-in-use-a-simple-guide-to-freeing-up-ports-fbc6a3822983 WebView错误处理常见错误：Error loading webview: Error: Could not register service workers: TypeError: Failed WebView错误解决方案: https://stackoverflow.com/questions/67698176/error-loading-webview-error-could-not-register-service-workers-typeerror-fai 网络代理与连接问题代理配置管理 # 手动设置代理 export http_proxy="http://127.0.0.1:7890" CFW代理配置使用经验：现在CFW不影响conda，配置manual proxy即可无法在重启后CFW缓慢启动前连接网络，但手动配置可以工作网络连接故障排除重启后网络连接问题的解决方案：检查网络服务状态验证代理配置测试DNS解析检查防火墙设置开发工具集成 Python外部程序调用 import subprocess # 调用外部程序的标准方法 def run_external_command(command): result = subprocess.run(command, shell=True, capture_output=True, text=True) return result.stdout, result.stderr 包管理集成使用subprocess调用系统包管理器： # 调用antechamber等外部工具 def call_antechamber(input_file, output_file): cmd = f"antechamber -i {input_file} -o {output_file}" result = subprocess.run(cmd, shell=True, capture_output=True, text=True) return result JSON数据处理 import json # 加载JSON数据的标准方法 with open('data.json', 'r') as f: data = json.load(f) 系统文档与术语技术术语翻译 de facto：事实上的标准 Software Development Kit (SDK)：软件开发工具包编程概念 Arrow Functions JavaScript箭头函数: https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Functions/Arrow_functions 数据库与版本控制 Git版本控制扩展基于Git版本控制的关系型数据库Dolt: https://jasonkayzk.github.io/2024/01/21/%E5%9F%BA%E4%BA%8EGit%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B6%E7%9A%84%E5%85%B3%E7%B3%BB%E5%9E%8B%E6%95%B0%E6%8D%AE%E5%BA%93Dolt/ 这种新型数据库结合了版本控制的优势。 LaTeX与文档处理 LaTeX环境配置基础安装 # 安装LaTeX基础包 sudo apt install texlive-latex-extra # 安装XeLaTeX sudo apt install texlive-xetex # 安装BibTeX支持 sudo apt install texlive-bibtex-extra Linux LaTeX安装指南: https://linuxconfig.org/how-to-install-latex-on-ubuntu-20-04-focal-fossa-linux 中文支持处理”LaTeX Error: File `ctexbook.cls’ not found”错误：这个错误表明缺少CTEX包，该包用于LaTeX中文文档的排版。需要安装相应的中文支持包。 Markdown到PDF转换 VSCode Markdown PDF插件: https://github.com/yzane/vscode-markdown-pdf?tab=readme-ov-file#usage Docker容器化 Docker配置问题 Linux Docker配置: https://blognas.hwb0307.com/linux/docker/654 容器化部署在开发环境中的重要性日益增加。 API与Web开发 GitHub相关服务 GitHub Discussions快速入门: https://docs.github.com/zh/discussions/quickstart GitHub Apps Giscus: https://github.com/apps/giscus Vue.js开发 Vue.js组合式函数: https://cn.vuejs.org/guide/reusability/composables 故障排除最佳实践系统问题诊断流程问题重现：确认问题的可重现性日志检查：查看系统和应用程序日志资源监控：检查CPU、内存、磁盘使用情况服务状态：验证相关服务的运行状态配置验证：检查关键配置文件权限确认：验证文件和目录权限网络问题排查连通性测试：ping、traceroute 端口检查：netstat、ss命令 DNS解析：nslookup、dig命令防火墙状态：iptables、ufw检查代理配置：环境变量和应用配置桌面环境问题解决重启服务：重启显示管理器重置配置：备份后重置用户配置扩展管理：禁用可疑扩展兼容性检查：验证软件版本兼容性监控与维护系统健康检查定期进行系统健康检查：磁盘空间使用情况系统更新状态服务运行状态网络连接质量安全更新应用预防性维护定期清理临时文件更新系统软件包检查硬件健康状态备份重要配置文件监控系统性能指标本文基于2023年9月至2024年上半年的系统运维实践整理，涵盖常见运维问题的诊断方法和解决方案

Techniques · 2025-10-08

【笔记整理|2023-09】Linux科研开发环境配置和管理指南

【笔记整理|2023-09】Linux科研开发环境配置和管理指南本文总结了在Linux环境下进行科研开发的实用配置技巧、常见问题解决方案和工具推荐。跨平台文件同步和远程控制 KDE Connect：跨设备无缝协作功能特色 KDE Connect是一个强大的跨平台设备协作工具，支持Windows、Linux、macOS、iOS、Android之间的无缝连接： # 安装KDE Connect sudo apt install kdeconnect # Ubuntu/Debian sudo dnf install kdeconnect # Fedora 主要功能 KDE Connect虽然不是投屏软件，但功能非常丰富：文件传输：电脑文件右键直接发送至手机手机图片视频可发送到电脑指定文件夹无需蓝牙，只要在同一局域网即可远程控制：手机作为电脑遥控器音乐视频播放控制（音量、进度、暂停等） PPT演示时手机可作为翻页器通知同步：手机电话、短信通知同步到电脑在电脑上让手机发出声音找手机剪贴板共享：跨设备剪贴板同步复制粘贴无缝衔接命令执行：预设Linux命令，手机远程执行支持关机、锁屏、自定义脚本等远程桌面解决方案对比 ToDesk 官网：ToDesk Linux版：https://www.todesk.com/linux.html 优点：免费，跨平台支持好缺点： Linux不支持复制粘贴功能任务栏显示问题（特别是全屏模式）输入法切换可能有问题 AnyDesk 安装和配置： # 禁用自启动 # 参考：[AnyDesk禁用自启动指南](https://devicetests.com/disable-anydesk-autostart-ubuntu)：https://devicetests.com/disable-anydesk-autostart-ubuntu # 会话管理 # 参考：[AnyDesk会话管理](https://support.anydesk.com/knowledge/disconnecting-sessions)：https://support.anydesk.com/knowledge/disconnecting-sessions Fedora安装问题：Fedora论坛讨论：https://discussion.fedoraproject.org/t/cannot-install-anydesk/73854 代理和网络配置代理软件配置 electron-ssr配置 # 启动命令（解决沙盒问题） /usr/bin/electron-ssr --no-sandbox # Fedora38环境下使用 # electron-ssr在conda环境中不会报错相关问题讨论：Electron-SSR GitHub问题：https://github.com/shadowsocksrr/electron-ssr/issues/126 Clash for Windows Linux版配置指南：Linux Clash配置教程：https://bestoko.cc/p/linux-clash-for-windows/ 其他代理工具 go-proxy-bingai设置：GitHub项目：https://github.com/adams549659584/go-proxy-bingai 网络连接问题诊断 Fedora镜像源问题 # 常见错误：无法连接到Fedora镜像源 Failed to search for file: cannot update repo 'fedora': Cannot prepare internal mirrorlist: Curl error (7): Couldn't connect to server for https://mirrors.fedoraproject.org/metalink?repo=fedora-38&arch=x86_64 [Failed to connect to 127.0.0.1 port 12333 after 0 ms: Couldn't connect to server] 解决方案：检查代理设置是否正确尝试更换镜像源检查防火墙和网络配置开发工具配置 Visual Studio Code 扩展开发 # VSCode扩展路径 /home/user/.vscode/extensions/md-highlighter-0.0.1 # 发布token配置 vscode token: your_token_here 已知问题虚拟桌面恢复：VSCode或Firefox无法在Fedora KDE中将窗口恢复到正确的虚拟桌面，这是已知问题调试配置：缺少.vscode文件夹可能导致调试扩展无法识别相关讨论：VSCode VSCE GitHub问题：https://github.com/microsoft/vscode-vsce/issues/419 Linux原生应用微信支持现在优麒麟下有Linux原生的微信，虽然功能简陋了一些，但是有比没有强，基本的聊天需求是可以被满足的。文件权限管理 # 设置可执行权限 chmod +x /path/to/Multiwfn_3.8_dev_bin_Linux/Multiwfn # 批量权限设置 find . -type f -exec chmod a+x {} \; 系统优化和故障排除桌面环境配置 KDE Plasma优化启动速度：Plasma启动需要25-40秒（可能与NVIDIA显卡有关）应用启动器：左下角的”f”图标（Plasma application launchers）窗口恢复：重启后只有Firefox能够恢复窗口状态虚拟桌面管理目前VSCode和Firefox在Fedora KDE中无法正确恢复虚拟桌面窗口位置。编译工具链配置 Devtoolset（CentOS/RHEL） Devtoolset是一个用于在Red Hat Enterprise Linux (RHEL)和CentOS系统上安装和使用多个版本的编译器和开发工具的软件集合。它提供了更新的编译器版本，以便开发人员可以使用最新的功能和优化。包管理问题 # Conda包损坏问题 InvalidArchiveError("Error with archive /home/user/anaconda3/pkgs/gxx_impl_linux-64-10.4.0-h7ee1905_16.tar.bz2. You probably need to delete and re-download or re-create this file.") # 解决方案：清理并重新下载 conda clean -a 端口和服务管理端口占用检查 # 查看端口12333的使用情况 sudo lsof -i :12333 # 识别占用端口的进程 lsof -i :port_number 系统服务管理 # 检查系统版本 gnome-shell --version # 网络服务诊断 ping -c 4 mirrors.fedoraproject.org 文档和教程资源 Bash编程 Bash序列表达式：https://linuxize.com/post/bash-sequence-expression/ Python字典排序：https://www.golinuxcloud.com/python-sort-dictionary-by-key/ 网络分析工具 import networkx as nx NetworkX文档：NetworkX算法文档：https://networkx.org/documentation/stable/reference/algorithms/traversal.html Ubuntu系统资源 Amber22安装指南：http://archive.ambermd.org/202302/att-0090/Amber_22_and_Tools_22_install_Ubuntu_22.pdf 性能优化建议 GPU计算支持配置GPU支持的计算环境： Quick package for Hartree-Fock and DFT electronic stucture calculations, with GPU support. Quick is integrated into sander for QM/MM simulations, and AmberTools23 contains significant performance improvements, a new geometry optimizer, and support for spin-unrestricted calculations. 跨平台兼容性注意Linux和Windows之间文件格式的兼容性：是因为在Linux里面读Windows的chk？某些二进制文件在不同操作系统间可能存在兼容性问题。故障排除检查清单网络连接问题检查代理设置 electron-ssr是否正常运行端口12333是否被占用防火墙设置是否正确包管理问题 conda缓存是否损坏镜像源是否可访问网络连接是否稳定桌面环境问题显示相关 NVIDIA驱动是否正确安装 Plasma启动时间是否异常虚拟桌面功能是否正常应用兼容性 VSCode扩展是否正确安装 .vscode配置文件夹是否存在权限设置是否正确开发环境问题编译工具 GCC版本是否兼容开发库是否完整安装环境变量是否正确设置 Python环境 conda环境是否激活包依赖是否满足路径配置是否正确推荐的Linux发行版选择科研用途推荐 Ubuntu LTS：稳定性好，社区支持强 Fedora：新技术支持好，适合开发优麒麟：中文支持好，有原生微信桌面环境选择 KDE Plasma：功能丰富，可定制性强 GNOME：简洁美观，资源占用相对较低本文基于2023年9-12月技术讨论记录整理，涵盖Linux环境下科研开发的实际经验和解决方案

Techniques · 2025-10-07

Mendelevium

Contact

Linux