RHCA03--硬件监控及内核模块调优

一、CPU性能

1. CPU架构与核心数

• 核心子系统：计算机系统性能由四大核心子系统决定，分别是CPU、内存、磁盘和网络。
• 硬件基础性：硬件性能是调优的基础，例如固态硬盘的先天性能优势无法通过软件调优在机械硬盘上实现。

（1）CPU架构类型

• 查询命令：使用lscpu命令可查看CPU详细信息，包括架构、核心数等。
• 主流架构：
  • x86架构：Intel和AMD为代表的复杂指令集（CISC）架构，当前服务器主流。
  • ARM架构：精简指令集（RISC）架构，如华为鲲鹏920处理器。
  • 国产架构：龙芯等国产处理器，采用不同于x86的指令集。
• 兼容性注意：不同架构的指令集不兼容，如x86与ARM架构程序不能直接互通。

（2）核心与线程配置

• 物理配置示例：
  • 插槽（socket）：1个物理插槽。
  • 核心（core）：每个插槽6个物理核心。
  • 线程（thread）：每个核心2个逻辑线程。
  • 总计：12个逻辑处理器（vCPU）。
• 虚拟化配置：
  • 4个逻辑处理器（0-3编号）。
  • 1个插槽，每个插槽4个核心。
  • 单线程配置。

（3）缓存层级结构

• 缓存级别：
  • L1缓存：最小最快，示例中物理机为384KB。
  • L2缓存：中等，示例中物理机为1.5MB。
  • L3缓存：最大最慢，示例中物理机为12MB。
• 虚拟化差异：虚拟机中显示的缓存容量可能与物理机实际配置不同，这是虚拟化层的抽象结果。
• 性能影响：多级缓存设计显著影响CPU性能，缓存越大通常性能越好。

2. 缓存层次与类型

• 层级划分：现代CPU通常具有三级缓存结构（L1/L2/L3），可通过命令get -a查看具体配置。
• 私有性差异：
  • L1/L2缓存为核私有：每个物理核独占独立的L1/L2缓存。
  • L3缓存为共享缓存：所有物理核共享同一块L3缓存空间。
• 数据访问流程：CPU处理数据时遵循层级访问原则：
  1. 优先查找L1缓存（命中则直接处理）。
  2. L1未命中时查询L2缓存。
  3. L2未命中时查询L3缓存。
  4. 三级缓存均未命中时从内存读取数据。
• 缓存细分结构：
  • L1缓存采用分立设计：
    • 指令缓存：存储处理器指令。
    • 数据缓存：存储运算数据。
  • L2/L3缓存仅包含数据缓存区。
• 容量特性：
  • L1缓存通常较小（如Intel处理器为32KB）。
  • AMD处理器可能配置更大L1缓存。
  • 缓存容量与功耗呈正相关关系。

3. 插槽、核与线程的关系

• 物理插槽本质：主板上的CPU安装位，决定可安装的物理处理器数量。
• 核的演进：
  • 早期通过提升主频（如266MHz→533MHz）增强性能。
  • 现代采用多核设计：单个物理处理器集成多个运算核心。
• 性能对比原则：
  • 8物理处理器（各1核）优于1物理处理器（8核）：
    • 前者各核享有独立三级缓存。
    • 后者所有核共享三级缓存。
• 线程本质：
  • 非实体运算单元，通过超线程技术模拟的逻辑处理器。
  • 主要价值在于提高CPU资源利用率。
• 缓存容量计算：
  • 示例：6核CPU的L1缓存总量为（含指令/数据缓存各32KB per core）。

4. 超线程与CPU性能

（1）线程与缓存结构

• 线程本质：一个处理器瞬间只能处理一个任务，超线程是通过任务简单化实现的并发能力，并非物理性能提升。典型处理器最多支持双线程（如Intel）。
• 缓存计算：
  • L1缓存：私有，（指令区32K+数据区32K）。
  • L2缓存：私有。
  • L3缓存：共享，12M（不乘以核数）。
• 虚拟化分配：给虚拟机分配CPU时实际分配的是线程数，例如“2个CPU”指2个线程。

（2）物理核与逻辑核

