服务器 Gind.cn

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

TCP Keepalive和防火墙消除空闲会话

在客户站点中,networking团队在客户端和服务器之间添加了防火墙。 大约40分钟的空闲时间后,这会导致空闲连接断开。 networking人士说,防火墙没有任何空闲的连接超时,但事实是空闲的连接被打破。 为了解决这个问题,我们首先configuration了tcp_keepalive_time = 300,tcp_keepalive_intvl = 300和tcp_keepalive_probes = 30000的TCP keepalive服务器(一台Linux机器)。 这是有效的,连接可以持续数天或更长时间。 但是,我们也希望服务器检测到死的客户端并终止连接,所以我们将设置更改为time = 300,intvl = 180,probes = 10,认为如果客户端确实存在,服务器会每隔300s (5分钟),并且客户端将以ACK进行响应,并且防止防火墙将其视为空闲连接并将其消除。 如果客户端死了,10次探测之后,服务器将中止连接。 令我们吃惊的是,这些空闲而又活跃的联系人在大约40分钟后就像以前一样死亡。 运行在客户端上的Wireshark在服务器和客户端之间根本不显示任何keepalive,即使在服务器上启用keepalive也是如此。 这里会发生什么? 如果服务器上的keepalive设置是time = 300,intvl = 180,probes = 10,我认为如果客户端处于活动状态但空闲,服务器将每隔300秒发送一次keepalive探针,客户端已经死了,它会在300秒后发送一个,然后每隔180秒再发送9个探测器,然后再杀死连接。 我对吗? 一种可能性是防火墙以某种方式拦截来自服务器的keepalive探测器,并且无法将它们传递给客户端,并且获得探测器的事实使得认为连接处于活动状态。 这是防火墙的常见行为吗? 我们不知道涉及哪种防火墙。 服务器是Teradata节点,连接是从Teradata客户端实用程序到服务器端的端口1025的数据库服务器,但我们已经看到与SSH连接相同的问题,所以我们认为它会影响所有TCP连接。

排除Redmine性能故障

我有一个Redmine实例(Bitnami Stack),速度非常慢。 因为我只是想深究其中,所以我想在这里讨论一些理论。 所以,如果有人对此有任何想法,请随时提供帮助:-) 系统: Bitnami堆栈与Redmine 1.4.x升级到Bitnami堆栈与Redmine 2.1.0是这样的: mysqldump'd旧数据库 用Redmine 2.1.0安装了新的Bitnami堆栈 干净地导入转储与重新创build所有表 耙db:迁移和所有 该堆栈正在使用OpenSUSE 12.1的虚拟机上运行。 资源不应该是一个问题,因为总是有几千GB的空闲内存,Redmine请求上的CPU峰值只能达到2个cpu核心的50%。 也只有很less的用户访问它。 什么可能是非常重要的:用户login是通过LDAP(ActiveDirectory)处理的。 问题: 在每个请求Redmine反应exception缓慢。 有时需要3秒钟,有时甚至需要10秒才能发送页面。 我的想法: 我不知道是否在Redmine的LDAP设置中选中了“即时创build用户”,我今天晚些时候才能检查这个。 但是,这里可能缺less支票是一个问题吗? 身份validation需要一些时间,login时是正常的,并确认。 但是,如果不是即时创build用户,是仅保留一个会话还是对每个请求重新进行身份validation,这可能是问题所在? Redmine 2.x可能比1.4.x慢得多,这只是普通的? Bitnami的Apache2 + Passengerconfiguration有问题吗? MySQL的索引不会是一个问题,因为MySQL对CPU非常冷静,是吗? 还有一件事对我来说似乎很奇怪,但可能是一个错误的测量结果(当我看到机器时,需要重新检查这个): 我试图检查是否是一个networking问题(networking反应慢,也许DNS或什么;服务器在本地networking)。 似乎本地主机上的请求(直接在OpenSUSE VM上的浏览器)很快,但通过networking的请求不是。 通常我会想到一个networking问题,但奇怪的是:当实际测量连接时间时,networking速度如此之快。 平安好,静态交货时间也是。 似乎只有Redmine方计算的页面被应用程序服务器缓慢发送,而Apache仍然很快 – 但只有当请求是远程局域网请求时。 很奇怪,但正如我上面提到的,我必须重新检查这一个。 这对我来说似乎不合逻辑。