英文:
how to profile c++/unix for blocking or sleeping code
问题
我正在开发一个较大的C++共享库,并最近将完整的数据库访问类替换为池使用等等。
在更改之前,某个与数据库相关的任务(根据性能等)在库(应用服务器上)产生了预期的CPU负载以及在数据库服务器上的CPU负载,并花了大约45分钟的时间。
现在在替换了数据库访问类之后,任务仍然需要很长时间(约40分钟),但应用服务器和数据库服务器上的CPU使用率都非常低。
所以我的期望是,我确实优化了代码(在两个系统上都释放了大量的CPU负载),但总体时间并没有减少。应用服务器的网络使用情况也按预期保持不变。
可能存在一些阻塞代码,如信号量(例如从池中获取连接)或休眠,但我无法找到一种分析运行时间而不是CPU时间的方法,从而获得是否存在磁盘问题(例如,数据库写入磁盘)、网络问题(无意义地重新连接到数据库)、(阻止)问题(例如,多线程使用池.grab)、MQ领域中的某些问题或其他问题的线索。
有人能给我一些提示如何对此进行分析并找到时间浪费者吗?
数据库系统应该足够强大,但通过Internet隧道连接,其余的部分目前在应用服务器上以单个多线程进程运行。
英文:
I'm developing a larger shared library in C++ and recently exchanged the complete database accessing classes to e.g. pool usage etc.
Before the change, a certain db-related task caused (according to perf etc.) an expected amount of CPU load in the lib (on application server) as well as CPU load on the DB server and took about 45 minutes.
Now after exchanging the database access classes, the task still takes much time (~40minutes), but CPU usage on application server as well as on DB server is VERY low.
So my expectation is, that indeed I optimized the code (freeing up MUCH CPU load on both systems), but the overall time did not decrease at all. Network usage of app server also expectedly stayed the same.
There probably is some blocking code like semaphores (e.g.grabbing a connection from pool) or sleep, but I fail to find a way to profile RUNtime instead of CPUtime and thus getting a hint wheather I have a disk issue (e.g. DB writing to disk), a network issue (senseless reconnections to DB), a (b)locking issue (e.g. multithreaded usage of pool.grab), something in the MQ area or whatever.
Can someone give me a hint how to profile this and find the time waster?
The DB system should be by far fat enough but connected via Internet tunnel the rest is at the moment running in a single multithreaded process on app server.
答案1
得分: 0
有时事情相当容易... Mike 的帖子中的第一个提示之一是仅仅在调试器中暂停这个东西,然后查看当前线程的位置,经过搜索超过100个子线程后,我发现一个在开发时无意中附加到另一行的“隐藏”休眠,之间有几个制表符,导致它出现在我的视图窗口的最右侧。感谢,Mike,提供这个链接
英文:
sometimes things are quite easy ... one of the first hints in Mike's post was to just pause the thing in debugger and look where the threads are currently and after searching through over 100 subtreads, I discovered a "hidden" sleep from development time, that was accidentally appended to another line with several tabs inbetween causing it to be far right of my viewing window.
Thanks, Mike, for this link
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论