• 物理核优势：8个物理处理器（每个1核）比1个物理处理器（8核）性能更优，因物理核是真实硬件资源。
• 任务调度机制：
  • 复杂任务会在不同CPU间轮询处理（通过ps axo %cpu,mem,pid,comm,psr可查看进程所在处理器）。
  • 超线程vCPU共享所有缓存（L1/L2私有是对核而言，线程间仍共享）。

（3）指令集架构差异

• 鲲鹏处理器特性：
  • 型号示例：6426表示64核2.6GHz。
  • 基于ARM架构（精简指令集），不支持超线程但核数多（如64核）。
  • 与x86对比：精简指令集在相同制程下可集成更多晶体管。
• 生态制约：
  • x86主导因Wintel联盟建立的完整软硬件生态。
  • ARM面临驱动/软件适配难题（如打印机驱动、专业软件缺失）。

5. CPU虚拟化支持

• 虚拟化技术基础：
  • VT-x标志：Virtualization: VT-x表示支持全虚拟化，是企业级虚拟化的必备条件。
  • NUMA架构：非统一内存访问架构，影响多处理器系统的内存分配策略。
• 大核小核设计：
  • 笔记本CPU可能存在大小核混合（如4大核+2小核）。
  • 服务器CPU通常核间参数一致，二级缓存大小可能不同。

二、NUMA架构

1. NUMA架构介绍

• 全称：Non-Uniform Memory Access（非一致性内存访问）。
• 核心特征：系统包含8个NUMA节点，每个节点包含特定编号的CPU核心（如node0包含0,10,14,18,22,30,38,46号核心）。
• 硬件组成：
  • 采用x86_64架构，支持32/64位操作模式。
  • 包含8个物理插槽（Socket），每个插槽8个核心。
  • 三级缓存配置：L1d/L1i各32KB，L2缓存256KB，L3缓存24MB。
  • 支持VT-X虚拟化技术，基础频率1064MHz。

2. 一致性内存访问与非一致性内存访问

（1）概念对比

• NUMA特点：
  • 内存访问时间取决于内存位置与处理器的相对关系。
  • 典型配置：8个NUMA节点通过QPI（Intel）/HyperTransport（AMD）互联。
  • 优势：支持大规模并行计算，扩展性强。
• UMA特点：
  • 传统架构采用统一内存访问模式。
  • 所有处理器访问内存的时间相同。
  • 通过共享总线连接内存和处理器。

（2）技术细节

• 缓存结构：
  • 单个线程：L1指令区32K + L1数据区32K = 64K。
  • 6核配置：L2缓存256K×6=1.5MB，L3缓存12MB共享。
• ARM架构对比：
  • 鲲鹏920采用64核2.6GHz设计。
  • 精简指令集架构，不支持超线程。
  • 典型NUMA节点配置与x86体系类似。

3. 前端总线与瓶颈问题

• FSB定义：前端总线（Front Side Bus）是CPU与内存、IO设备交换数据的通道，全称为FSB。
• 瓶颈现象：当多CPU和多内存同时工作时，所有数据都需通过单一FSB传输，形成“千军万马过独木桥”的拥堵局面。
• 架构局限：传统南北桥架构中，北桥管理高速设备（CPU/内存），南桥管理低速设备（磁盘/网卡），但FSB成为整体性能瓶颈。

4. NUMA架构的实现

（1）基本概念

• 设计理念：将CPU、内存和IO设备组成独立节点（NUMA node），类比城市交通的“井字路”设计，避免单点拥堵。
• 资源分配：每个node包含1个物理CPU和8条内存（示例中64条内存分布在8个node），虚拟机应尽量部署在同一node内。
• 硬件要求：NUMA支持由硬件决定，PC机通常不支持，需特定服务器硬件配置。

（2）运行机制

• 本地优先原则：程序优先使用本node内的CPU和内存资源，不足时才跨node访问。
• 全互联架构：各node间通过QPI（快速通道互联）直连，访问路径等距（AMD平台使用HyperTransport技术）。
• 距离参数：通过numactl命令可查看node间“距离”，反映访问延迟差异。

（3）实际应用

