4.1 面板卡顿与网站慢的系统排查

4.1 面板卡顿与网站慢的系统排查

先给一个判断

“慢”先分两会：面板慢还是网站慢。 这两个的排查方向完全不同。先用 SSH 连一下服务器——如果 SSH 也卡，是服务器整体资源问题；如果 SSH 飞快只有面板卡，问题在面板服务或浏览器；如果面板飞快只有网站卡，问题在网站或 OpenResty。花 30 秒做这个分流，比闷头查两小时强。

现象：你的“慢”属于哪一种

现象	含义	大方向
SSH 也卡、命令回得慢	服务器整体资源问题	磁盘/内存/CPU
只有面板网页卡	面板服务问题	4.1 本节
只有某个网站慢	网站/后端应用问题	第 2 章 / 4.3
时段性卡（每晚固定慢）	定时任务在抢资源	看计划任务
重启就好、过阵子又卡	慢性资源泄漏	4.3 / 4.4

时段性卡特别值得注意：如果你的服务器每天凌晨固定变卡，先去看计划任务——备份任务、快照任务全都在那时跑，磁盘 IO 被吃满，什么都会慢。

定位：标准三板斧

# 1. 磁盘——先排除 90% 的坑（满了/IO 瓶颈）
df -h

# 2. 内存——available 还剩多少
free -h

# 3. 谁在吃资源——CPU 占用前 10
top -bn1 | head -20

top 的读法：%CPU 列从高到低排，前几名就是罪魁。看到不认识的进程占着 200% CPU，先别紧张，可能是挖矿木马，也可能只是你的某个应用——对照 docker ps 和进程名确认（入侵自查见 5.4 节）。

进一步看 IO 等待：

# IO 等待占比（wa 那一列，持续高就是磁盘瓶颈）
vmstat 2 5

# 磁盘实时吞吐，看哪个盘在疯狂读写（没装 sysstat 就先 yum/apt 装）
iostat -dx 2 5

iostat 的读法：重点看 %util（忙到什么程度，长期接近 100% 就是瓶颈）和 await（一次 IO 等了多少毫秒，机械盘几十算正常，几百就有问题）。服务器用的是机械盘还是云盘，await 的体感差距很大——如果await 经常破百，磁盘就是你的短板，治理方法见 4.2 节。

分流之后怎么查：服务器整体慢的四板斧

如果分流的结果是“SSH 也卡”，说明是服务器整体资源问题，按这个顺序敲一遍：

# 1. 磁盘空间和 inode（90% 以上先清，见 4.2 节）
df -h
df -i

# 2. 内存——只看 available
free -h

# 3. CPU 和进程——谁在烧
top -bn1 | head -20

# 4. 磁盘 IO——谁在狂写
vmstat 2 5
iostat -dx 2 5

四板斧的关系：磁盘空间满了会影响 IO，IO 慢了会让进程排队（负载升高），负载高了 CPU 看起来就忙。所以顺序永远是磁盘 → 内存 → CPU → IO，从最底层往上查。一上来就看 CPU，多半会被表象带偏。

修复：面板慢的几种情况

情况	处理
面板服务资源占用高	重启面板服务试试
浏览器缓存问题	换个浏览器/无痕模式试试
服务器负载本来就高	治理资源问题（4.2~4.4）
面板数据太多（监控、日志）	调短保留天数、清空旧记录

每种根因怎么验证

根因	验证方法	判断
浏览器缓存	换浏览器或无痕模式打开面板	无痕快 = 缓存问题
面板进程	`top` 里看面板进程占用	长期高占用 = 重启服务
磁盘 IO	`iostat -dx 2 5` 看 %util	接近 100% = 磁盘拖慢一切
数据库慢查询	看面板数据库慢日志（4.3 节）	满屏同一条 = 慢查询
监控数据太大	看监控保留天数和采集间隔	留太久 = 查监控就慢

验证顺序建议：先花 10 秒开个无痕窗口——这是成本最低的一步，但也最容易被嫌麻烦跳过。无痕模式排除浏览器问题之后，再上服务器跑命令，不浪费时间。

