LOAD高但是CPU和IO都很低问题

解析Linux进程中D状态及解决方法
最新推荐文章于 2025-05-24 20:13:32 发布
原创 最新推荐文章于 2025-05-24 20:13:32 发布 · 2.3w 阅读 · 5 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文深入探讨了Linux进程中D状态的含义及其产生的原因，详细解释了D状态表示进程处于不可打断的睡眠状态，并提供了针对不同原因导致的D状态的解决策略，特别是与NFS服务中断相关的具体解决方案。


现象：

执行w命令，查看load情况


使用sar命令查看，CPU和load都不高


查看进程状态

top 然后执行shift+o，进入排序页面


键入 w字母（表示按照进程状态排序），回车，然后键入R


猜测由于nfs导致问题，执行：df -h


看到有网络文件系统。

查看了一些资料，涉及进程的D状态:  uninterruptible sleep (不可打断的睡眠状态)

[1] http://www.dewen.io/q/5664

“上图阐释了一个进程运行的情况，首先，运行的时候，进程会向内核请求一些服务，内核就会将程序挂起进程，并将进程放到parked队列，通常这些进程只会在parked队列中停留很短的时间，在ps(1)列表中是不会出现的。但是如果内核因为某些原因不能提供相应服务的话。例如，进程要读某一个特定的磁盘块，但是磁盘控制器坏了，这时，除非进程完成读磁盘，否则内核无法将该进程移出parked队列，此时该进程标志位就会被置为D。由于进程只有在运行的时候才能接受到signals，所以此时在parked队列上的进程也就无法接收到信号了。解决这个问题的方法要么是给资源给该进程，要么是reboot
通俗一点说，产生D状态的原因出现uninterruptible sleep状态的进程一般是因为在等待IO，例如磁盘IO、网络IO等。在发出的IO请求得不到相应之后，进程一般就会转入uninterruptible sleep状态，例如若NFS服务端关闭时，如果没有事先amount相关目录。在客户端执行df的话就会挂住整个会话，再用ps axf查看的话会发现df进程状态位已经变成D。”

[2] http://blog.kevac.org/2013/02/uninterruptible-sleep-d-state.html 

Sometimes you will see processes on your linux box that are in D state as shown by ps, top, htop or similar. D means uninterruptible sleep. As opposed to normal sleep, you can't do anything with these processes (i.e. kill them).

[3]http://blog.xupeng.me/2009/07/09/linux-uninterruptible-sleep-state/

ps 的手册里说 D 状态是 uninterruptible sleep，Linux 进程有两种睡眠状态，一种 interruptible sleep，处在这种睡眠状态的进程是可以通过给它发信号来唤醒的，比如发 HUP 信号给 nginx 的 master 进程可以让 nginx 重新加载配置文件而不需要重新启动 nginx 进程；另外一种睡眠状态是 uninterruptible sleep，处在这种状态的进程不接受外来的任何信号，这也是为什么之前我无法用 kill 杀掉这些处于 D 状态的进程，无论是 kill, kill -9 还是 kill -15，因为它们压根儿就不受这些信号的支配。

进程为什么会被置于 uninterruptible sleep 状态呢？处于 uninterruptible sleep 状态的进程通常是在等待 IO，比如磁盘 IO，网络 IO，其他外设 IO，如果进程正在等待的 IO 在较长的时间内都没有响应，那么就很会不幸地被 ps 看到了，同时也就意味着很有可能有 IO 出了问题，可能是外设本身出了故障，也可能是比如挂载的远程文件系统已经不可访问了，我这里遇到的问题就是由 down 掉的 NFS 服务器引起的。

正是因为得不到 IO 的相应，进程才进入了 uninterruptible sleep 状态，所以要想使进程从 uninterruptible sleep 状态恢复，就得使进程等待的 IO 恢复，比如如果是因为从远程挂载的 NFS 卷不可访问导致进程进入 uninterruptible sleep 状态的，那么可以通过恢复该 NFS 卷的连接来使进程的 IO 请求得到满足，除此之外，要想干掉处在 D 状态进程就只能重启整个 Linux 系统了。

[4]http://www.orczhou.com/index.php/2010/05/how-to-kill-an-uninterruptible-sleep-process/

