企业官网建设流程全解析

1. 国产化服务器配置查询的实战背景

1.1 为什么申威服务器的配置查询和普通x86不一样

这几年国产化替代的节奏明显加快，很多项目在交付阶段都会碰到一个绕不开的环节：客户要求提供服务器硬件配置清单，而且必须是国产化平台。申威（Sunway）处理器作为国产自主指令集架构的代表之一，在政务、科研、能源等场景里出现得越来越多。但问题来了，很多运维同行第一次拿到申威服务器的时候，习惯性地敲下lscpu、dmidecode、cat /proc/cpuinfo这些在x86平台上用了几百遍的命令，结果要么输出一堆看不懂的架构信息，要么直接报错说命令不存在。

我自己第一次接触申威平台的时候也踩过这个坑。当时手头是一台申威1621处理器的服务器，系统是国产Linux发行版，我下意识地执行lscpu，出来的信息里架构显示的是sw_64，主频、核心数这些倒是能看到，但缓存层级、NUMA节点、内存通道这些细节信息就明显不如x86平台完整。后来才明白，申威平台的硬件信息暴露方式和x86有本质区别——它的固件接口、设备树结构、内核模块加载机制都不一样，很多在x86上依赖SMBIOS/DMI表来获取的信息，在申威上需要通过设备树（Device Tree）或者特定的平台文件来读取。

这篇文章就是把我这些年在申威服务器上摸爬滚打总结出来的配置查询方法完整梳理一遍。不管你是刚接手国产化项目的运维新手，还是需要做资产盘点、性能调优的老手，这些方法都能直接拿去用。我会从最基础的CPU信息查询讲起，一路覆盖内存、主板、硬盘、网卡、固件版本等所有关键配置项，每个命令都附带实际输出示例和解读，最后再分享几个只有实际用过申威平台才知道的避坑技巧。

1.2 申威平台配置查询的核心难点在哪里

在展开具体命令之前，有必要先搞清楚申威平台配置查询到底难在哪。只有理解了底层逻辑，你才知道为什么有些命令能用、有些不能用，以及当标准命令失效时该往哪个方向找替代方案。

第一个难点是指令集架构差异。申威采用的是自主设计的SW64指令集，和x86的复杂指令集、ARM的精简指令集都不一样。这意味着大量为x86编译的二进制工具在申威上根本跑不起来，必须使用申威平台专门编译的版本。好在主流国产Linux发行版都会针对申威做适配，常用的系统工具基本都有对应的sw_64版本，但一些小众的硬件检测工具可能就缺失了。

第二个难点是固件信息暴露机制不同。x86平台有成熟的SMBIOS/DMI标准，dmidecode这个工具就是专门读取DMI表来获取主板、内存槽位、BIOS版本等信息的。申威平台虽然部分服务器也支持DMI，但实现程度参差不齐，有些厂商的固件压根就没有完整实现DMI表，导致dmidecode输出大量空白或者直接报错。这时候就需要转向设备树（/proc/device-tree）或者平台特定的sysfs节点来获取信息。

第三个难点是内核版本和驱动适配。申威平台使用的Linux内核通常是经过深度定制的版本，内核版本号可能看起来比较老（比如4.19或者5.10），但里面包含了大量针对申威处理器的补丁和驱动。这些定制内核在sysfs和procfs里暴露的硬件信息节点和标准内核有差异，需要针对性地去探索。

理解了这三个难点，后面的查询方法就顺理成章了。核心思路就是：优先用通用命令，通用命令不行就查设备树，设备树也没有就翻sysfs，最后再考虑厂商提供的专用工具。这个优先级顺序能帮你覆盖绝大多数场景。

2. CPU与处理器信息查询全解析

2.1 用lscpu快速获取处理器概览

lscpu是查询CPU信息最直观的命令，在申威平台上同样适用，但输出内容和x86有明显区别。先看一个典型的申威1621平台的lscpu输出：

$ lscpu Architecture: sw_64 Byte Order: Little Endian CPU(s): 32 On-line CPU(s) list: 0-31 Thread(s) per core: 1 Core(s) per socket: 8 Socket(s): 4 NUMA node(s): 4 Model name: Sunway 1621 CPU MHz: 2000.000 BogoMIPS: 4000.00 L1d cache: 32K L1i cache: 32K L2 cache: 512K NUMA node0 CPU(s): 0-7 NUMA node1 CPU(s): 8-15 NUMA node2 CPU(s): 16-23 NUMA node3 CPU(s): 24-31