• 资源绑定：可指定程序在特定node运行（考试重点），通过内核参数可模拟多node环境（非真实硬件支持）。
• 典型配置：示例系统含8个物理CPU，每个node分配8个逻辑CPU和1/8总内存（1TB/8=128GB per node）。
• 内存识别：解释内存插槽与CPU的node归属关系，说明为何有时更换插槽可使内存被识别。

（4）管理工具

• numactl使用：需额外安装的软件包，可查看各node剩余内存和拓扑结构。
• 监控要点：重点关注本地（node-local）与远程（remote）内存访问比例，过高远程访问会降低性能。

5. NUMA节点间的距离与互联架构

• 距离参考值：NUMA架构中节点间的距离是相对参考值，不是实际物理距离。例如node 0到node 0的距离为10，node 0到node 1的距离为20。
• 全互联特性：所有NUMA节点之间都是互联的，形成全互联架构。如node 0可以访问node 1、node 2等所有节点的内存。
• 距离矩阵解读：通过numactl --hardware命令输出的距离矩阵中，x坐标和y坐标对应的数字就是两个节点间的距离值。
• 节点内存查看：使用numactl --hardware可查看每个NUMA节点的内存情况，包括：
  • 节点包含的CPU核心（如node 0 cpus: 0 1）。
  • 节点内存总量（如node 0 size: 503 MB）。
  • 节点剩余内存（如node 0 free: 308 MB）。

6. NUMA架构的应用场景

• 虚拟化适配：在华为Fusion Compute虚拟化平台中，开启“NUMA结构自动调整”功能可使虚拟机CPU和内存尽可能运行在同一个NUMA节点内。
• 进程绑定：可以指定应用程序运行在特定NUMA节点上，例如：
  • 数据库程序可设置为运行在所有处理器上。
  • 特定程序可限定在CPU 0和内存0-1上运行。
  • 支持设置“倾向性”运行策略。
• 硬件设计原理：每个CPU处理器管辖特定内存插槽区域，构成一个NUMA节点。节点内存大小取决于：
  • 该节点管辖的内存插槽数量。
  • 每个插槽安装的内存条容量。
• 缓存层级：需要注意一级缓存、二级缓存是CPU核心私有还是节点共享，这会影响程序性能优化策略。

7. CPU缓存的共享与私有

• 核心与线程关系：
  • 每个物理CPU对应一个插槽，示例中显示两个插槽（槽0和1）。
  • 每个核心对应一个CPU，若一个核心对应两个CPU则表示支持超线程（两个线程）。
  • 示例中node显示为00表示所有CPU位于同一个NUMA节点。
• 缓存层级特性：
  • 一级缓存（L1 Cache）：
    • 分为指令区和数据区。
    • 编号显示为0/1/2/3，表示每个CPU核心私有。
  • 二级缓存（L2 Cache）：
    • 同样显示私有特性（编号0/1/2/3）。
  • 三级缓存（L3 Cache）：
    • 显示为共享缓存（编号000）。
    • 若显示0011可能表示存在两个物理插槽。
• 判断方法：
  • 通过编号模式识别共享/私有：
    • 连续编号（如0/1/2/3）→私有。
    • 重复编号（如000）→共享。
  • 插槽数量推断：
    • 三级缓存编号出现01变化可能对应多个物理插槽。

8. dmidecode命令查看硬件信息

• 命令功能：
  • 可获取主板型号、序列号、CPU型号等完整硬件信息。
  • 特别适用于物理服务器硬件审计。
• 关键信息查询：
  • 物理CPU插槽数量：通过“Socket Designation”字段查看。
  • 缓存信息：通过“Cache Configuration”字段查看。
  • 内存配置：显示物理内存阵列的最大容量和纠错类型。
• 考试应用场景：
  • 典型考题：分析导出的硬件信息文件。
  • 解题技巧：
    • 搜索“L1”/“L2”等关键词定位缓存信息。
    • 注意16进制编码（如示例中的0094/0114）。
    • 结合物理服务器实际配置验证数据准确性。
