我们有6个kafka代理，256gbram，24c/48t，它们托管在raid10中配置的20x1.8tbsas10krpm磁盘。
有两个spark流媒体应用程序
每10分钟开始一批
一旦他们开始，他们的第一份工作就是阅读同一个Kafka主题。
该主题有200个分区，平均分布在6个代理上（每个代理上有33个分区）。
流媒体应用程序使用kafka客户端0.8.2.1从kafka消费
有21个喷油器示例以6k事件/秒的速率连续写入该主题。他们使用librdkafka poroducer为Kafka制作事件。
当stremaing应用程序醒来时，他们的第一项工作就是阅读主题。一旦这样做，kafka磁盘中的%util将变为90-100%，持续30秒-60秒，同时所有注入器示例都会从kafka生产者那里获得“队列已满”错误。这是生产者配置：
queue.buffering.max.kbytes:2097151
玲儿.ms:0.5

从这张图上看不出来，但在高利用率%期间，有一段时间的写入为0，我们假设在这段时间内，注入器的生产者的队列已满，因此抛出“队列已满”错误。
值得一提的是，我们在kafka机器中使用了deadline io调度程序，它优先于读取操作。
对于如何释放写作压力，我们有几个想法：
为了减少不必要的iops—将kafka磁盘配置从raid10更改为非raid（“jbod”）
传播阅读——让spark应用程序在不同的时间阅读Kafka的作品，而不是在同一时间醒来
要更改写入和读取的优先级，请将io调度程序更改为cfq
我写这个问题是为了验证我们在正确的轨道上，确实操作系统hault在读取过程中写入，因为raid10，截止期io调度程序和太多的读取在同一时间。
你怎么认为？