服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

调整Linux IP路由参数 – secret_interval和tcp_mem

我们今天的HAProxy虚拟机有一个小小的故障转移问题。 当我们挖掘它时,我们发现这一点: Jan 26 07:41:45 haproxy2内核:[226818.070059] __ratelimit:10个callback被抑制 1月26日07:41:45 haproxy2内核:[226818.070064] Out of socket内存 1月26日07:41:47 haproxy2内核:[226819.560048] Out of socket内存 1月26日07:41:49 haproxy2内核:[226822.030044] Out of socket内存 其中,通过这个链接 ,显然与net.ipv4.tcp_mem低默认设置有关。 所以我们将它们的默认值增加了4倍(这是Ubuntu服务器,不确定Linux的风格是否重要): 当前值是:45984 61312 91968 新值是:183936 245248 367872 之后,我们开始看到一个奇怪的错误消息: 1月26日08:18:49 haproxy1内核:[2291.579726]路由哈希链太长! 1月26日08:18:49 haproxy1内核:[2291.579732]调整你的secret_interval! 嘘.. 这是一个秘密! 这显然与/proc/sys/net/ipv4/route/secret_interval ,默认为600,并控制周期性的刷新路由caching secret_interval指示内核多频繁地吹走所有路由哈希条目,而不pipe它们是多么新/旧。 在我们的环境中这通常是不好的。 每当清除caching时,CPU将忙于重build每秒数千条logging。 然而,我们设置这个每天运行一次,以防止内存泄漏(虽然我们从来没有)。 虽然我们很乐意减less这种情况, 但build议您定期删除整个路由caching ,而不是简单地将旧值从路由caching中移出的速度更快。 经过一番调查,我们发现/proc/sys/net/ipv4/route/gc_elasticity这似乎是保持路由表大小的更好的select: gc_elasticity可以最好地描述为内核在开始使路由哈希条目过期之前将接受的平均存储桶深度。 这将有助于维持活跃路线的上限。 我们将弹性从8调整到4,希望路由caching修剪更加积极。 secret_interval不适合我们。 但是还有一些设置,不清楚哪一个是真正正确的方法。 / proc […]