0

我们正在使用 SQL Server 2005（sqljdbc 驱动程序 1.2）运行 jboss 4.2.2。

我们最近安装了新的遗物，可以看到我们的交易存在很大的瓶颈。

通常，对于任何一个 Web 请求，瓶颈位于以下之一：

  • master..xp_sqljdbc_xa_start
  • master..xp_sqljdbc_xa_commit
  • org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection()
  • master..xp_sqljdbc_xa_end

在其中一项上花费了数百毫秒（在某些情况下为几秒钟）。累积的大部分响应时间都花在了这些项目上。

我正在尝试确定它是否属于以下任何一种：

  • 摆脱 XA 交易会有帮助吗？
  • 我的数据库中是否存在我无法查看的更大问题？
  • 我可以升级我的 SQL 驱动程序来帮助解决这个问题吗？
  • 或者这是否表明只有很多查询，我们应该从查看我们的代码开始，并尝试降低整体查询的数量？
4

1 回答 1

1

如果您在单个事务中针对多个资源执行工作，则需要 XA 事务，如果您需要一致性，则需要 XA。但是，您所说的“查询”可能意味着您主要进行只读活动，因此 XA 可能是矫枉过正。此外，您没有谈到使用多个数据库或其他事务性资源，所以您真的需要 XA 吗？

所以第一步：了解需求，您是否需要跨越多个数据库交互的事务范围？如果您只是执行单个查询，则不需要 XA。如果您混合了需要 XA 的活动和不需要 XA 的简单查询，则使用两种不同的连接，一种带有 XA，一种没有 - 这阐明了您的意图。但是，我希望 XA 驱动程序使用单一资源优化，这样如果不需要 XA，您就不必支付开销，所以我怀疑这里还有更多事情要做。（免责声明我不使用 JBoss，所以我的直觉是可疑的）。

所以看看你的事务范围是否合适，隔离级别是否合理等等。您是否因为交易时间过长而发生争用，例如交易是否超过了用户的思考时间？

接下来是几秒钟的等待：这意味着争用（或一些奇怪的网络问题） 我能想到的 xa_start 缓慢的唯一原因是写入事务日志花费了不合理的时间 - 您的日志可能在一些慢速网络设备上吗？等待 getConnection() 可能只是意味着您的连接池太小（或者您保持连接的时间太长）如果 xa_commit 和 xa_end 需要很长时间，我想知道资源管理器在做什么，你能从数据库服务器获取任何信息。

我的总体立场：如果您真的需要 XA，那么您将支付一些日志记录和网络消息开销，但这些不应该花费您数百或数千毫秒。大多数业务系统通常在更新两个其他独立系统时需要在其整体资源访问的一小部分中使用 XA，而在只读场景中几乎从不 - 分布式系统之间的绝对一致性几乎没有意义，因此使用 XA 进行查询几乎肯定是矫枉过正。

于 2013-01-04T07:53:27.227 回答