问题标签 [iowait]

我一直在试图追查为什么我的盒子上有 100% iowait。如果我执行 mysql 选择查询之类的操作，系统会进入 100% iowait（在我的服务器上的多个 cpu 上），这会杀死我的看门狗，有时还会杀死 httpd 本身。

在 vmstat 中，我看到每 8 秒左右，就有 5MB 磁盘写入。这会导致至少一个 cpu（共 4 个）阻塞一两秒。

我不得不说我的 ext3 中有几百万个文件（我尝试了 ext2，但我没有启用 atime，也没有启用日志。）有一个硬件 raid，镜像了两个 300GB 的 ide。

我错过了 dtrace。有没有办法找出导致这些写入的原因？以及如何加快文件系统的速度？

欢迎提出想法！

谢谢！

我正在开发一个与使用 Linux 内核的系统一起工作的监控代理。通过打开 /proc/stat ，您可以轻松了解一个或所有 CPU（聚合）等待 I/O 请求完成的时间。

我试图找到一种方法来分解这个数字，以便我可以区分磁盘和网络 i/o。例如，将内核节拍的单位转换为秒后，您会看到所有 CPU 的总和花费了 1024 秒等待 I/O。我想知道其中有多少是由于网络连接速度慢而被烧毁的。

我不确定这是否可能，感谢任何帮助:) 我在 /proc/net 或 sysfs 中看不到任何有帮助的东西。

我如何获得系统 ioWait？通过使用 /proc 接口的信息（我猜它写在那里的某处），这将是更可取的，因此应用程序可以检测到这一点，但是从我的应用程序对 exec() 的外部调用是可以接受的。

我有一个涉及许多机器/节点的并发系统。每台机器运行几个 JVM，做不同的事情。它是一个“分层”架构，其中每一层都由许多跨机器运行的 JVM 组成。基本上，顶层 JVM 通过文件从外部接收输入，解析输入并将其发送到第二层“存储”的许多小记录。第二层实际上并不持久化数据本身，而是实际上将数据持久化在第三层（HBase 和 Solr）中，而 HBase 实际上也不持久化它本身，因为它将数据发送到第四层（HDFS）进行持久化。

层之间的大部分通信都是同步的，因此当然它最终会导致许多线程等待较低层完成。但我希望那些等待的线程在 CPU 使用率方面是“免费的”。

不过，我看到一个非常高的 iowait（顶部的 %wa）——比如 80-90% iowait 和只有 10-20% 的 sys/usr CPU 使用率。系统似乎已经筋疲力尽——通过 ssh 登录缓慢，对命令响应缓慢等。

我的问题是所有等待较低层完成的 JVM 线程是否会导致这种情况？它不应该是“免费”等待响应（套接字）。就这一点而言，不同的层使用阻塞还是非阻塞（NIO）io有关系吗？究竟在什么情况下，Linux 会将某些东西算作 iowait（顶部的 %wa）？当机器上所有 JVM 中的所有线程都处于等待状态时（计数是因为在此期间没有其他线程可以运行来做有意义的事情）？或者，即使有其他进程准备好使用 CPU 进行实际处理，等待的线程是否也计入 %wa？

我真的很想彻底解释它是如何工作的以及如何解释这个高 %wa。一开始我猜想当所有线程都在等待时它算作 %wa，但是那里实际上有足够的空间来做更多的事情，所以我尝试增加线程数以期望获得更多吞吐量，但这并没有发生. 所以这是一个真正的问题，而不仅仅是一个“视觉”问题。

下面的输出取自仅运行 HBase 和 HDFS 的机器。我显示的问题是在具有 HBase 和/或 HDFS 的机器上（最清楚）

我们在 Amazon EC2/Rightscale m1.large 实例上的单节点 cassandra 上有以下统计信息，其中包含 2 个带有 raid0 的临时磁盘。（7.6 GB 总内存）

4 GB RAM 分配给 cassandra Heap，800MB 是 Heap NEW 大小。

以下统计数据来自 OpsCenter 社区 2.0

每秒读取请求 285 到 340 每秒
写入请求 257 到 720
操作系统负载 15.15 到 17.15
写入请求延迟 293 到 685 微秒
操作系统发送的网络流量 18 MB 到 30 MB 每秒
操作系统接收的网络流量 22 MB 到 34 MB 每秒
操作系统磁盘队列大小 23 到 26 个请求
读取请求待处理 8 到 20 个
读取请求延迟 69140 到 92885 微秒
OS 磁盘延迟 37 到 42 毫秒
OS 磁盘吞吐量 12 到 14 Mb/秒
磁盘 IOP 读取 600 到 740 每秒
磁盘 IOP 写入 2 到 7 次第二

IOWait 60 到 70 % CPU 平均

空闲 24 到 30 % CPU 平均

行缓存被禁用。

上述统计数据是否满足所提供的配置......或者我们如何进行更多调整以减少 IOWait............因为我们认为我们正在经历很多 IOWait......我们如何调整它以获得最佳效果。