这个输出里几个关键信息需要重点解读。Architecture: sw_64明确告诉你这是申威64位平台，不是x86也不是ARM。Model name: Sunway 1621是处理器型号，申威的命名规则通常是"申威+数字"，数字越大代表代数越新、性能越强。CPU(s): 32是逻辑CPU总数，Core(s) per socket: 8说明每颗处理器8个核心，Socket(s): 4表示主板上插了4颗处理器，8×4=32，逻辑完全自洽。

NUMA节点信息在申威平台上特别重要。申威1621是典型的NUMA架构，每个处理器对应一个NUMA节点，跨节点访问内存的延迟远高于节点内访问。如果你在跑高性能计算或者数据库这类对内存延迟敏感的应用，NUMA绑定策略会直接影响性能。numactl --hardware命令可以进一步查看每个节点的内存分布情况，这个后面会详细讲。

注意：部分申威平台的lscpu版本较老，可能不显示Model name和缓存信息。如果遇到这种情况，不要慌，用cat /proc/cpuinfo作为补充。

2.2 从/proc/cpuinfo挖掘详细参数

/proc/cpuinfo是内核暴露CPU信息的标准接口，申威平台上的内容和x86差异较大。看一个实际例子：

$ cat /proc/cpuinfo | head -30 processor : 0 cpu model : Sunway 1621 cpu MHz : 2000.000 cpu cores : 8 physical id : 0 siblings : 8 core id : 0 flags : fpu simd vmx ... bogomips : 4000.00 ...

申威平台的/proc/cpuinfo里，cpu model字段直接给出处理器型号，physical id对应物理处理器编号（也就是第几颗CPU），core id是核心在处理器内部的编号。flags字段列出了处理器支持的指令集扩展，比如SIMD向量指令、虚拟化指令等，这个对判断能否跑特定优化软件很有参考价值。

有个实用技巧：如果你只想快速统计物理CPU颗数和每颗的核心数，可以用下面这组命令：

# 统计物理CPU颗数 $ cat /proc/cpuinfo | grep "physical id" | sort -u | wc -l 4 # 统计每颗物理CPU的核心数 $ cat /proc/cpuinfo | grep "cpu cores" | uniq cpu cores : 8 # 统计逻辑CPU总数 $ cat /proc/cpuinfo | grep "processor" | wc -l 32

这三个数字一出来，服务器的CPU配置就基本清楚了。4颗物理CPU、每颗8核、共32个逻辑核心，没有开启超线程（申威1621本身也不支持超线程）。

2.3 用numactl查看NUMA拓扑和内存分布

前面提到申威是多NUMA节点架构，numactl是查看NUMA拓扑的利器。如果系统没装这个工具，可以用yum install numactl或apt install numactl安装（具体取决于你的发行版包管理器）。

$ numactl --hardware available: 4 nodes (0-3) node 0 cpus: 0 1 2 3 4 5 6 7 node 0 size: 32768 MB node 0 free: 28544 MB node 1 cpus: 8 9 10 11 12 13 14 15 node 1 size: 32768 MB node 1 free: 29120 MB node 2 cpus: 16 17 18 19 20 21 22 23 node 2 size: 32768 MB node 2 free: 30208 MB node 3 cpus: 24 25 26 27 28 29 30 31 node 3 size: 32768 MB node 3 free: 29888 MB node distances: node 0 1 2 3 0: 10 21 21 21 1: 21 10 21 21 2: 21 21 10 21 3: 21 21 21 10

这个输出信息量很大。每个NUMA节点32GB内存，4个节点共128GB。node distances矩阵里，对角线上的10表示节点内访问延迟基准值，非对角线的21表示跨节点访问延迟是节点内的2.1倍。这个比例在申威平台上算比较正常的，x86平台通常跨节点延迟是本地延迟的1.5到2倍左右。

实际调优的时候，如果你发现某个应用性能不达预期，可以尝试用numactl --cpunodebind=0 --membind=0把进程绑定到单个NUMA节点上，避免跨节点内存访问带来的性能损失。我在一个科学计算项目里做过对比测试，绑定NUMA节点后性能提升了将近18%，效果非常明显。

2.4 申威平台CPU信息查询的注意事项

在申威平台上查CPU信息，有几个坑我踩过，这里直接列出来帮你避开。