什么时候该重启面板服务

** 1pctl restart 是面板慢的第一道急救，但它治标不治本**。判断标准：

该重启：面板进程占用异常升高、面板刚升级完、面板功能偶发抽风——这些情况重启一下，八成就好；
别急着重启：服务器整体就卡、磁盘满了、内存红了——先治资源问题，重启面板只会让你短暂地“感觉好了”，过几分钟照样卡；
千万别重启：你正在跑备份或快照任务的时候——重启面板会打断它，等任务跑完再动。

# 重启面板服务（不影响网站和容器）
1pctl restart

# 看面板状态
1pctl status

一个常被忽略的点：监控数据保留太长、采集太密，面板查监控就会慢。在监控的【设置】里调整保留天数，必要时清空历史记录（清空不可恢复，先确认不需要）。同理，日志审计的各种日志也可以定期用计划任务清理（见 4.4 节）。

修复：网站慢的排查思路

网站慢的层次更多，从快到慢依次排除：

检查项	怎么测	判断
服务器到用户	不同网络环境访问	用户网络/CDN
OpenResty 响应	静态文件快不快	快 = 问题在后端
后端应用	看应用日志和资源	应用自身或数据库
数据库	慢查询日志（4.3 节）	慢查询/索引

一个黄金判断：访问一个纯静态文件（比如网站目录下的一张图片）。静态文件秒开但动态页面慢 = 问题在后端；静态文件也慢 = 问题在 Web 层或网络。

修复：定时任务时段性卡

排查方法：看监控曲线里负载升高的时间和计划任务列表的时间对不对得上。

处理建议：

错峰安排：备份、快照、清理任务别全堆在同一时间；
低峰留余量：给任务之间留半小时以上间隔；
大任务拆小：全量备份改成按类型分开备份。

一个 FAQ 短案例：面板突然卡，网站正常

现象：面板卡顿，网站访问飞快，SSH 也正常。

排查命令：

# 服务器没毛病，那就看面板进程自己
top -bn1 | grep -i 1panel

# 看磁盘 IO 有没有被面板相关操作占住
iostat -dx 2 5

根因：面板进程占用异常（常见于刚升级完、或在查一段很长的监控历史）。

修法：低峰期执行 1pctl restart，重启后面板恢复流畅。如果隔几天又卡，就不是重启能解决的了——去查监控保留天数和采集间隔，这是数据量在慢性增长，治法见本节前面「一个常被忽略的点」。

一个完整的复现与修复

现象：面板操作明显变卡，网站也不如以前快，SSH 偶尔也延迟。

排查过程：

df -h 磁盘用了 85%——有点高但还不至于致命；
free -h 内存 available 只剩 200M——嫌疑落内存上；
top -bn1 | head -20 发现 MySQL 容器长期占着 40% CPU；
进数据库设置看慢日志（4.3 节细说），日志里满是同一条统计查询。

修复：

给那条查询对应的表加上索引（慢查询定位的完整流程见 4.3 节）；
顺手用缓存清理清掉一波系统垃圾，磁盘降到 70%；
观察两天，面板和网站都恢复正常。

复盘要点：“慢”很少是单一原因。这个案例里磁盘、内存、数据库三个都有问题，但主线只有一条——监控曲线和 top 会告诉你时间线，跟着时间线找主线。

验证

# 改完后盯一会儿负载趋势
uptime

# 再看资源水位
free -h
df -h

同时打开面板监控曲线，观察一整天（尤其要看夜间定时任务跑的时候）。只在白天看是不够的——很多问题只在凌晨出现。

本节要点

先用 SSH 分流：服务器慢、面板慢、网站慢是三个问题；
df -h / free -h / top 三板斧，先磁盘后内存再 CPU；
静态文件秒开但动态页慢，问题在后端或数据库；
固定时段卡，去查计划任务的时间安排；
监控曲线的“时间线”比当前值更有价值。

主机监控的使用见 1Panel 官方文档：主机监控，以官方文档为准。

下一节：如果 df -h 里磁盘已经红了——别慌，4.2 节教你怎么找到罪魁祸首，安全地清出空间。