一个tuxedo应用系统的整体性能往往是由很多方面决定的,操作系统、网络、数据库、以及应用系统的设计,程序的编写水平都会影响该tuxedo应用系统的性能。当性能不好时,主要表现在对客户段的请求响应很慢。这时,如果用tmadmin,中的pq命令察看,会发现有较多的请求在排队。
如何确认应用程序的瓶颈是性能调优的关键,也是难点。对于一个程序,如果可以知道每个函数的调用次数,调用时间,无疑会指引系统调优的方向。本文将介绍如何使用gprof查看tuxedo服务进程的函数调用情况,包括调用次数、调用时间、函数调用关系图等等。
gprof是GNU profiler工具。基本用法如下:
- 使用-pg选项编译和链接你的应用程序。
- 执行你的应用程序,使之运行完成后生成供gprof分析的数据文件(默认是gmon.out)。
- 使用gprof程序分析你的应用程序生成的数据,例如:gporf a.out gmon.out。
关于gprof的详细用法可以google、百度之,有很多信息,这里不再赘述。
对于一个tuxedo程序,一般会编写很多.cpp文件,生成相应的.o文件,最后使用buildserver命令生成可执行文件。你会想在编译.cpp文件产生.o文件时,为编译器(系统为linux环境,编译器为gcc)提供-pg选项,再使用buildserver,但在tmshutdown服务进程之后,并没有发现gmon.out文件产生。为什么?
原来gprof只能在程序正常结束退出之后才能生成程序测评报告,原因是gprof通过在atexit()里注册一个函数来产生结果信息,任何非正常退出都不会执行atexit()的动作,所以不会产生gmon.out文件。如果你的程序是一个不会退出的服务程序,那就只有修改代码来达到目的。如果不想改变程序的运行方式,可以添加一个信号处理函数解决问题(这样对代码修改最少),例如:
1 #include <unistd.h>
2 #include <signal.h>
3 4staticvoid catch_term(int sig_no) 5{ 6 exit(0); 7} 8 9int main() 10{ 11 signal(SIGTERM, catch_term); 12//以下是原来的代码 13 }
当使用kill –TERM pid 后,程序退出,生成gmon.out文件。
问题又来了,在tuxedo程序中,你只编写了应用服务的代码,并没有编写main函数,也就是说,buildserver命令在编译时对你的代码做了一些手脚,查看buildserver帮助文档,可以看到使用-v选项可以详细显示buildserver的编译过程,使用这个选项可以容易看出buildserver实际上使用gcc来生成可执行文件,并添加了tuxedo相应的链接库,而且可以看到一个你没写过的***.c,编译之后,这个***.c文件却消失了。
问题就在这,这个***.c文件中包含着main函数,buildserver使用-k选项可以保留这个***.c文件而不被删除。在生成***.c后,按上面的方法注册一个TERM信号处理方法。此时不再用buildserver生成可执行文件,而是使用buildserver –v实际调用gcc的命令来生成可执行文件。
当你使用tmshutdown –s server –k TERM(使用TERM信号结束程序),还是没有产出gmon.out,原因是在链接时gcc没有使用–pg选项;使用-pg选项重新编译链接程序,启动、结束服务程序后,终于看到久违的gmon.out文件了。
--转自