• 注意事项：
  • 虚拟机环境可能显示不准确的硬件信息。
  • 实际物理服务器查询时需注意网络连通性。
  • 重要字段可能包含：“Product Name”、“Serial Number”、“Asset Tag”等。

9. SOS report功能介绍

• 功能概述：SOS report是Linux系统中用于收集系统诊断信息的工具，能够生成包含系统配置、日志等详细数据的压缩包。
• 使用场景：
  • 当需要技术支持时（如红帽官方支持），提供完整的系统信息。
  • 系统出现问题时快速收集诊断数据。
• 生成过程：
  • 执行命令后会提示“系统将生成各种数据”。
  • 按回车键继续或Ctrl+C退出。
  • 自动收集计算机所有信息并打包。
• 输出文件：
  • 生成压缩文件（默认存放在/tmp目录）。
  • 同时提供MD5校验值文件。
  • 通过比对MD5值验证文件完整性。
• 包含内容：
  • 系统安装的所有软件包列表。
  • 进程树信息（pstree）。
  • 内存使用情况。
  • 收集时的系统日期。
  • 磁盘分区信息。
  • 系统负载。
  • 内核版本。
  • 用户组信息。
  • 加载的内核模块。
  • 网络监听信息。
  • 主机名和IP地址。
  • 系统日志（/var/log下所有日志）。

10. 硬件监控

（1）CPU监控

• 监控方法：
  • 使用lscpu -p命令获取可解析格式的CPU信息。
  • 输出包含CPU、核心、插槽、节点、缓存等唯一ID。
• 缓存层级：
  • L1缓存分为指令缓存（L1i）和数据缓存（L1d）。
  • L2缓存为每个核心私有。
  • L3缓存由所有核心共享。
• 物理机识别：
  • 通过lscpu查看虚拟化类型。
  • 若显示VT-x等而非KVM/Xen则为物理机。

（2）内存监控

• 信息获取：
  • 使用dmidecode命令查看详细内存信息。
  • 可获取内存插槽数量及使用情况。
• 关键指标：
  • 内存大小（如8GB、16GB）。
  • 内存类型（如DDR3）。
  • 插槽位置（如A1、A2）。
  • 带宽（如72位）。
  • 速率和电压。

（3）四大核心子系统

• 磁盘子系统：
  • 类型：SATA/SAS/SSD/NVMe。
  • 数量及RAID级别（RAID0/1/5/6/10）。
  • 实际业务中通常系统盘做RAID1，数据放在存储。
• 网络子系统：
  • 网卡类型及带宽（1G/10G/100G）。
  • 交换机带宽。
  • 绑定模式（mode0/1/4/6）。
• 内存子系统：
  • 插槽类型及数量。
  • 内存带宽和电压。
• CPU子系统：
  • 核心数/线程数。
  • 缓存大小。
  • NUMA架构。

11. Linux内核模块管理

（1）模块基础

• 模块功能：
  • 驱动程序（如网卡驱动）。
  • 文件系统支持（如ext4/xfs）。
  • 安全功能（如SELinux）。
• 查看模块：
  • lsmod命令显示：
    • 模块名称。
    • 模块大小。
    • 使用次数。
    • 描述信息。
• 动态加载机制：
  • 按需自动加载（如挂载文件系统时加载对应模块）。
  • 闲置后自动卸载（约10分钟无使用）。

（2）模块操作

• 手动操作：
  • 加载模块：modprobe <模块名>。
  • 卸载模块：modprobe -r <模块名>。
  • 查看信息：modinfo <模块名>。
• 驱动安装：
  • 下载驱动源码包。
  • 解压并进入src目录。
  • 执行make install。
  • 驱动安装到/lib/modules目录。
• 依赖关系：
  • 需要安装kernel-devel等开发包。
  • 驱动必须匹配当前内核版本。

（3）模块调优

• 参数查看：
  • 通过modinfo查看模块可调参数。
  • 在/sys/bus/scsi/drivers目录查看当前值。
• 调优方法：
  • 在/etc/modprobe.d/目录创建.conf文件。
  • 格式：options <模块名> <参数名>=<值>。
  • 执行modprobe -r和modprobe重新加载。
• 持久化：
  • 配置文件方式可保证重启后生效。
  • 优于直接修改/sys下的临时值。