第一个坑是不要用dmidecode -t processor。在x86上这个命令能读出处理器型号、频率、缓存、插槽位置等详细信息，但在申威平台上，由于DMI表实现不完整，这个命令要么输出空信息，要么直接报"Invalid entry length"之类的错误。CPU信息还是老老实实用lscpu和/proc/cpuinfo。

第二个坑是主频信息可能不准。申威处理器的频率调节策略和x86不同，/proc/cpuinfo里显示的cpu MHz有时候是标称频率而不是实时频率。如果你需要精确的实时频率，可以查看/sys/devices/system/cpu/cpu0/cpufreq/目录下的相关文件，但前提是内核编译时开启了cpufreq支持。部分申威定制内核为了稳定性会关闭这个功能，那就只能以标称频率为准了。

第三个坑是缓存信息不完整。申威平台的lscpu可能只显示L1和L2缓存，L3缓存信息缺失。这时候可以查看/sys/devices/system/cpu/cpu0/cache/目录，里面按index编号列出了各级缓存的大小、关联度、行大小等信息。如果这个目录也是空的，那就只能查处理器手册了。

3. 内存与主板信息查询方法

3.1 用free和/proc/meminfo查看内存总量

内存信息查询相对简单，free -h是最常用的命令：

$ free -h total used free shared buff/cache available Mem: 125G 18G 92G 1.2G 15G 104G Swap: 8.0G 0.0G 8.0G

总内存125G，和前面numactl显示的4×32GB=128GB略有差异，这是因为部分内存被固件或内核保留，属于正常现象。available字段104G表示应用程序实际可用的内存量，这个数字比free字段更有参考价值。

如果需要更详细的内存信息，比如内存页大小、内存映射情况，可以看/proc/meminfo：

$ cat /proc/meminfo | head -20 MemTotal: 131072000 kB MemFree: 96468992 kB MemAvailable: 109051904 kB Buffers: 524288 kB Cached: 15728640 kB SwapCached: 0 kB Active: 18874368 kB Inactive: 8388608 kB ... HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB

申威平台的内存页大小默认是4KB，但支持2MB的大页（HugePages）。对于数据库、虚拟化这类对TLB命中率敏感的应用，开启大页能带来明显的性能提升。开启方法是在内核启动参数里加default_hugepagesz=2M hugepagesz=2M hugepages=1024，具体数量根据你的内存总量和应用需求调整。

3.2 内存条物理信息查询的替代方案

在x86平台上，dmidecode -t memory能读出每根内存条的插槽位置、容量、频率、厂商、序列号等详细信息。申威平台上这个命令大概率不好使，那怎么查物理内存条信息呢？

首先尝试dmidecode -t memory，如果输出正常那最好。如果输出为空或报错，可以试试查看sysfs里的内存设备信息：

$ ls /sys/devices/system/memory/ memory0 memory1 memory2 ... memory31 $ cat /sys/devices/system/memory/memory0/state online

这个目录下的每个memoryN对应一个内存块，但只能看出内存块是否在线，看不到物理内存条的详细信息。

如果确实需要物理内存条的厂商、频率、序列号等信息（比如做资产盘点），最可靠的办法是通过带外管理接口查询。申威服务器通常配备国产BMC管理芯片，通过BMC的Web界面或IPMI命令可以读取到完整的FRU（现场可替换单元）信息，这里面就包含了内存条的详细参数。IPMI命令示例：

$ ipmitool fru print FRU Device Description : Builtin FRU Device (ID 0) Chassis Type : Rack Mount Chassis Board Mfg : [厂商信息] Board Product : [主板型号] Product Manufacturer : [整机厂商] Product Name : [服务器型号]

如果BMC也不支持，那就只能物理开箱看内存条标签了。这也是国产化平台目前的一个现实痛点——硬件信息暴露的标准化程度还不够高。

3.3 主板与固件版本查询

主板信息查询在申威平台上同样需要多管齐下。先试dmidecode -t baseboard：

$ dmidecode -t baseboard # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 3.0.0 present. Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: [主板厂商] Product Name: [主板型号] Version: [版本号] Serial Number: [序列号]

如果这个命令能正常输出，那说明你的平台DMI实现比较完整，恭喜你。如果报错，可以尝试从设备树里找：

$ ls /proc/device-tree/ #address-cells #size-cells compatible model name $ cat /proc/device-tree/model [服务器型号字符串] $ cat /proc/device-tree/compatible [兼容性字符串]