读取请求是混合的............一些来自一个超级列系列和一个标准，拥有超过百万个键......并且不同的没有。超级列最多 14 个，数量不等。从 1 到 10000 的子列和不同的编号。标准列族中最多 14 列......子列本质上非常薄，值为 0 字节......名称为 8 个字节。

过程是从超级列族中删除数据并将处理后的数据写入标准列族。

EBS 磁盘会更好地工作吗……在 Amazon EC2 上

我们有一个在 linux debian 上运行 PostgreSQL 8.3 的专用数据库服务器。定期查询数据库以获取大量数据，同时更新/插入也经常发生。数据库会定期在短时间内（如 10 秒）不响应，然后再次进入正常执行流程。

我通过 top 注意到的是，只要数据库没有响应，在此期间就会出现 iowait 峰值。同时 pdflush 被激活。所以我的想法是pdflush必须根据脏页和背景比率将数据从缓存的内存空间写回磁盘。其余时间，当 postgresql 正常工作时，不会发生 iowait，因为 pdflush 不活动。我的 vm 的值如下：

我的记忆信息：

我正在考虑调整脏页留在内存中的持续时间（dirty_expire_centisecs），以便及时平均划分 iowait 峰值（更频繁地调用 pdflush 以便将较小的数据块写入磁盘）。任何其他建议的解决方案？

我需要一些帮助来提高 Cassandra 的读取性能。我担心随着列族大小的增加读取性能会下降。我们在单节点 Cassandra 上有以下统计数据。

操作系统： Linux - CentOS release 5.4 (Final)
Cassandra 版本： apache-cassandra-1.1.0
Java 版本： “1.6.0_14” Java(TM) SE Runtime Environment (build 1.6.0_14-b08) Java HotSpot(TM) 64 -Bit Server VM（内部版本 14.0-b16，混合模式）

卡桑德拉配置：（cassandra.yaml）

• rpc_server_type：hsha
• disk_access_mode：mmap
• 并发读取：64
• 并发写入：32

平台： Amazon-ec2/Rightscale m1.Xlarge 实例，带有 4 个带有 raid0 的临时磁盘。（15 GB 总内存，4 个虚拟内核，2 个 ECU，总 ECU = 8）

---

实验配置： 我曾尝试用 GC 做一些实验

Cassandra 配置：
10 GB RAM 分配给 Cassandra 堆，3500MB 是堆新大小。

JVM 配置：
JVM_OPTS="$JVM_OPTS -XX:+UseParNewGC"
JVM_OPTS="$JVM_OPTS -XX:+UseConcMarkSweepGC"
JVM_OPTS="$JVM_OPTS -XX:+CMSParallelRemarkEnabled"
JVM_OPTS="$JVM_OPTS -XX:SurvivorRatio=1000"
JVM_OPTS= "$JVM_OPTS -XX:MaxTenuringThreshold=0"
JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=40"
JVM_OPTS="$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCompressedOops"

---

OpsCenter 社区 2.0 的结果统计信息：

每秒读取请求 208 到 240 次
写入请求 每秒 18 到 28 次
操作系统负载 24.5 到 25.85
写入请求延迟 127 到 160
微秒 读取请求延迟 82202 到 94612 微秒
操作系统发送的网络流量 44646 KB 平均每秒
OS 接收的网络流量 4338 KB 平均每第二个
OS 磁盘队列大小 13 到 15 个请求
读取请求待处理 25 到 32

操作系统磁盘延迟 48 到 56 毫秒
操作系统磁盘读取吞吐量 4.6 Mb/秒
磁盘 IOP 读取 420/秒

IOWait 80 % CPU 平均

空闲 13 % CPU 平均

行缓存被禁用。

---

列族 我仅从中读取的列族之一是通过 CLI 创建的

列族 SSTable 大小 = 7.10 GB，SSTable 计数 = 2

XColFam列族有59499904号。估计的行键（大多数是具有不同长度的 utf8 文字，通过 mx4jtools 估计），其列本质上很薄，值为 0 字节......现在。

大多数行应该有非常少的列数，可能是 1 到 10，因此列名的第一个组件大约有 20 到 30 个字节，第二个是 8 个字节的整数....复合列的第二个组件是动态的可以重复但概率很低.......第一个组件在品种中重复，但行中的列数可能不同。

我试图SnappyCompression压缩列族，但大小没有变化。

我有一个计划的服务，它使用 20 个线程运行几个小时，并对这个列族的多个键（现在每个请求有 2 个键）发出随机读取请求，并读取整行，没有列切片等。

我认为它现在表现不佳，因为它每分钟处理的请求太少。当列族大小不是那么大时，它之前工作得更好。它大约是 3 到 4 GB。

我担心随着列族大小的增加，读取性能下降得太快。

我还尝试调整一些 GC 和内存的东西，因为在那之前我有很多 GC 和 CPU 使用率。当数据量较小且波形中的iowait非常小时。

---

如何提高 Cassandra 的性能。您的建议将不胜感激。

