Kafka由于ext4的日志问题导致IO.WAIT升高的解决办法

先引用kafka的ext4文件系统使用注意事项

http://orchome.com/48

Ext4 may or may not be the best filesystem for Kafka. Filesystems like XFS supposedly handle locking during fsync 
better. We have only tried Ext4, though.

Ext4可能是也可能不是最好的文件系统，据说像XFS文件系统处理锁fsync更好，我们只尝试过Ext4。


EXT4 is a serviceable choice of filesystem for the Kafka data directories, however getting the most performance out of
 it will require adjusting several mount options. In addition, these options are generally unsafe in a failure 
concern as the disk can be wiped and the replicas rebuilt from the cluster. In a multiple-failure scenario, such as a power outage, this can mean underlying filesystem (and therefore data) corruption that is not easily recoverable. The 
following options can be adjusted:

EXT4可供Kafka数据目录文件系统选择。要获得最佳的性能将需要几个挂载选择。另外，这些选项在故障情况下通常是不安全的。并且将导致更多的数据丢失和
损坏。 对于单个broker故障，无心担心，可以擦除磁盘，并从集群重建副本。在多故障情况下，如断电，这可能意味着底层文件系统（数据）损坏，这是不容
易恢复的。 可以调整以下选项：

It is not necessary to tune these settings, however those wanting to optimize performance have a few knobs that will 
help:

这些设置不是必须的，提供了一些方式，将帮助优化性能：

data=writeback: Ext4 defaults to data=ordered which puts a strong order on some writes. Kafka does not require this 
ordering as it does very paranoid data recovery on all unflushed log. This setting removes the ordering constraint and 
seems to significantly reduce latency.
data=writeback: 默认Ext4为data=ordered（对一些写入设置强顺序写入）。Kafka不需要，因为kafka的数据在所有未冲洗的日志上恢复。此设置删除
了排序约束，并且显著地减少了延迟（似乎）。
Disabling journaling: Journaling is a tradeoff: it makes reboots faster after server crashes but it introduces a great 
deal of additional locking which adds variance to write performance. Those who don't care about reboot time and want 
to reduce a major source of write latency spikes can turn off journaling entirely.
禁用日志记录：日志是一个权衡，它使服务器崩溃后重启更快，但它引入了大量的额外的锁定，这增加了写性能的差异。如果不关心重启时间，想减少写入高峰延
迟，可以完全关闭日志记录。
commit=num_secs: This tunes the frequency with which ext4 commits to its metadata journal. Setting this to a lower 
value reduces the loss of unflushed data during a crash. Setting this to a higher value will improve throughput.
mmit=num_secs：调整ext4提交到其元数据日志的频率。将此值设置的较低可减少崩溃期间未冲洗数据的丢失。设置的越高将提高吞吐量。
nobh: This setting controls additional ordering guarantees when using data=writeback mode. This should be safe with 
Kafka as we do not depend on write ordering and improves throughput and latency.
nobh：此设置是当使用data=writeback时，控制额外的排序保证。这应该与kafka是安全的，因为我们不依赖写入顺序，并提高吞吐量和延迟。
delalloc: Delayed allocation means that the filesystem avoid allocating any blocks until the physical write occurs. 
This allows ext4 to allocate a large extent instead of smaller pages and helps ensure the data is written 
sequentially. This feature is great for throughput. It does seem to involve some locking in the filesystem which adds a bit of latency variance.
delalloc: 延迟分配意味着文件系统避免分配任何块，直到物理写入发生。这允许ext4分配很大程度上代替小的页面并确保数据按顺序写入。这一特性非常适
合吞吐量，它涉及在文件系统中增加了一些延迟差异锁（似乎）。

我的操作步骤

umount /data           #先卸载磁盘
tune2fs -O ^has_journal /dev/sdd1   #动态禁用磁盘的journaling日志
dumpe2fs /dev/sdd1 | grep 'Filesystem features' | grep 'has_journal' #查看是否禁用成功，没有结果代表成功了
fsck.ext4 -f /dev/sdd1  #动态禁用日志功能后需要对文件系统进行fsck检查，避免出错：
mount -O data=writeback /dev/sdd1 /data   #使用writeback模式挂载磁盘

这篇文章写了调整参数后的性能优化测试结果

http://blog.csdn.net/helloanthea/article/details/50464774