来源:http://blog.scoutapp.com/articles/2011/02/10/understanding-disk-i-o-when-should-you-be-worried
Do you have an I/O bottleneck?
Your I/O wait measurement is the canary for an I/O bottleneck. I/O Wait is the percentage of time your processors are waiting on the disk.
For example, lets say it takes 1 second to grab 10,000 rows from MySQL and perform some operations on those rows.
The disk is being accessed while the rows are retreived. During this time the processor is idle. It’s waiting on the disk. In the example above, disk access took 700 ms, so I/O wait is 70%.
---------------------------------------------------------------------------------------------------
[pope译]
有I/O瓶颈吗?
I/O wait 是i/o 瓶颈的方向标{the canary pope意译了}。i/o wait 是 处理器花费在等待磁盘上的时间百分比。
比如: 下图代表 1秒钟 处理 10,000 行的操作， 包含 从 mysql 读取 和 在这些数据上 完成 一些操作。
读取这些行的磁盘访问时间，处理器是空闲状态。它在等待磁盘读取。上面的例子，磁盘读取700ms，所以i/o wait 是70%。
================================================================
You can check your I/O wait percentage via
top, a command available on every flavor of Linux:
If your I/O wait percentage is greater than (1/# of CPU cores) then your CPUs are waiting a significant amount of time for the disk subsystem to catch up.
In the output above, I/O wait is 12.1%. This server has 8 cores (via
cat /proc/cpuinfo). This is very close to (1/8 cores = 0.125). Disk access may be slowing the application down if I/O wait is consistently around this threshold.
------------------------------------------------------------------------------------------------------------
[pope译]
你可以通过top 命令 ,多数流行的linux版本都支持的命令, 查看i/o wait 百分比:
如果你的I/O wait 百分比 高于 （1/# CPU内核个数），那么你的CPU们 正花大量的时间{significant
amount time}在等待 磁盘系统处理(to catch up).
上面的例子中, i/o wait 是12.1%。这个服务器有8个内核 (通过 cat /proc/cpuinfo 查看)。这个很接近 (1/8=0.125). 如果i/o wait 总保持这个值附件，磁盘存储 可能愈加慢下来。
==============================================================
What impacts I/O performance?
For random disk access (a database, mail server, file server, etc), you should focus on how many input/output operations can be performed per-second (IOPS).
Four primary factors impact IOPS:
- Multidisk Arrays – More disks in the array mean greater IOPS. If one disk can perform 150 IOPS, two disks can perform 300 IOPS.
- Average IOPS per-drive – The greater the number of IOPS each drive can handle, the greater the the total IOPS capacity. This is largely determined by the rotational speed of the drive.
---------------------------------------------------------------------------------
[pope译]
什么在影响i/o性能呢？
随机磁盘访问(数据库服务，邮件服务，文件服务，等等)，可以归结为 每秒有多少输入/输出操作被执行(IOPS)。
四点主要因素影响 IOPS:
- Multidisk Arrays(多磁盘阵列) - 多个磁盘阵列意味着更高的IOPS. 如果一个磁盘可以 完成 150 IOPS, 那两个磁盘就可以 完成 300 IOPS.
- Average IOPS per-drive(平均IOPS) - 每个设备越大的IOPS控制处理量(The greater the number of IOPS each drive can handle 这么翻译可以吗?)，就越高的IOPS总量,这个主要取决于磁盘转速。
- ===============================================================
- RAID Factor – Your application is likely using a RAID configuration for storage, which means you’re using multiple disks for reliability and redundancy. Some RAID configurations have a significant penalty for write operations. For RAID 6, every write request requires 6 disk operations. For RAID 1 and RAID 10, a write request requires only 2 disk operations. The lower the number of disk operations, the higher the IOPS capacity. This article has a great breakdown onRAID and IOPS performance.
[pope译]
RAID Factor(RAID 因素)- 你的应用可能使用到了RAID,这意味着你使用多磁盘保证可靠和冗余.某些RAID结构 对写操作 有特别的意义。对 RAID6，每个写请求 需要6个磁盘操作完成。 而对于RAID 1 和RAID 10,一个写入请求只需要2个磁盘操作。较低的磁盘操作意味着，更高的IOPS容量。这篇（This article)中有更多关于 RAID 和 IOPS容量的分类介绍。
=============================================================
Read and Write Workload – If you have a high percentage of write operations and a RAID setup that performs many operations for each write request (like RAID 5 or RAID 6), your IOPS will be significantly lower.
-----------------------------------------------------------------------------------------------
[pope译]
Read and Write Workload（读写量）- 如果你有更多的写操作 ，那么RAID可以为每个写请求提供更快的操作(例如 RAID5 或者 RAID6)，而IOPS却相对较低。
=============================================================
Calculating your maximum IOPS
A more exact way to determine just how close you are to your maximum I/O throughput is to calculate your theoretical IOPS and compare it to your actualIOPS. If the numbers are close, there may be an I/O issue.
You can determine theoretical IOPS via the the following equation:| I/O Operations Per-Sec = | number of disks * Average I/O Operations on 1 disk per-sec |
| % of read workload + (Raid Factor * % of write workload) |
All but one of the pieces in this equation can be determined from your hardware specs. You’ll need to figure out the read/write workload though – it’s application dependent. For this, use a tool like sar. You can also install the Scout Device Input/Output plugin which reports read and write throughput.
-----------------------------------------------------------------------------------------------
[pope译]
计算你最大IOPS[popexizhi:我要看的内容，注意了~]
通过 计算你的理论IOPS 并且比较 真实环境的IOPS 可以让你更精准的确定 是否接近你的最大I/O吞吐量了。如果结果很接近，这个应该就是I/O 问题了。
可以通过如下公式计算理论IOPS:
通过 计算你的理论IOPS 并且比较 真实环境的IOPS 可以让你更精准的确定 是否接近你的最大I/O吞吐量了。如果结果很接近，这个应该就是I/O 问题了。
可以通过如下公式计算理论IOPS:
| I/O Operations Per-Sec = | number of disks * Average I/O Operations on 1 disk per-sec |
| % of read workload + (Raid Factor * % of write workload) |
[popexizhi:这个sar try一下，Device Input/Output plugin 应该是iostat了.]
=============================================================
Read & write throughput captured via the Scout Device Input/Output plugin. In this case, the vast majority of the workload is dedicated to writing.
[pope译] 读&写 吞吐量通过 Device Input/Output plugin 获得。这个例子中，写操作工作量过大。
=============================================================
Once you’ve calculated your theoretical IOPS, compare it to the
tps column displayed via sar. The tps column indicates the number of transfers per second that were issued to the device. This is your actual IOPS. If the tps is near the theoretical IOPS, you may be at capacity.
Check out a more detailed calculation of IOPS.
[pope译]
一旦你计算出自己的理论IOPS，与通过sar获得的内容比较。这个tps行 代表 每秒 设备翻译的数量[the tps column indicates the number of transfers per second that were issued to the device.是这样翻译吗？]这个是你实际的IOPS.如果tps 接近 理论IOPS,你就应该注意了。
点击这里有更多的细节关于如何计算IOPS(Check out a more detailed calculation of IOPS.)
=============================================================
[pope译]
一旦你计算出自己的理论IOPS，与通过sar获得的内容比较。这个tps行 代表 每秒 设备翻译的数量[the tps column indicates the number of transfers per second that were issued to the device.是这样翻译吗？]这个是你实际的IOPS.如果tps 接近 理论IOPS,你就应该注意了。
点击这里有更多的细节关于如何计算IOPS(Check out a more detailed calculation of IOPS.)
=============================================================
What’s the best path to fixing an I/O bottleneck?
Even if a banana slug follows all of the tips in The 4 Hour Body, it will never be as fast as an F-18 Hornet. Likewise, you can tune your disk hardware for better performance, but it’s complicated and will not approach the speed of RAM.
[pope译]
什么是最好的方式处理I/O瓶颈?
即使黄色鼻涕虫 遵从 The 4 Hour Body 全部的提示，它也不可能快过F-18 大黄蜂。{[popexizhi] The 4 Hour Body 是什么啊？！:)简单go了一下，发现应该是一种高效锻炼的书吧:)} 同理，你可以调整你的硬盘使其有更好的表现，但是它很难也不可能接近RAM的速度。
=============================================================
If you’re hitting a disk I/O bottleneck now, tuning your hardware likely isn’t the fastest remedy. Hardware changes likely involve significant testing, data migration, and communication between application developers and sys admins.
[pope译]
如果你现在碰到I/O瓶颈，调整你的硬件可能不是最快的措施。硬件的改变以为着大量的测试，数据迁移和应用程序与系统管理直接的通讯修改。
=============================================================
When we see I/O bottlenecks at the Blue Box Group, we first try to tweak the service that’s using the most I/O and cache more of its data in RAM. For example, we usually configure our database servers to have as much RAM as possible (up to 64 GB or so), and then have MySQL cache as much as possible in memory.
[pope译]
当我们在Blue Box Group看到I/O瓶颈,我们首先尝试缓存更多的数据在它的RAM中。例如，我们经常配置数据服务尽可能多的在RAM中(高达64GB左右)，以及尽可能多的缓存MYSQL数据到内存中。
=============================================================
[pope译]=============================================================
How do you monitor disk I/O?
It’s important to measure disk performance on data-heavy servers so you can judge how changes in your application impact disk performance over time. Ad-hoc readings of
top output don’t give much context: is what you’re seeing normal? Is this just a momentary peak? How did I/O Wait look 2 months ago?
Scout has two key plugins for measuring your disk performance.
- The CPU usage plugin monitors key CPU metrics, which include I/O Wait %.
- The Device Input/Output plugin provides additional I/O metrics for a given device, including the I/O Wait time in milliseconds and read/write throughput.
如何监控 磁盘I/O?
在大量处理数据服务器上衡量磁盘性能，是很重要的，如此你可以长期的计划{over time 应该是说can judge 吧？我理解的是，所以意译成这个 }，判断如何改变你的应用对磁盘的影响。某次特定的top 输出提供不了太多的信息: 你看到的什么是正常的？这也许只是瞬间峰值也说不定？2个月前的I/O wait 又是什么呢？
Scout 有两个插件来测量你的硬盘性能:
CPU usage plugin 监控CPU使用率 ，其中包括I/O wait %.
Device Input/Output plugin 提供给出设备的I/O使用率，包含毫秒级别的I/O wait时间 和I/O 吞吐量。
================================================================
【popexizhi:这篇虽然是介绍Scout的，但是我是冲IOPS的峰值是什么，已经read，write 的正常异常去的，这个公式
You can determine theoretical IOPS via the the following equation:
| I/O Operations Per-Sec = | number of disks * Average I/O Operations on 1 disk per-sec |
| % of read workload + (Raid Factor * % of write workload) |
看来要详细了解:
1.top 的 %wa 的极限值，正常值
2.io --next [http://www.cmdln.org/2010/04/22/analyzing-io-performance-in-linux/]
】
没有评论:
发表评论