我已经在Kubernetes上运行Kafka了一段时间,而没有任何重大问题。但是,我最近引入了一组Cassandra pods ,并且开始出现Kafka的性能问题。

即使Cassandra不像Kafka那样使用页面缓存,它也会对磁盘进行频繁写入,这大概会影响内核的底层缓存。

我知道Kubernetes Pod通过cgroup管理内存资源,可以通过在Kubernetes中设置内存请求和限制来配置内存组,但是我注意到Cassandra对页面缓存的利用可能会增加Kafka Pod中页面错误的数量,即使它们似乎并没有争夺资源(即,他们的节点上有可用的内存)。

在Kafka中,更多页面错误会导致对磁盘的更多写入,这会妨碍顺序IO的优势并损害磁盘性能。如果使用类似AWS的EBS卷之类的东西,最终将耗尽突发平衡,并最终在整个集群中造成灾难性故障。

我的问题是,是否可以在Kubernetes中隔离页面缓存资源,或者以某种方式让内核知道我的Kafka Pod拥有的页面在缓存中的保留时间比在Cassandra Pod中保留的页面更长?

最佳答案

我认为这是一个有趣的问题,所以这是从一些挖掘中得出的一些发现。

最佳猜测:k8s OOB不能做到这一点,但是有足够的工具可用,因此它可能是研究和开发可作为DaemonSet部署的调整和策略应用程序的丰硕成果。

发现:

应用程序可以使用fadvise()系统调用向内核提供有关应用程序需要哪些文件支持的页面,哪些文件不能回收的页面的指南。

http://man7.org/linux/man-pages/man2/posix_fadvise.2.html

应用程序还可以使用O_DIRECT来尝试在执行IO时避免使用页面缓存:

https://lwn.net/Articles/457667/

有迹象表明,Cassandra已经使用fadvise尝试优化以减少其页面缓存占用量:

http://grokbase.com/t/cassandra/commits/122qha309v/jira-created-cassandra-3948-sequentialwriter-doesnt-fsync-before-posix-fadvise

三星最近还对内核中的Cassandra和fadvise进行了修补(2017年1月),以更好地利用多流SSD:

http://www.samsung.com/us/labs/pdfs/collateral/Multi-stream_Cassandra_Whitepaper_Final.pdf

Kafka知道页面缓存体系结构,尽管它似乎没有直接使用fadvise。内核提供的旋钮足以在专用主机上调整Kafka:

  • vm.dirty *,用于指导何时将已写入(脏)的页面写回到磁盘
  • vm.vfs_cache_pressure提供有关使用RAM进行页面缓存的积极程度的指南

  • 内核中对特定于设备的写回线程的支持可以追溯到2.6天:

    https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics

    Cgroup v1和v2专注于基于pid的IO限制,而不是基于文件的缓存调整:

    https://andrestc.com/post/cgroups-io/

    也就是说,旧的linux-ftools实用程序集有一个简单的命令行旋钮示例,用于在特定文件上使用fadvise:

    https://github.com/david415/linux-ftools

    这样就足够了。给定特定的kafka和cassandra工作负载(例如,大量读取和大量写入),特定优先级(相对于cassandra而言,kafka或相反)和特定IO配置(专用设备与共享设备),可能会出现一种特定的调优模型,归纳为政策模型。

    07-24 09:45
    查看更多