慢跑查询

Question

我们有一个需要3个小时才能完成的查询。这以前不是问题。之前，调用此查询的代码部署在weblogic上，并使用后者自己的连接池管理器。

现在，由于该过程占用大量内存，我们将此代码拉出并使其在自己的堆空间上运行。调用查询的请求是通过jms进行的。我还注意到，我们使用的连接池管理器是使用其默认设置（最大连接数= 8，最小连接数= 0）的dbcp。 jms客户端是多线程的。

当我们通过一个接口（TOAD）执行查询时，它只需要2秒钟，所以从这里我排除了“责备”数据库。

我想知道我可以从这里找到哪些步骤来找到瓶颈。也许有连接池的东西？

Answer 1

你应该使用像VisualVM或线程转储这样的工具来检查你的线程在做什么。他们只是在等待一些IO操作才能完成？是否有一些很差的同步代码等待时间比所需时间长？也许甚至是三小时（或三小时）超时后停止的僵局？

Answer 2

我觉得总是值得回到您可以使用的最基本的Java性能工具：线程转储。有很多方法可以得到一个线程转储：

• 如果你有一个控制台，使用Ctrl-中断（赢），或CTRL- \（* nix中）
• jstack
• 的JConsole和线程标签或可用mbeans导致转储

看看你的程序在做什么。定期采取这些。有些工具可以帮助您查看大型线程转储，如Thread Dump Analyzer或Samurai。

您也可以使用jconsole或Visual VM以交互方式查看，但我认为读取原始转储的完善人才将为您提供良好的服务。