（4）历史演变

• 红帽5及之前：
  • 使用/etc/modprobe.conf文件。
  • 通过alias定义设备别名（如eth0）。
  • 直接在该文件中设置模块参数。
• 红帽6及之后：
  • 改用/etc/modprobe.d/目录。
  • 通过udev规则命名网络设备。
  • 每个模块有独立配置文件。

三、结束

1. 模块加载与卸载

（1）模块动态加载特性

• 动态加载机制：模块采用动态加载方式，系统会根据设备存在情况自动决定是否加载对应模块。
• 参数读取时机：当模块加载时，系统会自动读取该模块的参数配置。
• 开机生效保证：无需担心开机是否生效，只要检测到对应设备就会自动加载相关模块。

2. 模块加载的时机与参数读取

• 加载条件判断：
  • 有对应设备时才会加载模块。
  • 有相关资源时才会加载模块。
  • 无设备或资源时不会加载。
• 参数读取过程：模块加载时会自动读取其参数配置。
• 考试特殊说明：考试中可能出现“启动时不加载”的特殊情况，但实际工作中不会出现。

3. 开机自动加载模块的方法

（1）自动加载实现方式

• 配置文件位置：在/etc/systemd/system/目录下创建脚本。
• 执行机制：系统启动时会自动执行该目录下的脚本。
• 实际应用说明：此方法主要用于考试场景，实际工作中通常不需要。

（2）配置文件扫描机制

• 扫描触发：每次模块加载时都会扫描配置文件。
• 扫描内容：检查是否有与该模块相关的调优参数。
• 默认处理：若无相关配置则采用默认参数。

4. 模块加载脚本的编写与放置位置

• 脚本命名要求：必须以.modules结尾。
• 路径规范：必须使用绝对路径指定模块路径。
• 放置位置重要性：必须放在特定位置以确保在系统启动时优先加载。
• 加载顺序原理：系统启动时先加载模块再读取参数，许多功能需要模块加载后才能生效。

5. 模块加载脚本的生效验证

（1）验证方法

• 文件扩展名要求：必须使用.modules扩展名，.sh扩展名无效。
• 测试技巧：可通过创建测试文件（如ABC）验证加载效果。
• 扫描机制：系统会扫描所有以.modules结尾的脚本文件。

（2）常见问题解决

• 不生效排查：检查脚本扩展名是否正确。
• 强制加载方法：使用绝对路径确保准确加载。

6. 模块管理总结

（1）模块加载核心要点

• 动态特性：模块是动态加载的，按需加载。
• 参数关联：加载时自动读取相关参数。
• 持久化配置：通过特定目录下的.modules文件实现开机加载。

（2）实际应用案例

• 驱动缺失问题：系统启动失败可能由于关键驱动（如RAID卡驱动）缺失导致。
• 特殊驱动影响：某些驱动（如RAID卡驱动）缺失会导致系统无法启动，而网卡等驱动缺失仅影响对应功能。
• 解决方案原理：将所需驱动打包到initramfs文件中，系统启动时加载。

（3）initramfs文件处理

• 文件作用：包含系统启动所需的核心驱动。
• 修改方法：
  • 解压initramfs文件。
  • 添加所需驱动模块。
  • 重新打包生成新的initramfs文件。
• 版本一致性：必须确保修改的initramfs文件与系统内核版本匹配。

（4）驱动封装流程

• 封装命令：使用mkinitrd命令将驱动封装到initramfs中。
• 强制覆盖选项：添加-f参数强制覆盖现有文件。
• 跨机处理方案：当系统无法启动时，可在其他正常系统上完成驱动封装后再拷贝回故障系统。

（5）云迁移（P2V）问题处理

• 问题根源：物理机和虚拟机的硬件驱动不同导致迁移后无法启动。
• 解决方案：
  • 删除原有initramfs文件（操作前务必备份）。
  • 重新生成initramfs文件，系统会根据当前硬件自动生成正确驱动。
  • 或从相同内核版本的其他云主机拷贝initramfs文件。
• 应急处理：在救援模式下挂载系统盘到其他主机进行处理。