在 IT 运维工作里，服务器 CPU 飙高可是个让人头疼的问题。一旦 CPU 使用率过高，服务器的性能就会大打折扣，可能导致服务响应变慢、甚至直接崩溃，影响业务的正常运行。今天咱就来唠唠，在 IT 运维中碰到服务器 CPU 飙高的情况，有哪些快速定位的方法。
一、检查系统层面
1. 利用系统监控工具
在 Linux 系统中，top 命令是一个非常实用的系统监控工具。它可以实时显示系统中各个进程的资源使用情况，包括 CPU、内存等。比如，我们在终端输入 top 命令，就能看到类似下面这样的输出：
top - 14:56:44 up 12 days, 23:45, 2 users, load average: 1.05, 1.12, 1.08
Tasks: 152 total, 1 running, 151 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.2 us, 1.3 sy, 0.0 ni, 93.0 id, 0.0 wa, 0.0 hi, 0.5 si, 0.0 st
KiB Mem : 8055860 total, 1234560 free, 3456780 used, 3364520 buff/cache
KiB Swap: 2097152 total, 2000000 free, 97152 used. 4567890 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
123 root 20 0 1024m 256m 64m R 90.0 3.2 1:23.45 myapp
从这个输出中，我们可以看到，PID 为 123 的进程占用了 90% 的 CPU 资源，这个进程很可能就是导致 CPU 飙高的“罪魁祸首”。你可以根据这些信息进一步分析这个进程的行为，看看是不是有什么异常情况。
另外，htop 也是一个不错的选择，它是 top 的增强版，界面更加友好，操作也更方便。你可以通过 yum install htop（CentOS 系统）或者 apt-get install htop（Ubuntu 系统）来安装它。
2. 查看系统日志
系统日志可以记录很多重要的信息，比如系统启动、进程异常退出等。在 Linux 系统中，常见的日志文件位于 /var/log 目录下，像 messages、syslog 等。我们可以使用 grep 命令来查找与 CPU 相关的信息，例如：
grep "CPU" /var/log/messages
如果日志中出现了与 CPU 过热、资源不足等相关的信息，那就可能是硬件或者系统配置方面的问题了。
二、分析进程层面
1. 确定高 CPU 进程
通过上面提到的 top 命令，我们已经找到了占用高 CPU 的进程。接下来，我们要进一步分析这个进程。以 Java 进程为例，如果发现 Java 进程占用了大量的 CPU 资源，我们可以使用 jstack 命令来获取该进程的线程堆栈信息。
假设 Java 进程的 PID 是 123，我们可以在终端输入以下命令：
jstack 123 > jstack.log
这个命令会将 Java 进程的线程堆栈信息输出到 jstack.log 文件中。然后，我们可以打开这个文件，查看线程的状态和调用栈，找出那些处于 RUNNABLE 状态且长时间占用 CPU 的线程。
2. 分析进程代码
如果是自己开发的应用程序，我们可以结合代码来分析问题。比如，在一个 Java 应用中，有一个循环可能没有正确的退出条件，导致 CPU 一直处于高负载状态。下面是一个简单的示例代码：
// 这是一个存在问题的 Java 代码示例
public class EndlessLoopExample {
public static void main(String[] args) {
while (true) { // 这是一个无限循环，会一直占用 CPU
// 这里可以是一些计算密集型的操作
int result = 1 + 1;
}
}
}
在这个示例中，由于 while 循环没有正确的退出条件，程序会一直运行下去，不断地进行计算，从而导致 CPU 飙高。我们可以通过添加退出条件来解决这个问题，比如：
// 修正后的 Java 代码示例
public class FixedLoopExample {
public static void main(String[] args) {
int counter = 0;
while (counter < 100) { // 循环 100 次后退出
int result = 1 + 1;
counter++;
}
}
}
三、排查数据库层面
1. 数据库查询性能
如果服务器上运行着数据库，比如 MySQL 数据库，一些慢查询可能会导致 CPU 使用率升高。我们可以通过查看 MySQL 的慢查询日志来找出这些问题。首先，需要在 MySQL 配置文件（通常是 /etc/my.cnf 或者 /etc/mysql/mysql.conf.d/mysqld.cnf）中开启慢查询日志：
# 开启慢查询日志
slow_query_log = 1
# 慢查询日志文件路径
slow_query_log_file = /var/log/mysql/mysql-slow.log
# 定义慢查询的时间阈值，单位为秒
long_query_time = 2
然后重启 MySQL 服务，这样 MySQL 就会将执行时间超过 2 秒的查询记录到慢查询日志中。我们可以使用 explain 命令来分析这些慢查询的执行计划，例如：
-- 分析慢查询的执行计划
EXPLAIN SELECT * FROM users WHERE age > 30;
explain 命令会输出查询的执行计划，包括查询使用的索引、扫描的行数等信息。通过分析这些信息，我们可以优化查询语句，比如添加合适的索引，从而提高查询性能，降低 CPU 使用率。
2. 数据库连接池配置
数据库连接池配置不合理也可能导致 CPU 飙高。如果连接池中的连接数量过多，数据库服务器可能会不堪重负。我们需要根据服务器的硬件资源和实际业务需求来合理配置连接池的参数。以 Java 中的 HikariCP 连接池为例，下面是一个简单的配置示例：
import com.zaxxer.hikari.HikariConfig;
import com.zaxxer.hikari.HikariDataSource;
import javax.sql.DataSource;
public class DatabaseConnection {
public static DataSource getDataSource() {
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost:3306/mydb");
config.setUsername("root");
config.setPassword("password");
// 最大连接数
config.setMaximumPoolSize(20);
// 最小空闲连接数
config.setMinimumIdle(5);
return new HikariDataSource(config);
}
}
在这个示例中，我们将最大连接数设置为 20，最小空闲连接数设置为 5。这样可以避免连接池中的连接数量过多，减少对数据库服务器的压力。
四、检查网络层面
1. 网络流量监控
高网络流量可能会导致服务器 CPU 飙高。我们可以使用 iftop 命令来监控网络接口的实时流量。例如，在终端输入 iftop -i eth0 可以监控 eth0 网络接口的流量情况。
interface: eth0
IP address is: 192.168.1.100
MAC address is: 00:11:22:33:44:55
TX: cum: 3.25MB peak: 4.23Mbps rates: 2.34Mbps 2.12Mbps 2.01Mbps
RX: cum: 2.10MB peak: 3.12Mbps rates: 1.87Mbps 1.76Mbps 1.65Mbps
TOTAL: cum: 5.35MB peak: 7.35Mbps rates: 4.21Mbps 3.88Mbps 3.66Mbps
20.05Mb 40.10Mb 60.15Mb 80.20Mb 100.25Mb 120.30Mb 140.35Mb 160.40Mb 180.45Mb
└───────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────┴────────────
从输出中我们可以看到，当前网络接口的发送和接收流量情况。如果发现某个时间点的流量突然增大，可能是有异常的网络请求，比如遭遇了 DDoS 攻击，需要进一步排查。
2. 网络服务配置
某些网络服务的配置不合理也可能导致 CPU 问题。比如，Nginx 服务器的配置中，如果 worker_processes 参数设置过大，可能会导致 CPU 使用率过高。worker_processes 参数表示 Nginx 工作进程的数量，通常可以将其设置为服务器 CPU 核心数，如下所示：
# nginx.conf 配置示例
worker_processes auto; # 根据 CPU 核心数自动设置工作进程数量
events {
worker_connections 1024;
}
http {
# 其他配置项
}
这样可以确保 Nginx 以合适的进程数量运行，避免资源浪费。
五、应用场景
在企业级应用中，服务器 CPU 飙高的问题可能会出现在各种场景下。比如，在电商平台的促销活动期间，大量的用户同时访问网站，服务器的 CPU 使用率可能会急剧上升。另外，在大数据处理场景中，当进行大规模的数据计算和分析时，也容易出现 CPU 飙高的情况。
六、技术优缺点
优点
- 系统监控工具：使用系统自带的监控工具，如
top、htop等，不需要额外安装复杂的软件，操作简单，能够快速定位到高 CPU 进程。 - 查看系统日志：系统日志记录了很多有用的信息，可以帮助我们发现一些潜在的问题，如硬件故障、系统异常等。
- 分析进程代码：对于自己开发的应用程序，通过分析代码可以从根本上解决 CPU 飙高的问题，提高程序的性能和稳定性。
- 数据库排查：通过优化数据库查询和配置连接池，可以提高数据库的性能，减少对服务器 CPU 的压力。
- 网络监控：实时监控网络流量可以及时发现异常的网络请求，保障服务器的网络安全。
缺点
- 系统监控工具：只能提供一些基本的系统信息，对于复杂的应用程序问题可能无法深入分析。
- 查看系统日志：日志文件可能非常庞大，查找有用信息需要花费一定的时间和精力。
- 分析进程代码：需要对代码有深入的了解，对于大型项目来说，分析代码的工作量较大。
- 数据库排查：数据库优化需要一定的专业知识，操作不当可能会影响数据库的正常运行。
- 网络监控：只能发现网络流量的异常，无法直接确定问题的根源，可能需要结合其他工具和方法进一步排查。
七、注意事项
- 在使用
top、htop等监控工具时，要注意查看统计的时间范围，避免被短期的高 CPU 波动误导。 - 在修改数据库配置文件和应用程序代码之前，一定要先做好备份，以免出现问题导致数据丢失或服务不可用。
- 在进行网络流量监控时，要注意区分正常的业务流量和异常流量，避免误判。
八、文章总结
在 IT 运维中，服务器 CPU 飙高是一个常见但又比较棘手的问题。通过从系统层面、进程层面、数据库层面和网络层面进行全面的排查和分析，我们可以快速定位到问题的根源，并采取相应的措施进行解决。在实际工作中，我们要灵活运用各种工具和方法，结合具体的应用场景，不断积累经验，提高自己的运维能力。
评论