这个是最详细的，但是也很难理解；为什么IO的uninterruptible sleep会导致load变高呢？

“进入该状态的进程，会一直等待NFS，不接受任何信号，当然也就无法被杀死（kill/fuser -k）。因为进程一直在运行队列（running queue）中，所以还会导致主机的Load上升（虽然主机并不繁忙）。如果由于这个原因被卡住的进程很多的话，主机的Load可能会看起来非常高。”

引出来一个问题就是，为什么IO问题会导致load变高，这个 running queue在哪里可以看到呢？uninterruptible sleep状态的进程为什么会使load变高？



CPU使用过低，load过高
huangleijay的专栏
06-21 2165
1：按照网上说的，这种情况很有可能下面的情况 等待磁盘I/O完成的进程过多，导致进程队列长度过大，但是cpu运行的进程却很少，这样就体现到负载过大了，cpu使用率低。 使用“iostat -txk 1”或者“sar -d 1”（每个一秒采样）来查看： io阻塞会让出cpu，如果大多数的进程都在阻塞，那么会造成太多的上下文切换，这种切换消耗了cpu的时间，但是没有真正的执行任务！ 根据load的官方解释： System load averages is the average numbe..
CPU负载很低，loadavg很高处理方法
m0_37625564的博客
07-01 2309
CPU空闲但是load average很高
LOAD高但是CPU和IO都很低问题解决
ang639
09-02 7855
生产环境借用别人机器的CPU LOAD居高不下，合
linux负载高但cpu使用率低,系统负载高, 但CPU使用率和IO都非常低 - 第15页 - 系统管理 - LinuxTone | 运维专家网论坛 - 最棒的Linux运维与开源架构技术交流社区!...
weixin_28958733的博客
05-13 240
本帖最后由 mbillion 于 2011-9-7 17:14 编辑查看系统有以下进程，就是由于这个引起root 310890.00.0 3796 400 ? D Sep02 0:00 cat /sys/hypervisor/uuidroot 311070.00.0 87001040 ? Ss Sep01 ...
linux load高 cpu io 低,cpu load高的排查思路
weixin_33664951的博客
05-13 1024
1. 首先排查哪些进程cpu占用率高。 通过命令 ps ux 2. 查看对应java进程的每个线程的CPU占用率。通过命令：ps -Lp 15047 cu 3. 追踪线程内部，查看load过高原因。通过命令：jstack 15047。或者打印线程 jstackpidof java> stack.out查找到对应的threadid, 再反查代码。一般经验cpu load的飙升，一方面...
linux-一次load高但是cpu占用率低的排查
nina19900811的博客
07-04 1万+
一次load高但是cpu占用率低的排查    作者 randyjia 关注 2015.12.18 10:08 字数 343 阅读 878评论 0喜欢 0 load过高但是cpu占用率低的排查 过程描述 某天晚上，短信受到报警，说mongodb服务器cpu load过高；登录到线上一看，使用top命令，发现load到了12(db服务器是4核）但是cpu占用
linux大io引起cpu使用率偏高,系统负载高, 但CPU使用率和IO都非常低
weixin_39640157的博客
05-12 361
ps auxUSER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMANDroot 10.00.010348 696 ? Ss May21 0:00 init [5]root 20.00.0 0 0 ? Sr...
Load飙高问题排查过程
小徐的博客
01-25 1377
🎉欢迎来到专栏：Load飙高问题排查过程好学而不勤非真好学者📜 欢迎大家关注！❤️。
Load高，CPU idle很高，这情况太诡异了
weixin_33885676的博客
06-12 1805
Load很高，CPU使用率很低的诡异情况 第一次碰到这种Case：物理机的Load很高，CPU使用率很低 先看CPU、Load情况 如图一：vmstat显示很有多任务等待排队执行（r）top都能看到Load很高，但是CPU idle 95%以上 这个现象不太合乎常规，也许是在等磁盘IO、也许在等网络返回会导致CPU利用率很低而Load很高 贴个vmsta...
iotop&iostat （load高 IO高的问题排查）
u010023489的专栏
04-27 860
执行 cpu  us sy 显示都不高，并且wa 占用高，说明系统在等待大量的io操作   1、安装iotop sudo yum install iotop   2、top命令显示   从top命令可以看出，系统load 6.43，对于4 cpu的系统来说，已经是超载，另外 wa 60%，可以确定系统的线程在等待io操作 其中 线程 2492 比较可疑 top -H -p 2492    3、iostat iostat ALL ：可以查阅 那个磁盘读写频繁   4、sudo i
服务器load高但是CPU使用率低
热门推荐
森林里的一天
08-10 1万+
线上应用部署了两台服务器，项目发布之后跟踪线上服务器性能，发现一台load为3，一台load为1，四核服务器，有一台已经快到瓶颈了，因此紧急排查下原因 1.TOP命令查看load和占用CPU比较大的进程，显示如下 shift+c排序 占用最大的也就0.7% 1命名查看每个cpu的使用情况 基本上都处于空闲状态 2.vmstat 2 5查看io情况 procs -----------me...
Linux服务器CPU使用率较低但负载较高
weixin_33933118的博客
12-11 4236
CPU使用率较低但负载较高 问题描述 Linux 系统没有业务程序运行，通过 top 观察，类似如下图所示，CPU 很空闲，但是 load average 却非常高，如下图所示。 处理办法 load average 是对 CPU 负载的评估，其值越高，说明其任务队列越长，处于等待执行的任务越多。出现此种情况时，可能是由于僵死进程导致的。可以通过指令 ps -axjf 查看是否存在 D 状态进程。 ...
linux 负载高 cpu低,Linux服务器CPU使用率较低但负载较高
weixin_33856202的博客
05-13 1197
CPU使用率较低但负载较高问题描述Linux 系统没有业务程序运行，通过top观察，类似如下图所示，CPU 很空闲，但是 load average 却非常高，如下图所示。 处理办法load average是对 CPU 负载的评估，其值越高，说明其任务队列越长，处于等待执行的任务越多。出现此种情况时，可能是由于僵死进程导致的。可以通过指令ps -axjf查看是否存在 D 状态进程。D 状态...
14.Linux rpm,brew软件安装包命令，zsh和bash，内置命令和外部命令，ps命令，top命令解析，swp，为什么cpu利用率很低，负载却很高？
Sai_BAN的博客
04-19 1611
解释一下rpm, opt,opt-get, brew,brewhome wget是什么，和brew联系和区别 ps命令 man info help --help 如何区分内置命令和外部命令？ zsh 和 bash 的区别是什么？ top命令 展示值解析 系统负载是什么 平均负载是怎么算的 平均负载的具体计算逻辑是怎么样的 每个核心的负载和平均负载之间的联系和区别 如何查看系统中 CPU 核心的个数？ htop里面的swp是什么？有什么作用？ 明明物理内存还有很多，为什么swp却占比那么高 为什么cpu利用率
Linux中CPU使用率低负载高
******* ▄︻┻┳═一 *******
11-14 9723
一、原因总结     等待磁盘I/O完成的进程过多，导致进程队列长度过大，但是cpu运行的进程却很少，这样就导致负载过大，但cpu使用率低。 二、场景分析 (1)磁盘读写请求过多就会导致大量I/O等待     cpu的工作效率要高于磁盘，而进程在cpu上面运行需要访问磁盘文件，这个时候cpu会向内核发起调用文件的请求，让内核去磁盘取文件，这个时候会切换到其他进程或者空闲，这个任务就会转
Linux内存很低CPU满,Linux中CPU使用率低负载高
weixin_39523835的博客
05-06 2194
Linux中CPU使用率低负载高一、原因总结等待磁盘I/O完成的进程过多，导致进程队列长度过大，但是cpu运行的进程却很少，这样就导致负载过大，但cpu使用率低。二、场景分析(1)磁盘读写请求过多就会导致大量I/O等待cpu的工作效率要高于磁盘，而进程在cpu上面运行需要访问磁盘文件，这个时候cpu会向内核发起调用文件的请求，让内核去磁盘取文件，这个时候会切换到其他进程或者空闲，这个任务就会转换为...
cpu使用率低但是cpu负载高什么原因？
sre救赎之路
05-24 2483
CPU 负载的本质负载（Load Average）反映的是一段时间内（通常取 1 分钟、5 分钟、15 分钟）处于 Runnable（运行中或等待 CPU）和 Uninterruptible Sleep（不可中断睡眠，如等待 I/O）状态的进程数。高负载 ≠ 高 CPU 使用率：即使 CPU 使用率低，若有大量进程在排队等待 CPU 或阻塞在 I/O 操作，负载仍会升高。CPU 计算资源未充分利用，但系统整体调度压力或 I/O 阻塞导致任务处理效率低下。排查时需重点关注。
记一次愚蠢的失误，centos cpu满载但单进程cpu占用很低
strike2206的博客
08-27 2308
症状： 在宝塔管理面板看到服务器满百，CPU负载满百，内存富裕，磁盘富裕，网站能正常访问。 排查： top查询后发现除了elasticsearch与阿里云盾占用偶尔过10%之外，其他都是在1%甚至0% 查看宝塔的监控页面，对照安全页面，cpu负载飙升的时刻，操作记录显示当时正在重启redis，判断应该是调整redis配置时导致的异常 因为单进程CPU占用极低，排除病毒干扰的话，可能是因为...
tpcc-mysql测试 cpu使用率很低
最新发布
10-15
<think>首先，用户的问题是：“我想查找tpcc-mysql测试时CPU使用率很低的原因及解决办法”。这是基于之前的引用内容，我需要参考这些引用来分析。 回顾引用： - 引用[1]：提到TPC-C测试在腾讯云1核2G内存机子上表现糟糕，数据库未调优。 - 引用[2]：比较MySQL和其他系统的性能，但提到CPU效率节约一半。 - 引用[3]：描述某公司进行TPC-C测试的环境和方法。 - 引用[4]：讨论TPCC测试的约束和目标，以及删除库重新导入数据以再次测试。 用户的主要疑问是：在tpcc-mysql测试中，CPU使用率很低的原因和解决方法。我需要基于这些引用和一般知识来回答。 关键点： - CPU使用率低意味着数据库没有充分利用处理器资源，可能导致性能瓶颈在其他地方。 - 在TPC-C测试中，CPU使用率低可能的原因： - I/O瓶颈：磁盘读写慢，CPU空闲等待。 - 锁竞争：如锁冲突导致线程阻塞。 - 配置问题：如MySQL参数设置不当（如线程池、缓冲区大小）。 - 测试工具或环境限制：如虚拟机资源限制。 - 数据量小：测试数据不足，导致负载低。 从引用[1]：提到“腾讯云1核2G内存机子不怎么给力”和“数据库没有经过任何调优”，暗示资源受限和配置问题可能影响性能。 引用[4]：提到需要删除库重新导入数据以确保测试状态OK，这暗示数据准备的重要性。 因此，原因可能包括： 1. I/O瓶颈：磁盘慢，CPU等待。 2. 内存不足：缓冲池小，导致频繁磁盘访问。 3. 配置不当：如innodb_buffer_pool_size太小。 4. 并发设置：如测试工具并发线程数少。 5. 环境因素：虚拟机或云实例限制CPU资源。 解决方法： 1. 调优MySQL： - 增加缓冲池大小（innodb_buffer_pool_size）。 - 优化查询和索引（引用[4]提到表和索引数据）。 2. 检查I/O： - 使用SSD磁盘。 - 优化磁盘配置。 3. 增加负载： - 确保数据量足够（引用[3]提到10个仓库）。 - 调整BenchmarkSQL或tpcc-mysql的并发用户数。 4. 环境优化： - 使用更高CPU和内存的服务器。 - 确保操作系统设置优化。 5. 监视和分析： - 使用工具如vmstat、iostat监视CPU和I/O。 - 查看MySQL慢查询日志。 回答结构： - 系统指令要求：使用中文，行内数学用$...$，独立公式用$$...$$（如果需要），生成相关问题。 - 回答清晰可靠。 - 末尾添加引用标识。 生成相关问题： - 根据用户查询，生成相关的问题，如如何调优MySQL等。 最终回答结构： 1. 解释原因。 2. 提供解决方法。 3. 结尾添加相关问题。 4. 自然地添加引用标识。 例如： 原因可能包括[^1][^4]... 解决方法：... §§相关问题§§ 1. ... 2. ... 3. ... </think>### tpcc-mysql测试时CPU使用率低的原因及解决方法 在tpcc-mysql测试中，CPU使用率低通常表示数据库未能充分利用硬件资源，导致性能瓶颈。这会影响测试结果，如TPS（每秒事务数）降低。基于引用内容和实践经验，以下是主要原因和解决方法： #### 一、CPU使用率低的原因 1. **I/O瓶颈导致CPU空闲**： - 磁盘读写速度慢（如使用HDD而非SSD），CPU等待I/O操作完成而空闲[^1][^4]。 - 数据加载或查询时频繁访问磁盘，而非内存缓存。 2. **MySQL配置不当**： - **缓冲池过小**：如`innodb_buffer_pool_size`设置太小，无法缓存热点数据，增加磁盘I/O压力[^1]。 - **并发参数不合理**：如`innodb_thread_concurrency`或`thread_cache_size`过低，限制了并发处理能力。 - **日志写入延迟**：`innodb_flush_log_at_trx_commit=1`（默认）确保数据安全但增加I/O开销，CPU利用率下降。 3. **测试环境限制**： - 资源不足：如引用[1]所述，1核2G内存的云服务器（如腾讯云）无法处理高负载[^1]。 - 虚拟机CPU配额限制：云环境可能限制vCPU性能。 - 数据量不足：引用[3]提到TPC-C需要足够仓库数量（如10个），数据量小导致负载过低[^3]。 4. **测试工具或方法问题**： - 并发用户数设置过低：BenchmarkSQL或tpcc-mysql的并发线程数不足。 - 数据未正确初始化：引用[4]强调需重新导入表和索引数据，否则约束检查失败（如业务占比不达标）[^4]。 5. **锁竞争或索引缺失**： - 行锁或表锁冲突导致事务阻塞，CPU空闲等待。 - 缺少优化索引，查询扫描大量数据，增加I/O而非CPU计算负载。 #### 二、解决方法 通过调优MySQL参数、优化环境和测试方法，可提升CPU利用率： 1. **优化MySQL配置**： - **增大缓冲池**：调整`innodb_buffer_pool_size`为可用内存的70-80%。例如，16GB内存服务器设置为： ``` innodb_buffer_pool_size = 12G ``` - **调整并发参数**： ``` innodb_thread_concurrency = 0 # 自动适配CPU核心数 thread_cache_size = 16 # 减少线程创建开销 ``` - **平衡日志写入**：改为`innodb_flush_log_at_trx_commit=2`（牺牲部分持久性提升性能）。 2. **解决I/O瓶颈**： - 使用SSD磁盘替代HDD。 - 启用`innodb_io_capacity`和`innodb_io_capacity_max`，匹配磁盘IOPS能力。 3. **优化测试环境**： - **升级硬件**：选择更高核数（如8核CPU）和大内存的实例（引用[3]中8核16GB环境）[^3]。 - **确保数据充足**：按TPC-C标准生成足够仓库（如50+），参考引用[4]重新导入数据： ```bash # 删除旧库并重新初始化 mysqladmin drop tpcc ./tpcc_load localhost tpcc user password 10 # 10个仓库 ``` 4. **调整测试参数**： - 增加并发用户数（如BenchmarkSQL的`-c`参数从50增至100）。 - 监视实时负载：使用`vmstat`或`iostat`观察CPU和磁盘使用： ```bash iostat -dx 2 # 每2秒显示磁盘I/O ``` 5. **数据库索引优化**： - 分析慢查询日志（`slow_query_log=1`），为高频查询添加索引。 - 确保TPC-C表索引完整（引用[4]强调索引数据状态必须OK）[^4]。 #### 三、验证效果 - **调优后测试**：重新运行tpcc-mysql，监视CPU使用率（如`top`命令）。理想状态下，CPU利用率应接近70-90%。 - **参考案例**：引用[2]显示，优化后TDSQL-C MySQL的CPU效率可提升近50%[^2]。 如果调整后仍无改善，检查操作系统层限制（如ULIMIT）或云服务配额。定期优化能显著提升测试准确性[^1][^3][^4]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值