如何查看core文件是如何产生的

1.用gdb打开core文件来确定。如下例子：

[plain] view plain copy

[xuzhina@localhost ~]$ ls

asm.listDesktopDownloads Pictures Templates vmtoolsd

core.22625 Documents Music PublicVideos vmtoolsd.tar.gz

[xuzhina@localhost ~]$ ls core.22625

core.22625

[xuzhina@localhost ~]$ gdb -c core.22625

GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-51.el7

Copyright (C) 2013 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-redhat-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

[New LWP 22625]

[New LWP 22680]

Core was generated by `/usr/lib/vmware-tools/sbin64/vmtoolsd -n vmusr --blockFd 3'.

Program terminated with signal 11, Segmentation fault.

#0 0x0000000000000000 in ?? ()

(gdb)

2.用file命令来确定，如下例子：

[plain] view plain copy

[xuzhina@localhost ~]$ ls -l core.22625

-rw-------. 1 xuzhina xuzhina 16257024 Sep 5 23:50 core.22625

[xuzhina@localhost ~]$ file core.22625

core.22625: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/usr/lib/vmware-tools/sbin64/vmtoolsd -n vmusr --blockFd 3'

一、对外表现

1.应用访问速度慢、应用报错(WAS性能差)

2.应用(server)停止对外服务无法访问(WAS服务挂起或者服务器宕机)

二、xxx系统我们发现过的问题

1.WAS内存处理大对象内存分配bug(大报文(20M)-小报文(20M)-20M)

2.内存回收碎片(java heap free memory很多，一个很小的报文都申请不到内存)

3.WAS MDB侦听MQ队列问题

三、排查思路

思路：

1.查看收集服务器性能指标，内存使用、CPU使用包括磁盘I/O等。

2.查看收集 *** 作系统级日志。

3.根据服务器的性能指标以及 *** 作系统级日志，基本定位是否存在影响性能的瓶颈，通过排除那些不是导致问题发生的因素，以缩小问题的范围，可以使问题简单化，并且避免浪费时间。举例：

CPU使用不高，用户感觉交易响应时间很长，可以断定是由于系统的某一小部分造成了瓶颈，导致了所有的请求都在等待。我们可以考虑，线程池的数量开的太小，导致所有的请求都在排队等待进入线程池，因为没有可用的线程使用，所以这个交易请求一直在排队，导致交易响应时间很长。数据库连接池开的太小，也会有同样的表现。

CPU使用很高，用户感觉交易响应时间很长，比较复杂。可能的根源之一是硬件资源不够。 根源之二是应用系统中产生了多个大对象。根源之三是程序算法有问题。 解决思路如下：用性能分析器, 对运行环境进行分析，分析哪个类甚至于哪个函数消耗了这么多的CPU，并找到相应的解决方案。

4.收集分析WAS日志

当应用服务器发生挂起、或者发生out-of-memory等现象时，为了更好的全面分析问题，则需要收集一定的日志信息，一般情况下我们需要收集以下这些日志：

1)收集垃圾回收日志native_stderr.log或者native_stdout.log。

2)收集应用服务器(install_root/profiles/profile_name/logs/server_name)下所有的日志(systemout)。

3)收集install_root/profiles/profile_name/目录下的JavaCore文件和Heapdump文件，如果没有这些文件，可以在服务器没有响应的时候，运行命令来生成这些文件，对于IBM JDK中可以运行kill -3 PID_Java_jvm，然后每隔两分钟，重复执行该命令，至少3次，通过该命令生成的JavaCore文件会在install_root/ profiles目录下。

4)收集首个故障数据捕捉日志/logs/ffdc。

5)收集Web server服务器，插件Plug-in(plugin-cfg.xml and http_plugin.log)的日志及配置文件。

6)如果应用程序具有自身的日志文件，也应收集对应的日志文件。

5.应用分析工具基本定位问题

1)使用WAS自带工具分析(管理控制台的故障诊断、日志分析器等)。

2)使用其他分析工具，可分析对象报错相关日志文件以及java core ,heap dump文件等(GC、DUMP)。

6.确定问题所在找出解决问题办法

7.重现场景，进行相关测试(包括升级新的补丁程序、调整参数、修改应用等)

was性能调优

部署在WAS上的J2EE应用程序，其性能是由多个因素决定的。比如网络、数据库、内存分配、WAS服务器的配置以及应用程序的设计。对于一个标准的J2EE应用，一个请求到来时，往往需要经过多次转发：网络 >Web服务器Web容器 >EJB容器 >数据库。而每一次转发，都可能造成请求处理的瓶颈，使得应用程序整体性能下降。我们把每一次转发的待处理资源都看成一个队列

调优的基本步骤如下：

1)设置的是Web Server的最大并发用户：

这个设置是在conf/httpd.conf这个文件里面配置的。在Unix系统中，对应的属性是MaxClient。

2)设置Web Container的最大、最小并发用户：

在管理控制台中点击应用程序服务器 >server1 >线程池 >WebContainer，根据测试性能情况和应用情况输入合适的最小、最大进程数。

3)对象请求代理(ORB)的线程池大小：

在管理控制台中点击应用程序服务器 >server1 >ORB 服务 >线程池，根据测试性能情况和应用情况输入合适的最小、最大进程数。

4)设置数据库的连接池属性：

JDBC 提供者 >数据库JDBC驱动名称 >数据源 >数据源名称>连接池 ，根据测试性能情况和应用情况输入合适的最小、最大连接数。

5)JVM堆参数设置的性能调优：

应用程序服务器 >server1 >进程定义 >Java 虚拟机，根据硬件物理内存和应用情况输入合适的初始堆大小、最大堆大小。

(XX系统)K值调整针对WAS内存碎片问题IBM建议值：－Xk30000 －Xk24000,2400k (core dump抛出建议值)

6)ORB参数调用方式的性能调优：

应用程序服务器 >server1 >ORB 服务>选中按引用传递。

当时 java 启动的当前目录 ，比如你在桌面上双击快捷方式，那么它就在快捷方式中所指定的”运行目录”下。

你也可以把 System.getProperties() 打印出来，里面提到了好几个目录 。

---