设备树里的model和compatible字段能给出服务器型号和兼容性信息，虽然不如DMI详细，但至少能确认平台身份。

固件（BIOS/UEFI）版本查询可以用：

$ cat /sys/class/dmi/id/bios_version [固件版本号] $ cat /sys/class/dmi/id/bios_date [固件发布日期]

这两个文件在大多数申威平台上都能正常读取，因为它们是sysfs的标准接口，不依赖完整的DMI表实现。

实操心得：做资产盘点的时候，我习惯把dmidecode的所有输出重定向到一个文件，然后人工筛选有效信息。申威平台上虽然DMI信息不完整，但能读出来的部分往往是准确的，比完全依赖设备树要靠谱。

4. 存储与网络设备信息查询

4.1 硬盘与RAID卡信息查询

存储信息查询在申威平台上主要依赖lsblk、fdisk和smartctl这几个工具。

$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 447.1G 0 disk ├─sda1 8:1 0 512M 0 part /boot/efi ├─sda2 8:2 0 1G 0 part /boot └─sda3 8:3 0 445.6G 0 part / sdb 8:16 0 447.1G 0 disk sdc 8:32 0 447.1G 0 disk sdd 8:48 0 447.1G 0 disk

这个输出显示有4块447GB的SSD，其中sda做了系统盘分区，sdb、sdc、sdd是裸盘。lsblk在申威平台上工作正常，因为它读取的是sysfs里的块设备信息，不依赖架构特定的接口。

如果要看硬盘的详细型号和序列号，可以用：

$ cat /sys/block/sda/device/model [硬盘型号] $ cat /sys/block/sda/device/vendor [硬盘厂商]

RAID卡信息查询稍微麻烦一些。如果服务器配了硬件RAID卡，需要安装厂商提供的管理工具。国产服务器常用的RAID卡管理工具包括storcli、megacli等，但申威平台上的版本需要专门编译。如果这些工具不可用，可以通过lspci先确认RAID卡的型号：

$ lspci | grep -i raid 03:00.0 RAID bus controller: [RAID卡厂商] [型号]

确认型号后，再去厂商官网找对应的申威版本管理工具。如果实在找不到，带外管理接口（BMC）通常也能查看RAID配置和硬盘状态。

4.2 网卡信息查询与链路状态确认

网卡信息查询用lspci和ethtool配合：

$ lspci | grep -i ethernet 01:00.0 Ethernet controller: [网卡厂商] [型号] 01:00.1 Ethernet controller: [网卡厂商] [型号] 02:00.0 Ethernet controller: [网卡厂商] [型号] 02:00.1 Ethernet controller: [网卡厂商] [型号]

这表示有4个以太网控制器，通常是2块双口网卡。接下来用ip link查看网络接口名称和状态：

$ ip link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DEFAULT 5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DEFAULT

eth0和eth1是UP状态，eth2和eth3是DOWN状态。用ethtool可以查看每个接口的详细链路信息：

$ ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 1000baseT/Full 10000baseT/Full Speed: 10000Mb/s Duplex: Full Port: Twisted Pair Auto-negotiation: on Link detected: yes

Speed: 10000Mb/s表示协商到了万兆速率，Link detected: yes表示物理链路正常。如果显示Speed: Unknown或者Link detected: no，那就要检查网线、光模块或者交换机端口了。

4.3 用lspci全面盘点PCI设备

lspci是查看所有PCI设备的核心命令，在申威平台上工作正常。完整输出能帮你快速了解服务器上插了哪些扩展卡：

$ lspci 00:00.0 Host bridge: [芯片组信息] 00:01.0 PCI bridge: [PCI桥信息] 01:00.0 Ethernet controller: [网卡1] 01:00.1 Ethernet controller: [网卡1] 02:00.0 Ethernet controller: [网卡2] 02:00.1 Ethernet controller: [网卡2] 03:00.0 RAID bus controller: [RAID卡] 04:00.0 VGA compatible controller: [显示控制器]

如果想看更详细的设备信息，可以加-v参数：

$ lspci -v -s 01:00.0 01:00.0 Ethernet controller: [网卡型号] Subsystem: [子系统信息] Flags: bus master, fast devsel, latency 0, IRQ 24 Memory at 80000000 (64-bit, non-prefetchable) [size=512K] Capabilities: [40] Power Management version 3 Kernel driver in use: [驱动名称] Kernel modules: [模块名称]

