4

环境：

  • Delphi 2009 客户端应用程序（和一个 Java），在 Windows 2003 服务器上运行
  • 通过 dbExpress 连接到 InterBase 7.5.1（另一个 Windows 2003 服务器）

TSQLConnectionDelphi 应用程序使用对象的 AfterConnect 事件处理程序记录打开时间TSQLConnection。

在随机间隔中，连接需要三分钟的“额外时间”。我首先怀疑这可能是 SQL 查询的问题，但今天更详细的日志显示它是SQLConnection.Connect挂起的。

我不确定这是否可能是网络、InterBase 服务器或 Delphi / dbExpress 层的问题。

有没有人经历过类似的三分钟“挂起”？

ps Java 应用程序没有记录连接时间，所以我不能说它是否受到这个问题的影响。

从 2012 年我们开始登录日志文件以来，这种现象就出现在日志文件中，但在上个月出现了急剧上升。唯一的环境变化是添加了新的 Windows 服务器（用于 RDP 服务、邮件和传真），因此它可能是与网络相关的问题。

4

3 回答 3

0

请检查是否在上述服务器上的任何磁盘上激活了硬盘节电功能。这将解释您是否在第一次连接时有延迟，然后在后续连接中没有延迟。然后，一段时间后，省电功能被激活，同样的问题再次出现。

于 2013-09-09T10:57:14.570 回答
0

由于速率随着网络上新服务器的添加而增加，您可能会丢失数据包并且重试超时。为了测试该假设，您可以将连接超时更改为一个较小的值。您还可以使用wireshark 或tcpdump 监控服务器之间的网络流量。

监控

要仅监视 TCP 握手，您可以使用：

tcpdump -i eth0 'tcp[13] & 2 = 2

于 2013-09-08T14:10:52.897 回答
0

除了可能的网络问题之外，延迟的原因可能是，您的查询有时会在它正在查询的一个表中触发垃圾收集。

我不详细了解Interbase 7.5内部结构，但根据我的经验（使用Firebird），这通常发生在 aselect在最近删除/更新了许多记录的表上创建时。

IBExpert.net 上的这个文档解释了它：

垃圾收集仅在数据库扫描、数据库备份或对表进行 SELECT 查询时执行（而不是通过 INSERT、ALTER 或 DELETE）。每当 Firebird/InterBase® 触及一行时，例如在 SELECT 操作期间，版本控制引擎会清除事务号早于最旧有趣事务 (OIT) 的行的任何版本。这有助于保持版本历史小且易于管理，并保持性能合理。

在低使用时间进行定期扫描或备份，可以提高性能并最大限度地减少被不方便的垃圾收集所击中的风险。有关这方面的更多信息，请参阅Interbase 7.5 操作指南中的扫描间隔和自动内务管理（第 6-20 页）和促进垃圾收集（第 11-19 页）。

于 2013-08-30T11:35:05.693 回答