服务器使用过程中卡顿如何排查

我们都知道一台服务器优良的特性能够给用户很好的体验。但服务器并不是万能的，虽然服务器出现卡顿的现象比较少见，但也不排除出现的可能，而服务器一旦出现卡顿，造成的后果会严重的多。这里霍霍分享几个处理技巧，希望能有所帮助。
服务器卡顿的情况下，请先检查服务器的使用情况。
1、CPU使用率是否大于50%。
2、内存使用率是否过高。
3、网络使用率是否过高。
如果出现上述情况，请联系技术人员处理。如果没有出现上述情况则可能由以下原因造成：
1、服务器遭遇CC攻击导致，需要联系售后人员做CC防护策略。
2、服务器遭遇较大的流量攻击，但服务器没有被流量牵引。
3、设备网卡故障、网线故障、上层交换机故障。在出现故障前，您可以对您服务器的相邻ip进行测试，如果相邻ip 也同样出现丢包情况，说明是上层交换设备故障。
4、机房网络故障，这将是大范围的故障。
服务器卡的情况下，一般会出现的表现状况：
1、服务器严重丢包，正常的服务器丢包率为0%，若丢包率高于1%则会出现卡的情况。
2、部分用户卡，部分用户不卡，可能由于硬件防火墙造成，部分链路堵塞。
3、另外，上述情况也可能是互联网节点故障造成。
排查服务器的卡顿有利于保证业务稳定性和持续性。Linux中可以通过一些监控命令来实现。
在Linux服务器运维中，实时掌握系统资源的使用情况是保障服务稳定性的基石。无论是CPU过载、内存泄漏、磁盘I/O瓶颈，还是网络流量异常，都需要依赖一系列高效的命令行工具进行精准监控与分析。本文将系统梳理Linux生态中用于服务器指标监控的核心命令，涵盖资源查看、性能诊断、趋势预测及自动化监控场景，并结合实际案例演示如何快速定位问题与优化系统性能。
基础监控：快速获取系统状态
1. top与htop——全局资源总览
作为最经典的实时监控工具，top命令以动态刷新的方式展示系统的整体负载情况，包括：
CPU使用率：用户态（us）、系统态（sy）、空闲（id）、等待I/O（wa）等状态占比。
内存与Swap：物理内存总量、已用、缓存（cache）、交换分区使用情况。
进程列表：按CPU或内存占用排序的进程详情（PID、用户、资源消耗等）。
htop是top的增强版，支持彩色显示、鼠标操作、进程树视图及直接杀死进程的功能，交互性更强。例如，通过F6键可按磁盘I/O排序进程，快速定位高负载服务。
2. vmstat——虚拟内存与CPU统计
vmstat（Virtual Memory Statistics）以固定间隔输出系统资源快照，适合观察趋势变化：
$ vmstat 2 5 每2秒采样一次，共5次
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 5012344 102384 2103456 0 0 25 30 105 220 10 5 85 0 0
关键指标解析：
procs.r：等待CPU的进程数，持续大于CPU核心数表示CPU资源紧张。
memory.swpd：交换分区使用量，持续增长可能预示内存不足。
io.bi/bo：块设备每秒读写量（块数），反映磁盘I/O压力。
3. iostat——磁盘I/O与设备负载
iostat专注于存储设备监控，可展示每个磁盘的吞吐量、响应时间及利用率：
$ iostat x 1 每秒显示扩展信息
Device r/s w/s rkB/s wkB/s await %util
sda 5.2 3.1 120.4 45.2 2.1 8.3
%util：设备带宽使用率，接近100%表明磁盘成为瓶颈。
await：I/O操作平均等待时间（毫秒），过高可能因磁盘过载或硬件故障。
4. netstat与ss——网络连接与流量监控
netstat可查看当前网络连接、路由表及接口统计信息：
$ netstat tulnp 列出所有监听端口及对应进程
$ netstat s 显示网络协议统计（如TCP重传数）
ss（Socket Statistics）作为netstat的替代品，速度更快且信息更详细：
$ ss s 汇总所有socket状态
$ ss it '( dport = :80 )' 筛选目标端口为80的TCP连接
5. free与df——内存与磁盘空间检查
free显示内存总量及使用情况，推荐使用h参数以易读格式输出：
$ free h
total used free shared buff/cache available
Mem: 7.7G 2.1G 3.2G 256M 2.4G 5.0G
Swap: 2.0G 0B 2.0G
df（Disk Free）展示文件系统磁盘空间使用情况，结合h和T参数可显示文件系统类型：
$ df hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 ext4 50G 32G 16G 67% /
进阶工具：深度诊断与趋势分析
1. dstat——多功能资源监控器
dstat整合了vmstat、iostat、netstat等工具的功能，支持彩色输出与CSV导出：
$ dstat cmsdn topcpu 监控CPU、内存、磁盘、网络及高CPU进程
通过插件扩展，可监控MySQL查询、ZFS文件系统等特定服务。
2. sar——历史数据回溯与报告生成
sar（System Activity Reporter）属于sysstat工具包，可记录并分析历史性能数据：
$ sar u 1 3 每秒采样CPU使用率，共3次
$ sar r f /var/log/sa/sa15 查看15号的内存历史数据
需提前启用sysstat服务（systemctl enable sysstat），数据默认存储在/var/log/sa/。
3. nmon——交互式性能仪表盘
nmon以分屏模式展示CPU、内存、磁盘、网络等核心指标，支持快捷键切换视图：
$ nmon s2 c60 每2秒采样一次，共60次，生成交互式界面
结果可导出为CSV文件，便于后续分析。
4. iftop与nload——实时网络流量监控
iftop按主机对显示实时网络带宽使用情况：
$ iftop i eth0 监控eth0接口流量
nload则分通道展示进出流量曲线，直观识别流量峰值。
5. glances——跨平台综合监控工具
glances通过Web界面或终端提供一站式监控，支持API集成与告警功能：
$ glances webserver 启动Web服务（默认端口61208）
场景化监控策略与自动化实践
1. 实时告警与阈值触发
结合watch命令定期执行监控指令，并利用grep或awk过滤异常值：
$ watch n 5 "df h | grep '/data' | awk '{print $5}' | tr d '%'" 每5秒检查/data分区使用率
当使用率超过90%时，可通过邮件或Slack发送告警（需集成mail或curl命令）。
2. 性能瓶颈快速定位
CPU密集型场景：使用pidstat u 1定位高CPU进程，结合perf top分析热点函数。
内存泄漏排查：通过smem s swap查看进程Swap使用，或valgrind tool=memcheck检测内存错误。
磁盘I/O延迟：iotop按进程排序I/O消耗，iostat x 1观察%util与await指标。
3. 日志与监控数据持久化
使用cron定时任务收集关键指标并存储：
每日凌晨收集CPU、内存、磁盘数据
0 0 /usr/bin/sar u r d p 1 60 > /var/log/sa/daily_$(date +%F).log
4. 容器化环境监控
对于Docker或Kubernetes环境：
Docker：docker stats实时查看容器资源消耗，cAdvisor提供可视化监控。
Kubernetes：kubectl top pod/node获取资源用量，集成Prometheus+Grafana构建监控面板。
总结与最佳实践建议
Linux服务器监控的核心在于“分层观测”与“工具链组合”。日常运维中，建议：
基础巡检：使用htop、dstat快速掌握全局状态。
深度诊断：通过sar、nmon回溯历史数据，定位偶发性问题。
自动化：编写Shell脚本或使用Ansible集成监控任务，减少人工干预。
可视化：将数据导入Elasticsearch或Grafana，生成趋势图表与告警仪表盘。
无论是单机部署还是大规模集群，合理运用这些命令可将隐性的系统负载转化为显性的数据指标，为性能优化与容量规划提供坚实依据。掌握这些工具，意味着在服务器管理的复杂战场中，始终拥有“看得清、控得住”的核心能力。

审核编辑 黄宇