性能压测问题排查思路

一个接口在做性能压测的时候，100并发的时候CPU，响应时间是正常的，但是到200并发的时候CPU飙升到90%并且响应时间从600ms飙升到3s说一下你的排查思路：

1.数据库方面排斥思路

|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 数据库表没有加索引 |
| #### 1. 核心原因：从索引查找到全表扫描的成本爆炸 * 100并发时：内存缓冲还在起作用 * 当没有索引时，数据库执行查询通常需要全表扫描。 * 在压测初期或低并发时，数据库的Buffer Pool（缓冲区）是相对"干净"的。随着100个并发查询的执行，它们需要将表的数据页从磁盘加载到内存中。 * 随着压测的持续，这张表的大部分数据可能已经被加载到了内存里。 * 关键点： 在100并发时，虽然执行的是全表扫描，但因为数据已经在内存中了（逻辑IO），所以CPU只需要处理内存中的数据。内存的读写速度非常快（纳秒级），CPU可以轻松应对100个并发线程对内存数据的遍历。 * 200并发时：物理IO爆发，CPU等待与上下文切换的恶性循环 * 当并发数翻倍到200时，情况发生了质变。 * 内存不够了： 200个线程同时进行全表扫描，意味着每个线程都要遍历整个表。如果表的大小超过了分配给数据库的Buffer Pool大小，内存就会迅速被占满。 * 激烈的淘汰与载入： 内存被占满后，旧的缓存数据必须被淘汰，才能为新查询让路。这会导致大量的物理磁盘读取（物理IO）。 * CPU的困境： CPU的速度远远快于磁盘IO。当200个线程发起海量的物理读请求时，CPU需要花费大量时间来做两件事： 1. 发起IO请求：告诉磁盘控制器去读数据。 2. 上下文切换：由于磁盘读很慢，操作系统会让发起读请求的线程进入"休眠"等待状态，转而执行其他线程。当磁盘数据读回来后，又会产生中断，把等待的线程唤醒。 * 结果： 系统资源被大量消耗在"发起请求-等待-切换-唤醒"这个循环上，真正用于处理业务的CPU时间反而变少了。这就导致了CPU使用率飙升到90%（主要用于管理IO和线程切换），而查询响应时间也因等待磁盘而急剧延长到3秒。 #### 2. 并发本身加剧了全表扫描的负面影响没有索引时，数据量对查询成本的影响是线性的，但并发数对系统总成本的影响是指数级的。 * 假设： 一张表有100万行数据，一次全表扫描需要扫描100万行。 * 100并发： 意味着每秒需要处理 100万行/秒 * 100 = 1亿行 的逻辑判断。 * 200并发： 意味着每秒需要处理 100万行/秒 * 200 = 2亿行 的逻辑判断。 CPU需要处理的逻辑行数直接翻倍。这不仅仅是数字翻倍，当内存无法容纳全部数据时，还会叠加前面提到的物理IO等待成本。这就像一条高速公路，100辆车跑100迈很顺畅，但200辆车同时涌上来，即使每辆车都想跑快，也会因为需要频繁地排队、并线（上下文切换）而导致整体速度（响应时间）急剧下降。 #### 3. 排查路径：如何验证你的猜想如果你怀疑是索引问题，可以通过以下步骤来验证这个"100并发正常，200并发飙升"的现象： 第一步：查看数据库的关键指标 在200并发压测时，登录数据库，执行以下命令（以MySQL为例）： sql -- 查看当前的线程状态，是不是很多都在 'Sending data'（代表正在扫描数据） SHOW PROCESSLIST; -- 查看磁盘读写压力指标 SHOW GLOBAL STATUS LIKE '%innodb_data_reads%'; -- 物理读次数 SHOW GLOBAL STATUS LIKE '%innodb_buffer_pool_read_requests%'; -- 总逻辑读次数 -- 计算逻辑读与物理读的比例，如果物理读比例在200并发时急剧升高，说明内存已经无法覆盖工作集 第二步：执行一次成本分析 对怀疑的查询执行EXPLAIN： * 确认 type 列是否为 ALL（全表扫描）。 * 确认 rows 列扫描的行数是否非常大。 第三步：模拟大压力下的单条查询 如果不想重新压测，可以尝试在数据库空闲时，清空缓存 执行一次查询，对比 有缓存 时执行一次查询的耗时差异。 * SELECT SQL_NO_CACHE * FROM your_table WHERE your_column = '某个不存在的值'; （模拟物理读） * SELECT * FROM your_table WHERE your_column = '某个不存在的值'; （如果刚查过，可能走缓存）如果物理读比逻辑读慢几十倍甚至上百倍，就印证了高并发下物理IO爆发导致CPU飙升的推测。 #### 总结 "100并发正常，200并发CPU飙升"是因为系统从"内存计算"状态被推入了"磁盘IO等待+频繁上下文切换"的"风暴"状态。 * 100并发 ：数据在内存中，CPU在计算，效率高。 * 200并发 ：内存不够，数据在磁盘上，CPU忙于调度和等待，效率极低，表现为高CPU占用（系统态开销大）和长响应时间。解决这个问题的核心，就是通过添加合适的索引，将"大海捞针"式的全表扫描（需要加载整个表），转变为"查目录"式的索引查找（只需加载少量索引页和个别数据页），从而大幅降低对内存和磁盘IO的需求，让系统在200并发时依然能保持稳定。 |