正如标题所说，我有一个问题，rabbitmq显示（并认为）有更多的空间可用，正如我告诉他的。
我在2个RHEL pod中运行了2个rabbitmq 3.8.8和erlang 23.0的示例。对于这些pod，一个动态配置的PersistentVolume在NFS上的大小为2GB。这意味着，每个pod都应该有1GB的空间。
在rabbitmq.conf中，我有以下内容：
vm_memory_high_watermark.relative = 0.9
total_memory_available_override_value = 1000MB
disk_free_limit.absolute = 1GB
management.load_definitions = /etc/rabbitmq/definitions.json另外，当我启动Rabbitmq时，我在日志中看到配置读取正确：
2020-10-13 08:26:51.726 [info] <0.427.0> Memory high watermark set to 858 MiB (900000000 bytes)
2020-10-13 08:26:51.811 [info] <0.439.0> Enabling free disk space monitoring
2020-10-13 08:26:51.811 [info] <0.439.0> Disk free limit set to 1000MB问题是，rabbitMQ不知怎么地认为，有整个NFS可用空间-54 GB（如上面的截图所示）。所以我遇到了一个问题，超过20万条消息被卡在一个队列中，填满了我给他的2GB的PersistentVolume，但没有停止接收消息，因为他认为还有更多的可用空间。当然，整个rabbitmq pod崩溃，因为它无法将更多消息写入NFS。
请您指导一下，如何设置才是正确的？2或者您知道，为什么rabbitMQ不尊重 *disk_free_limit.absolute值 * 吗？
非常感谢
2条答案
按热度按时间dwbf0jvd1#
将显示实际有效的配置值。
在Linux上，RabbitMQ将使用配置的绝对值，或者通过运行以下命令来计算其数据目录的分区具有多少磁盘空间
因为它不知道Kubernetes的配额。
我在Kubernetes上没有NFS分区可供尝试，但使用以下
rabbitmq.conf文件进行了基本测试不繁殖;配置的值按预期使用。请参阅1。
cdmah0mi2#
关于您的问题：“为什么rabbitMQ不尊重disk_free_limit.absolute值”--我认为它尊重（即使它错误地对待k8s / pod的空闲内存）。
该值在您附加的图像中显示为“954 MiB低水位线”-这意味着当您只有1 GB的磁盘可用空间时，代理将阻止发布者发布，并且只允许使用者使用，直到磁盘上有更多可用空间。
因此只要机器具有多于1GB的可用容量，它就继续接受消息。
也许是因为它错误地读取了它有54 GB的可用空间，所以它崩溃了，但是disk_free_limit.absolute值似乎读取正确。