1. 应用服务器宕机后，为了方便分析问题，需要收集哪些日志？ 答： 当应用服务器发生挂起、或者发生out-of-menmory的现象时，为了更好的全面分析问题，则需要收集一定的日志信息，一般情况下我们需要收集以下这些日志：
- 如果可能在问题重新出现之前打开垃圾回收开关，收集垃圾回收日志一般存储在native_stderr.log或者native_stdout.log。
- 收集Web server服务器，插件Plug-in（plugin-cfg.xml and http_plugin.log）的日志及配置文件。以及应用服务器（install_root/profiles/profile_name/logs/server_name）下所有的日志。
- 在install_root/profiles/profile_name/目录下的JavaCore文件和Heapdump文件，如果没有这些文件，可以在服务器没有响应的时候，运行命令来生成这些文件，对于IBM JDK中可以运行kill -3 PID_Java_jvm，然后每隔两分钟，重复执行该命令，至少3次，通过该命令生成的JavaCore文件会在install_root/ profiles目录下。
- FFDC目录下的日志，install_root/profiles/profile_name/logs/ffdc。
- 如果应用程序具有自身的日志文件，也应收集对应的日志文件。
2. 如何打开详细垃圾回收的开关？ 答： 如果您的应用程序频繁出现内存溢出（out-of-memory）的错误现象，那么为了找出问题的所在，我们必须了解内存的分配情况和使用情况，那么这时候我们就需要详细垃圾回收的信息和日志，为了得到这些信息，我们必须打开详细垃圾回收的开关。打开的步骤如下：在管理控制台中点击服务器 > 应用服务器 > server1（或者是您自己定义服务器名） > JAVA和进程管理 > 进程定义 > Java虚拟机 > 选中详细垃圾回收选项，重启应用服务器，即可生效。打开垃圾回收开关后，关于内存的使用情况的日志会存储到相应的日志目录中的native_stdout.log文件中，并且可以通过分析该文件中的信息快速的找到产生问题的根源。
3. WAS 故障诊断的常用工具有哪些？ 答： 故障诊断是查找并除去问题的起因的过程。一旦您发现 WebSphere 运行环境有问题，故障诊断过程就开始。WebSphere 的基本故障诊断策略包括：
(
1). 记录症状 根据您的应用程序、服务器或是工具中出现的问题的类型，您可能接收到表明出现问题的消息。通过记录每条消息的详细信息，您就会对定位问题的所在了解更多。
(2). 重新创建问题 如果您一直有可重复的测试用例，则您可以很方便地确定哪些解决方案是必需的。
(3). 除去可能的起因 通过排除那些不是导致问题的组件以缩小问题的范围，您可以使问题简单化，并且避免浪费时间。
(4). 使用诊断工具 WebSphere Application Server 提供了一些帮助管理员以及开发者进行故障诊断的工具和资源，合理的利用这些工具和资源，当 WebSphere Application Server 出现故障的时候，可以帮助我们准确的定位问题的所在。
以下介绍了如何收集故障诊断的资源：
确定 WebSphere 产品安装信息： 可以执行 versionInfo 命令。
确定 JDK 的版本信息： 通过从命令行运行 java -fullversion
确定 Web 服务器的版本信息： 检查 Windows 平台上的IBM HTTP Server的版本信息，可以运行 apache.exe -v。检查 Unxi 和 Linux 平台上的 IBM HTTP Server 的版本信息，可以运行 httpd -v。
管理控制台消息： 管理控制台提供了一些重要的关于 WAS 运行时事件以及配置问题的信息。在管理控制台中的故障诊断中显示了运行状态的消息，您可以查看配置问题的消息以及运行时消息。通常运行时事件的错误信息页包含了重要信息。
使用日志文件： WebSphere Application Server 可以将系统消息写到几个通用日志中，包括 JVM 日志、进程日志和 IBM 服务日志。
使用跟踪： 跟踪文件显示 WebSphere Application Server 基本类调用的方法的时间和顺序，您可使用这些文件来查明故障。
WebSphere Application Server 中的故障诊断工具包括：日志分析器、收集器工具、首个故障数据捕捉（First Failure Data Capture,FFDC）、IBM Support Assistant 等。
日志分析器： Log Analyzer是一个图形化的工具，用来帮助用户查看、分析日志。
收集器工具： 收集器工具收集 WebSphere Application Server 安装信息，并将它打包后放在 Java 归档（JAR）文件中,您可将该文件发送给 IBM 客户支持人员以辅助确定和分析您的问题。JAR 文件的信息包括日志、属性文件、配置文件、操作系统和 Java 数据以及存在的每个必备软件及其级别。
首个故障数据捕捉（First Failure Data Capture,FFDC）： 首个故障数据捕捉工具保存由处理故障生成的信息，并将控制权返回受影响的引擎。捕捉到的数据保存在日志文件中，以供分析问题时使用。
IBM Support Assistant： IBM Support Assistant 是一个工具，它可帮助您使用 WebSphere Application Server 管理控制台中的各种 IBM Support 资源。
有关具体如何使用这些工具的更多资源，请参阅 developerWorks 中国站点的文章 与 。
4.问题：我应该使用数据库还是使用内存到内存复制来进行会话故障转移？ 答： 数据库持久化和内存到内存复制之间的性能差异并不大。这是因为 95% 的复制或持久化会话开销是在会话对象的序列化/反序列化中产生的——不论会话保存在哪里，这种开销都必定会产生。另外，当会话对象的大小增加时，性能就会下降——再强调一遍，两种会话分布方式的性能大致相同。
在 IBM WebSphere: Deployment and Advanced Configuration 中，我这样写道：
相反，决定选择哪种技术将部分基于这两种技术之间的差异： 通过使用数据库，您实际上持久化了数据（保存到磁盘中），这样高可用性的数据库服务器就可以在级联故障中幸免于难，而将应用服务器用作会话存储和复制器则无法达到此目的。 对于“黄金标准”（两个相同的单元/域），高可用性的数据库完全可以确保两个域之间的会话故障转移，而对于内存到内存复制，两个单元只能有一个通用复制器；因此，它就变为单点故障 (SPOF)。 因此，对于必须进行交叉单元会话故障转移的配置，只能选择高可用性数据库来消除 SPOF。请注意，此时跨单元共享会话是得到支持的，但不建议这样做，因为在单元间共享状态将使得在两个单元中独立升级组件（应用程序和 WAS）异常困难。最后，您的决定要基于您最喜欢使用的技术以及哪种技术可以提供所需的服务质量来满足可用性要求。
在此，我想谈一下我的另一个观点。利用内存到内存复制，您可以存储的会话信息的数量受应用服务器的 JVM 堆大小的限制。即使在 WebSphere Application Server V6.01 中支持 64 位的 JVM，最大应用服务器堆大小也大大小于数据库服务器（用作会话存储）上可用的磁盘空间数量。因此，尽管我知道在许多组织中，使用内存到内存复制对避免系统管理员和数据库管理员之间的角色和职责冲突更有利，但我仍持这样一种观点，即数据库持久化仍是最佳选择。
本答案，来自
IBM WebSphere 开发者技术期刊中的
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-375007/，如需转载，请注明出处，否则将追究法律责任。