我想确定我的应用程序是 IO 还是 CPU 受限。是否有这样的工具来确定您的应用程序的运行时间有多少用于 CPU 等待/IO 等待/在 CPU 上运行等？我正在从终端运行我的应用程序。我听说实际上有这样一个用于 linux 的工具，但我不知道它是什么。

Oracle Version: 11.1.0.7.0

我们的一个 Oracle RAC 实例中有更高的 IO 等待

一个 SQL 的执行时间较长 - 每次执行 1452.57 秒。这开始突然发生的一天。以前，查询 20k(:v4 参数) 记录最多需要 3-4 分钟

subscribeinfo 记录：5900 万（非并行）

收费记录：2k - 3k

SQL如下

选择 o.msisdn，o.spid，o.serviceid，o.ChargeReferenceID，o.channelID，o.nextchargetime，o.failtimestamp，o.lastmonfeeday，o.networkId，o.retryEndDateTime，o.trialType，o.subFlag，o .faultCode 来自 subscribeinfo o，chargerate r 其中 (o.monthbillid = :v1) and (((o.state = :"SYS_B_00") and (o.nextchargetime < :v2) and ((o.IsAutoExtend <> :"SYS_B_01 ") 或 ((o.IsAutoExtend = :"SYS_B_02") 和 (o.extendflag <> :"SYS_B_03")))) 或 (o.subFlag = :"SYS_B_04" 和 o.state = :"SYS_B_05" 和 o .retryenddatetime > :v2)) 和 (o.ChargeClassForSub = r.chargeclassidx) 和 ((r.chargemode = :"SYS_B_06" and r.activetype = :"SYS_B_07" and o.nextchargetime != :"SYS_B_08" ) 或 ( r.chargemode = :"SYS_B_09" 和 r.activetype <> :"SYS_B_10") or (r.chargemode >= :"SYS_B_11" and r.chargemode <= :"SYS_B_12" and r.basecharge >= :"SYS_B_13") or (r.chargemode = :"SYS_B_14") or (r .chargemode = :"SYS_B_15") 或 (r.chargemode = :"SYS_B_16") 和 (o.failtimestamp <= :v3) 和 (rownum <= :v4)

根据 AWR 报告 Top 5 Timed Foreground Events

直接路径读取 [平均等待时间：22 秒，%DB 时间：50.75%] DB 文件顺序读取 [平均等待时间：15 秒，%DB 时间：38.00]

我将无法发布完整的 AWR 报告，因为它受到限制。所以请询问详细信息我会发布

请在下面找到解释计划：

ID Exec Ord Operation Go To More Peek Bind Capt Bind Cost2 Estim Card LAST Starts LAST Output Rows LAST Over/Under Estimate1 PStart PStop 工作区 0 7 SELECT STATEMENT
23335 1 2577 1 6 COUNT STOPKEY [+] [+]
[+] 23335 1 2577 2 5 HASH JOIN [+] [+]
[+] 23335 20001 1 2577 8x over [+] 3 1 .. TABLE ACCESS FULL CHARGERATE [+] [+] 68 3035 1 3036 1x 4 4 .. 分区列表单 [+] 23266 25223 1 2577 10x over KEY KEY 5 3 ... 按本地索引 ROWID SUBSCRIBEINFO 访问表 [+] [+] [+]
[+] 23266 25223 1 2577 10x over KEY KEY 6 2 .... INDEX RANGE SCAN IDX_FAILTIMESTAMP_NEW [+] [+] [+] [+] 2435 1 2100765 KEY KEY

IOSTAT

Linux 2.6.16.46-0.12-smp (mdspdb01) 11/16/12

平均 CPU：%user %nice %system %iowait %steal %idle

设备：tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn

sda 5.71 39.53 121.79 665679995 2051190222

sdb 85.75 178.15 171.12 3000316741 2881953582

sdc 111.05 161.69 43.96 2723201251 740429949

---

我们为monthbilid、nextchargetime 和failtimestamp 字段创建了一个索引……尽管它的基数提高了1/6，但成本却增加了4-5 倍。但是oracle默认采用新索引

在 subscribeinfo(monthbillid, nextchargetime, failtimestamp) 本地表空间 IMUSE_INDEX 上创建索引 IDX_MONTHBILLQUERY；

dbms_stats.gather_index_stats('IMUSE01', 'IDX_MONTHBILLQUERY');

我们在 AWR 报告中有硬解析 = 0。我们也改变了 cursor_sharing = FORCE

现在 IO 得到控制。还是觉得，这不是根本原因。此外，我们为这个查询设置了专用实例，该查询每小时发生超过 10 次，检索 20k 条记录大约需要 100 秒。

谁能建议我是否将优化器模式作为 first_rows 或使用提示 first_rows(20000) 是否是一个好的决定。

到目前为止，我们已经禁用了 stats 作业，我们可以只为某些表或某些索引启用相同的功能吗？这可能吗？

我的朋友设计师正在手动编译他的 LESS 文件并使用 Coda（远程站点）上传它，花费了大量宝贵的时间。他问我：

是否可以自动检测 Linux 服务器上的文件更改并毫不延迟地进行编译？