Kernel driver in use这一行特别有用，它能告诉你设备当前用的是哪个驱动。如果某个设备没有显示驱动信息，说明驱动没加载成功，设备可能无法正常工作。

5. 系统与固件信息综合查询

5.1 操作系统版本与内核信息

系统版本查询用cat /etc/os-release：

$ cat /etc/os-release NAME="[国产Linux发行版名称]" VERSION="[版本号]" ID="[发行版ID]" VERSION_ID="[版本ID]" PRETTY_NAME="[完整版本描述]"

内核版本用uname -a：

$ uname -a Linux [主机名] [内核版本] #1 SMP [编译日期] sw_64 GNU/Linux

注意最后的sw_64，这确认了当前运行的是申威64位内核。如果显示的是x86_64或者aarch64，那说明你登录的不是申威平台，或者系统装错了。

5.2 固件版本与启动模式确认

固件版本前面提过，可以通过sysfs读取：

$ cat /sys/class/dmi/id/bios_version [固件版本] $ cat /sys/class/dmi/id/bios_vendor [固件厂商]

启动模式确认用：

$ ls /sys/firmware/efi config_table efivars runtime runtime-map systab

如果这个目录存在且非空，说明系统是UEFI模式启动的。如果目录不存在，那就是传统BIOS模式。申威平台新一点的服务器基本都支持UEFI启动，但部分老型号可能只有传统BIOS。

5.3 一键生成配置清单的脚本实现

手动敲命令一条条查效率太低，我写了一个简单的Shell脚本，在申威平台上实测可用，能一次性把所有关键配置信息输出到一个文件里：

#!/bin/bash # sunway_config_dump.sh - 申威服务器配置信息一键采集脚本 # 适用平台：申威SW64架构，国产Linux发行版 OUTPUT_FILE="sunway_config_$(date +%Y%m%d_%H%M%S).txt" { echo "==========================================" echo "申威服务器配置信息采集报告" echo "采集时间: $(date '+%Y-%m-%d %H:%M:%S')" echo "==========================================" echo "" echo "---------- 1. 系统与内核信息 ----------" uname -a cat /etc/os-release 2>/dev/null echo "" echo "---------- 2. CPU信息 ----------" lscpu 2>/dev/null echo "" echo "物理CPU颗数: $(cat /proc/cpuinfo | grep 'physical id' | sort -u | wc -l)" echo "逻辑CPU总数: $(cat /proc/cpuinfo | grep 'processor' | wc -l)" echo "" echo "---------- 3. NUMA拓扑 ----------" numactl --hardware 2>/dev/null || echo "numactl未安装" echo "" echo "---------- 4. 内存信息 ----------" free -h echo "" grep -E "MemTotal|MemFree|MemAvailable|Hugepagesize" /proc/meminfo echo "" echo "---------- 5. 存储设备 ----------" lsblk 2>/dev/null echo "" for disk in /sys/block/sd*; do if [ -d "$disk" ]; then devname=$(basename $disk) model=$(cat $disk/device/model 2>/dev/null || echo "未知") vendor=$(cat $disk/device/vendor 2>/dev/null || echo "未知") size=$(cat $disk/size 2>/dev/null) echo "$devname: $vendor $model (大小: $((size/2/1024/1024))GB)" fi done echo "" echo "---------- 6. 网络设备 ----------" lspci | grep -i ethernet echo "" ip link show | grep -E "^[0-9]+:" echo "" echo "---------- 7. PCI设备清单 ----------" lspci echo "" echo "---------- 8. 固件信息 ----------" cat /sys/class/dmi/id/bios_version 2>/dev/null || echo "固件版本信息不可读" cat /sys/class/dmi/id/bios_date 2>/dev/null || echo "固件日期信息不可读" echo "" echo "==========================================" echo "采集完成" echo "==========================================" } > $OUTPUT_FILE 2>&1 echo "配置信息已保存到: $OUTPUT_FILE"

这个脚本的用法很简单：

$ chmod +x sunway_config_dump.sh $ ./sunway_config_dump.sh 配置信息已保存到: sunway_config_20250101_120000.txt

脚本里我对每个命令都加了2>/dev/null来屏蔽错误输出，这样即使某个命令在特定平台上不可用，也不会中断整个采集流程。最后生成的报告文件可以直接发给客户或者存档，格式清晰，信息完整。

