一个tuxedo应用系统的整体性能往往是由很多方面决定的，操作系统、网络、数据库、以及应用系统的设计，程序的编写水平都会影响该tuxedo应用系统的性能。当性能不好时,主要表现在对客户段的请求响应很慢。这时，如果用tmadmin,中的pq命令察看，会发现有较多的请求在排队。

如何确认应用程序的瓶颈是性能调优的关键，也是难点。对于一个程序，如果可以知道每个函数的调用次数，调用时间，无疑会指引系统调优的方向。本文将介绍如何使用gprof查看tuxedo服务进程的函数调用情况，包括调用次数、调用时间、函数调用关系图等等。

gprof是GNU profiler工具。基本用法如下：

1. 使用-pg选项编译和链接你的应用程序。
2. 执行你的应用程序，使之运行完成后生成供gprof分析的数据文件（默认是gmon.out）。
3. 使用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文件。如果你的程序是一个不会退出的服务程序，那就只有修改代码来达到目的。如果不想改变程序的运行方式，可以添加一个信号处理函数解决问题（这样对代码修改最少），例如：

当使用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文件了。

--转自