测量使用预编译库的程序的总 CPU 时间（C++、Linux）
我目前遇到了这个问题，我很想听听您的一些建议。
我有一个 C++ 程序，它使用预编译库对 PostgreSQL 数据库进行一些查询。现在的问题是我想找出执行程序源代码中描述的所有例程所需的总（组合）CPU 时间以及等待与数据库相关的活动所花费的时间。
我在Linux中使用了time命令，但它似乎没有测量程序在数据库上花费的时间。
在我的情况下，我不可能重新编译提供给我的库，所以我认为像 gprof 这样的东西不会起作用。
有什么建议吗？
谢谢。
I am currently stumbled into this problem and I'd love to hear some suggestions from you.
I have a C++ program that uses a precompiled library to make some queries to PostgreSQL database. Now the problem is I want to find out the total (combined) cpu time it takes to do all routines described in the source code of the program and also the time it spends waiting for the database-related activities.
I used the time command in Linux, but it seems that it didn't measure the time the program spent on the database.
And in my situation, it won't be possible for me to recompile the library provided to me, so I don't think things like gprof would work.
Any suggestions?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
尝试一下ctime中的时钟功能。
Try the clock function in ctime.
使用 POSIX 的 times，它测量进程的真实时间、用户时间和系统时间和它的孩子。
链接的 Opengroup 页面上有一个示例：“计时数据库查找”
Use POSIX's times, it measures real, user and system time of a process and its children.
There is an example on the linked Opengroup page: "Timing a Database Lookup"
当然，无论如何您都会获得挂钟时间，但大概您正在尝试获得 CPU 时间。
当涉及子流程（或不相关的流程）时，这很重要。但是，您可能希望尝试采用更全面的基准测试方法。
测量应用程序的延迟很容易（只需观察挂钟），但吞吐量通常比较困难。
要了解应用程序在负载下的行为方式，您需要以可重现的方式将其置于负载下（在生产级硬件上）。
这通常意味着同时执行大量任务，因为现代硬件往往能够同时执行多项任务。此外，如果您的应用程序中的任何内容曾经等待任何外部数据源（可能包括您自己计算机的硬盘驱动器），那么即使在单核上，您也可以通过同时处理多个请求来获得更好的吞吐量。
您可能需要查看像 oprofile 这样的工具，它是为分析而不是基准测试而设计的。
Of course you'll get the wall-clock time anyway, but presumably you're trying to get the CPU time.
This is nontrivial when you have subprocesses (or unrelated processes) involved. However, you may want to try to have a more holistic approach to benchmarking.
Measuring the latency of an application is easy enough (just watch the wall-clock) but throughput is generally harder.
To get an idea of how an application behaves under load, you need to put it under load (on production-grade hardware), in a reproducible way.
This normally means hitting it with lots of tasks concurrently, as modern hardware tends to be able to do several things at once. Moreover, if anything in your app ever waits for any external data source (including the hard drive of your own machine potentially), you can get better throughput even on a single core by having multiple requests being served at once.
You may want to look at tools like oprofile, which is designed for profiling, not benchmarking.
您可以打开
log_statement和log_duration并在postgresql.conf中设置log_min_duration_statement=0，运行您的程序，然后然后使用 PQA 等分析 Postgres 日志。You can turn on
log_statementandlog_durationand setlog_min_duration_statement=0inpostgresql.conf, run your program, and then analyze Postgres logs using for example PQA.