我们有 6 个 kafka 代理，具有 256GB RAM、24c/48T，它们托管 20 个在 raid10 中配置的 1.8TB SAS 10K rpm 磁盘。
有两个 Spark Streaming 应用程序
- 每 10 分钟开始他们的批次
- 一旦开始，他们的第一份工作就是阅读同一个 kafka 主题。
- 该主题有 200 个分区，均匀分布在 6 个代理上（每个代理上 33 个分区）。
- 流媒体应用程序使用 kafka 客户端 0.8.2.1 从 kafka 消费
有 21 个注入器实例以 6K 事件/秒的速率连续写入该主题。他们使用 librdkafka poroducer 为 kafka 制作事件。
当流媒体应用程序醒来时，他们的第一项工作是阅读主题。一旦他们这样做，kafka 磁盘中的 %util 会在 30 秒到 60 秒内达到 90-100%，同时所有注入器实例都会从他们的 kafka 生产者那里收到“队列已满”错误。这是生产者配置：
- queue.buffering.max.kbytes：2097151
- 逗留时间：0.5
从这张图中看不到，但在高 util% 期间，有一段时间写入为 0，我们假设在这些时间段内，注入器的生产者的队列已满，因此抛出“队列已满”错误。
值得一提的是，我们在kafka机器中使用了deadline IO调度器，它优先考虑读取操作。
关于如何释放写入压力，我们有几个想法：
- 减少不必要的 iops - 将 kafka 磁盘配置从 raid10 更改为 non-raid ("jbod")
- 传播读取 - 使 spark 应用程序在不同时间从 kafka 读取，而不是同时醒来
- 更改写入和读取的优先级 - 将 IO 调度程序更改为 CFQ
我写这个问题是为了验证我们是否走在正确的轨道上，并且由于 raid10、deadline IO 调度程序以及同时读取过多，操作系统确实在读取期间写入。
你怎么看？