环境:
Delphi应用程序使用TSQLConnection
对象的AfterConnect事件处理程序记录打开TSQLConnection
的时间。
在随机间隔中,连接需要三分钟的“额外时间”。我首先怀疑它可能是SQL查询的一个问题,但今天更详细的日志记录显示它是挂起的SQLConnection.Connect
。
我不确定这是否可能是网络,InterBase服务器或Delphi / dbExpress层的问题。
有没有人经历过类似的三分钟“挂起”?
P.S。 Java应用程序没有记录连接时间,所以我不能说它会受到这个问题的影响。
自从我们在2012年开始登录以来,这种现象出现在日志文件中,但上个月的速度急剧上升。唯一的环境变化是增加了新的Windows服务器(用于RDP服务,邮件和传真),因此它可能是与网络相关的问题。
答案 0 :(得分:0)
除了可能的网络问题之外,延迟的原因可能是,您的查询有时会在其查询的某个表中触发垃圾回收。
我不知道 Interbase 7.5 内部细节,但根据我的经验(使用 Firebird ),这通常发生在select
上最近删除/更新了许多记录的表格。
垃圾收集仅在数据库扫描,数据库备份或在表上进行SELECT查询(而不是INSERT,ALTER或DELETE)时执行。每当Firebird /InterBase®触摸一行时,例如在SELECT操作期间,版本控制引擎就会清除事务编号早于最旧有趣事务(OIT)的行的任何版本。这有助于保持版本历史记录的小巧性和可管理性,并使性能保持合理。
在低使用时间进行的定期扫描或备份可以提高性能并最大程度地降低因不方便的垃圾收集而遭受攻击的风险。有关详细信息,请参阅Interbase 7.5 Operations Guide上的扫描间隔和自动内务管理(第6-20页)和促进垃圾收集(第11-19页)。< / p>
答案 1 :(得分:0)
由于随着网络上新增服务器的增加,速率会增加,因此可能会丢失数据包并导致重试超时。为了测试该假设,您可以将连接超时更改为较小的值。您还可以使用wireshark或tcpdump监视服务器之间的网络流量。
要监控TCP握手,您只能使用:
tcpdump -i eth0'tcp [13]&amp; 2 = 2
答案 2 :(得分:0)
请检查所提到的服务器上的任何磁盘上是否已激活硬盘节电。这可以解释如果您在第一次连接时有延迟,然后在后续连接中没有延迟。然后,一段时间后节电被激活,同样的问题再次出现。