举例来说，假设进程号（pid）为27260。

如果我们想知道哪个终端启动了服务器以及该终端是不是远程的，该怎么办？进入/proc/fd目录，其中包含该进程所使用的文件描述符列表。现在使用列表命令（ls -l）列出fd 0（标准输入设备），则会列出实际所用的设备。在本例中是/dev/pts/6。还可利用Linux的who命令查看登录该设备的用户及其IP地址。

> cd /proc/27260/fd

> ls -l 0 lrwx------ 1 root root 64 Nov 20 14:21 0 -> /dev/pts/6

>who

weblogic pts/6 Nov 20 10:55 (192.168.1.105)

也可显示startup命令和该进程正在使用的环境变量。对于想要跟踪某个功能选项是否已经通过脚本传递给了进程，此项操作尤为有用。

另外一个很有用的技巧可用来确定该进程正在使用哪些文件。显示maps文件（cat maps），此命令显示已经打开的文件。一个例子用例是确定某个JAR文件是否已加载以及它是从什么目录加载而来的。

> grep trader.jar maps

/opt/bea/weblogic81/samples/domains/examples/examplesServer/stage/

_appsdir_webservices_trader_ear/trader.jar

调优考虑

当应用程序进入产品阶段很短时间后（3-6个月），操作系统、应用程序以及任何触点都应该调优--或者至少应该重新检查一下配置参数以确保它们还是适当的。这是对环境及其触点进行持续衡量的好处之一。如果没有针对关键的参数进行持续衡量，那么这种衡量将是徒劳的。

有时，当工作负载发生了变化时，调优是很必要的。当更新的代码或设计已经迁移到产品中之后，或者应用程序现在支持一个更大的用户群，那么调优可能会较为复杂。无论何种原因，对应用程序的调优需要小心谨慎地进行确认，在大多数情况下，只有性能监控人员才能对整个应用程序施加影响。首先，在操作系统级启动，并依次通过不同的堆栈。查看当前性能标准，并使用诸如Transaction Tracer的工具快速显示哪些组件占用一个给定请求中的大部分处理时间。

查看操作系统所报告的各时间段内的平均负载、可运行任务，以及磁盘交换活动进行检查。如果磁盘活动只是在一个设备上进行，请考虑是否是文件重 向的问题。或许并行进程的数量已增加（同一台机器上的附加实例）。如果平均负载很重或可运行任务数很多，那么检查一下是什么别的进程在竞争系统的资源。将若干应用程序实例部署到各个独立的机器上可把工作负载分配到多台机器上，这样就可以降低单个机器的资源占用率。

当调优JVM时，要查看一下内存的使用率和所使用垃圾收集方案。JVM调优文档 http://edocs.bea.com/wljrockit/docs81/tunelnux是一个很好的资源，概要列出了可用的垃圾收集和线程选项。WebLogic应用程序本身也必须检查。文章"Tuning WebLogicServer"http://edocs.bea.com/wls/docs81/perform/WLSTuning.html是很好的入门资料。接下来，利用所收集的数据来验证性能。

检查WebLogic内部的执行队列和线程池。有没有正在等待处理的请求？在JDBC内部，是否有足够的可用连接用于轮询处理预期的工作负载，同时不会造成超限分配。

参考资料

与供应商谈论您的部署方案。他们通常了解问题的多种解决方案并常常能根据他们的经验给出具有洞察力的意见。以下的网站在对在Linux上部署WebLogic会有所帮助：

· www.wilytech.com

· CLICK!!

· http://e-docs.bea.com

总结

希望此文为您提供了有关BEA WebLogic产品以及在您的环境中对Linux进行部署的背景资料。应用程序服务器处理的快慢取决于WebLogic接收请求以及从后端检索数据的速度，所以，调优是很关键的。

我们概要列出的触点和调优考虑只是一个起点。

您的应用程序及环境会存在其他的触点。但请记住，在部署Linux和BEA WebLogic方面，您并不寂寞。

Linux部署问题分析

使用诸如Wily's Introscope的性能监控工具，可以捕获并在永久存储介质上记录应用程序以及构成整个应用程序的其他环境组件的性能参数。

使用Introscope和诸如环境性能代理软件（Environment Performance Agent，EPA）这样的Introscope特性（特别设计用于收集非Java触点的性能参数），可以得到操作环境的一个"整个应用程序"视图。例如，可以利用Introscope EPA来收集最关键的操作系统级数据和Web服务器数据，可以用Introscope收集有关J2EE应用程序的数据，而后，将以上的数据相结合并在面板上显示。此数据随后可被转化为性能参数，并可被Introscope用来提供一个应用程序整体性能的视图。

Introscope Transaction Tracer（Introscope事务跟踪器）这样的工具使您能够为分析捕获基线以外的请求，或者能够创建警报以通知潜在领域的支持人员进行检查。这是用来解决运行时问题的方法之一。 Introscope LeakHunter也可用来跟踪应用程序中的潜在内存泄漏。如果存在内存泄漏，则可给出类名、方法及其大小，以便于程序员对问题进行修改。

使用Introscope，可在产品部署前为公司中不同的支持团队创建不同的面板，以便在生产阶段出现问题时，团队成员就已经从应用程序服务器和支持系统获得了数据，这样，就更有利于问题的解决。

使用Introscope EPA，可以收集Linux的实时性能数据并用于监控和报警。如果将这些数据与用Introscope从BEA WebLogic所收集的数据相结合，一个关于应用程序及其所有支持系统的图像就会完整地呈现在我们眼前（见图1）。

作者简介

Eric Gudgion是Wily Technology公司的一位专业的服务工程师。他有19年以上的计算领域的工作经验，涉及大多数的商用计算机环境。他的大多数时间花在操作系统、网络、应用程序服务器以及性能调试产品方面。