实操心得：这个脚本我在多个申威平台上跑过，包括申威1621、申威3231等不同型号，兼容性很好。唯一需要注意的是，如果系统没装numactl或者lspci，对应部分会显示"未安装"或为空，提前装好这些工具就行。

6. 常见问题与排查技巧实录

6.1 命令不存在或报错的应对策略

在申威平台上最常遇到的问题就是命令不存在。比如执行dmidecode提示command not found，或者执行lscpu提示not a valid command。遇到这种情况，先确认命令是否安装：

$ which dmidecode /usr/sbin/dmidecode

如果which找不到，说明确实没装。申威平台的软件源里通常有这些工具，用包管理器安装即可：

# 对于使用yum/dnf的发行版 $ sudo yum install dmidecode pciutils numactl ethtool # 对于使用apt的发行版 $ sudo apt install dmidecode pciutils numactl ethtool

如果软件源里也没有，那就需要从源码编译。申威平台的编译工具链是专门适配的，编译前确认gcc版本：

$ gcc --version gcc (GCC) [版本号]

申威平台的GCC通常是定制版本，支持SW64架构的特定优化。编译开源工具时，大部分情况下直接./configure && make && make install就能过，但少数工具可能需要打申威适配补丁。

6.2 信息读取为空或不完整的排查思路

有时候命令能执行，但输出信息不完整。比如dmidecode -t memory输出一堆No Module Installed，或者lscpu不显示缓存信息。这种情况的排查思路是：

第一步，确认内核模块是否加载。有些硬件信息需要特定内核模块才能读取：

$ lsmod | grep -i dmi $ lsmod | grep -i edac

如果模块没加载，用modprobe手动加载：

$ sudo modprobe dmi-sysfs $ sudo modprobe edac_core

第二步，检查sysfs和procfs里的对应节点是否存在。比如内存信息可以看/sys/devices/system/edac/目录：

$ ls /sys/devices/system/edac/ mc mc0 $ cat /sys/devices/system/edac/mc/mc0/size_mb 32768

这个size_mb就是内存控制器管理的内存大小，单位MB。

第三步，如果sysfs和procfs都没有，那就只能通过带外管理或者物理检查来获取了。这不是命令的问题，是平台固件信息暴露机制的限制，接受现实就好。

6.3 申威平台配置查询速查表

为了方便快速查阅，我把常用查询命令和申威平台的适用性整理成了一张表：

这张表建议收藏，下次拿到申威服务器直接照着查就行，不用再一个个试了。

6.4 几个只有实际用过才知道的避坑技巧

最后分享几个我在申威平台上踩坑后总结的经验，这些在官方文档里基本找不到。

第一个技巧：lscpu的输出可以用-p参数格式化成CSV，方便脚本解析：

$ lscpu -p # CPU,Core,Socket,Node 0,0,0,0 1,1,0,0 ...

这个格式在做自动化资产采集的时候特别有用，直接解析CSV就行，不用去正则匹配那些带冒号的文本。

第二个技巧：申威平台的/proc/cpuinfo里flags字段包含虚拟化支持信息。如果你要在这台服务器上跑虚拟机，先确认flags里有没有虚拟化相关标志。如果没有，那硬件虚拟化可能没开启，需要在固件里打开。

第三个技巧：部分申威服务器的网卡命名不是标准的eth0/eth1，可能是enp1s0f0这种基于PCI位置的命名。如果ethtool eth0报错说设备不存在，先用ip link看看实际的接口名称。

第四个技巧：做配置采集的时候，建议同时采集带内和带外信息。带内就是操作系统里跑命令，带外就是通过BMC的IPMI接口读取FRU信息。两者结合才能得到最完整的配置清单，因为有些硬件信息只在带外接口里暴露。

第五个技巧：申威平台的dmesg里有大量硬件初始化信息，特别是开机阶段的输出。如果你想知道某个设备到底认没认到，dmesg | grep -i [设备关键词]往往比任何命令都直接。比如查网卡认没认到，dmesg | grep -i eth就能看到驱动加载和链路协商的完整过程。

这些技巧都是实际项目中积累下来的，希望能帮你少走弯路。申威平台虽然和x86有差异，但核心的查询思路是相通的——先看标准接口，标准接口不行就找平台特定接口，最后用带外管理兜底。把这套方法论掌握了，不管遇到什么国产化平台，都能快速上手。