查询运行缓慢
我们有一个查询需要 3 小时才能完成。这在以前不是问题。之前，调用这个查询的代码部署在weblogic上，并使用后者自己的连接池管理器。
现在，由于该进程占用了大量内存，因此我们将这段代码取出并使其在自己的堆空间上运行。调用查询的请求是通过jms发出的。我还注意到我们使用的连接池管理器是 dbcp，使用其默认设置（最大连接数 = 8，最小连接数 = 0）。 jms 客户端是多线程的。
当我们通过接口（TOAD）执行查询时，只需要 2 秒，所以从这里我已经排除了“指责”数据库的可能性。
我想知道我可以采取什么步骤来找到瓶颈。也许与连接池有关？
We have a query that's taking 3 hours to finish. This wasn't a problem before. Before, the code that calls this query is deployed on weblogic and uses the latter's own connection pool manager.
Now since the process occupies a lot of memory, we pulled this code out and made it run on its own heap space. The request to call the query is made via jms. I also noticed that the connection pool manager we are using is dbcp using its default settings (max connections = 8, min connections =0). The jms client is multithreaded.
When we executed the query via an interface (TOAD), it only takes 2 seconds so from here I have ruled out "blaming" the database.
I was wondering what steps I could take from here to find the bottle neck. Maybe something with the connection pool?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您应该使用 VisualVM 或线程转储等工具来检查线程正在做什么。他们只是在等待某些 IO 操作完成吗？是否有一些同步不良的代码等待的时间比需要的时间长得多？甚至可能是在三小时（或三个一小时）超时后停止的僵局？
You should use a tool like VisualVM or a thread dump to check what are your threads doing. Are they just waiting for some IO operation to complete? Is there some poorly synchronized code waiting much longer than needed? Maybe even a deadlock that stops after a three-hour (or three one-hour) timeout?
我发现退回到您可以使用的最基本的 Java 性能工具总是值得的：线程转储。有很多方法可以获取线程转储：
看看您的程序正在做。定期服用这些。还有一些工具可以帮助您查看大型线程转储，例如线程转储分析器< /a> 或 武士。
您还可以使用 jconsole 或 Visual VM 以交互方式查看此内容，但我认为熟练的读取原始转储的能力将为您提供很好的服务。
I find it's always worthwhile to fall back to the most basic Java performance tool at your disposal: thread dumps. There are lots of ways to get a thread dump:
Look at what your program is doing. Take these periodically. There are tools to help you look at big thread dumps as well like the Thread Dump Analyzer or Samurai.
You can also use jconsole or Visual VM to look at this interactively but I think a well-developed talent for reading raw dumps will serve you well.