标签：io   os   使用   ar   文件   数据   art   sp   问题   

consumer offset commit

使用kafka的python api时遇到了offset回滚的问题，因为最初使用了autocommit参数，发现有时会重复取记录，发现autocommit是批量提交，并且有offset回滚的问题，具体原因未发现，解决方法是手动调用commit函数提交，经过测试手动调用没有出现offset回滚的问题。

partition

一开始为了简单只使用了一个分区，consumer都从一个leader取数据，请求压力都在一台机器。使用不同分区策略可以分散topic的leader，还可以灵活处理不同数据。

fetch msg

MaxWaitTime 请求最大等待时间，MinBytes 请求消息的最小字节数，通过这2个参数可以调整你获取数据时的等待策略，最简单的做法就是不等待，没数据直接返回。

zookeeper

对于zookeeper不太了解，因此忽略了dataDir和dataLogDir这2个目录的配置对系统造成的影响。由于硬盘限制，把kafka和zookeeper的日志目录放在了同一个磁盘，而且磁盘的性能不是很好，造成了kafka写数据效率低下，每次写数据只有几百k。zookeeper网站上对这2个配置有Notes说不要把他们放在繁忙的磁盘设备上，会影响其他程序写磁盘的性能，最好这2个目录都分开存放不同设备。简单看了一下，dataDir下存的是snapshot文件，dataLogDir存的是log文件，应该是zookeeper把内存数据持久化到这2种文件中了，而且持久化操作很频繁且写的数据很少，会影响kafka写日志。

iostat -d -x

这是关于磁盘性能监控的。在排查磁盘io高的问题时用到了iostat -d -x 命令，由于对磁盘不是很了解，在排查时主要关注w/s、wkB/s、rkB/s，对于扇区没怎么关注，rsec/s wsec/s avgrq-sz这几个参数反应磁盘操作扇区的情况，当磁盘利用率高且iowait高，而平均扇区低也就意味着磁盘把大量时间用于磁盘寻道，你可能需要考虑是不是有大量随机写磁盘的操作。

end

以上是对在使用kafka时遇到的问题的一些总结。

应用kafka的总结

标签：io   os   使用   ar   文件   数据   art   sp   问题   

原文地址：http://my.oschina.net/u/566882/blog/316569