从Kubernetes DSE集群卸载1TB数据的DSBulk失败

Question

我使用DSBulk将数据从安装在Kubernetes下的DSE集群中卸载到CSV中，我的集群由9个Kubernetes Pods组成，每个节点都有120 GB的Ram。

我在卸载数据时对资源进行了监视，并注意到CSV中获取的数据越多，就会越多地使用ram，并且由于内存不足而重新启动。

如果一次一个Pod停机，DSBulk卸载将不会失败，但如果2个Pod处于停机状态，则卸载将失败，例外情况是：

Cassandra在一致性LOCAL_ONE的读取查询期间超时(需要1次响应，但只有0次响应)。

是否有办法避免这种超出内存的情况发生，还是有办法增加超时时间。

我使用的命令是：

dsbulk unload -maxErrors -1 -h ‘[“ < My Host > ”]’ -port 9042 -u < My user name >
-p < Password > -k < Key Space > -t < My Table > -url < My Table > 
--dsbulk.executor.continuousPaging.enabled false --datastax-java-driver.basic.request.page-size 1000 
--dsbulk.engine.maxConcurrentQueries 128 --driver.advanced.retry-policy.max-retries 100000

Answer 1

经过大量的尝试和错误，我们发现问题在于库伯内特斯卡桑德拉吊舱使用主服务器的内存大小作为Max直接内存大小，而不是使用分配给Ram的最大内存大小。

这些吊舱被分配了120 GB的Ram，但是每个吊舱上的卡桑德拉将185 GB的Ram分配给file_cache_size，，这使得卸载过程失败，因为库伯内特斯正在重新启动使用Ram超过120 GB的每个pod。

原因是Max直接内存大小计算为：

Max direct memory = ((system memory - JVM heap size))/2

每个豆荚使用325 GB作为Max直接内存大小，每个豆荚都自动设置为Max直接内存大小值的一半，因此每当pod请求内存超过120 GB时，库伯奈特就会重新启动它。

它的解决方案是在Kubernetes集群的yaml文件中将Max直接内存大小设置为env变量，或者通过在每个荚的Cassandra文件上设置该值来覆盖它。