监控优化板块建设意见全面征集
Websphere监控优化板块在经历一段时间的沉默后，准备以新的面貌重新与大家见面。
在以往的经验中，监控优化、问题诊断、工具分析等内容是大家最为关注的东西，但一般都存在这样两个问题。
1、专家给出建设性意见，但是我们还是无法解决问题
2、很多问题，无法解决，可能生产环境太复杂，包括的软件过多。
由于这些原因，导致我们很多人都无法从中获益，当然这其中或多或少都存在着一些客观和主观原因，因为性能监控调优，问题诊断属于综合性知识，不仅和应用服务器有关，还和数据库，代码，第三方程序等相互关联，那么这些因素是我们分析问题必不可少的组成部分。监控优化板块为了能够更好的为大家服务，特在此想大家全面征集对于监控优化板块的意见，主要包括
1、各位想得到什么样的服务，以便更好的帮助大家提升能力和解决问题
2、各位期待的监控优化板块是什么样子的
3、各位希望在监控优化板块中看到什么样的内容
活动奖励：每位发表建议的会员，均可得到 5W币，建议一经被采用，均可得到20W币
活动宣言：让我们共同提高，您的意见就是我为之奋斗的目标！
在以往的经验中，监控优化、问题诊断、工具分析等内容是大家最为关注的东西，但一般都存在这样两个问题。
1、专家给出建设性意见，但是我们还是无法解决问题
2、很多问题，无法解决，可能生产环境太复杂，包括的软件过多。
由于这些原因，导致我们很多人都无法从中获益，当然这其中或多或少都存在着一些客观和主观原因，因为性能监控调优，问题诊断属于综合性知识，不仅和应用服务器有关，还和数据库，代码，第三方程序等相互关联，那么这些因素是我们分析问题必不可少的组成部分。监控优化板块为了能够更好的为大家服务，特在此想大家全面征集对于监控优化板块的意见，主要包括
1、各位想得到什么样的服务，以便更好的帮助大家提升能力和解决问题
2、各位期待的监控优化板块是什么样子的
3、各位希望在监控优化板块中看到什么样的内容
活动奖励：每位发表建议的会员，均可得到 5W币，建议一经被采用，均可得到20W币
活动宣言：让我们共同提高，您的意见就是我为之奋斗的目标！
45同行回答
日志分析工具，coredump文件分析工具收起
浏览1019
性能监控优化部分可以分为：
1、性能工具专栏：
主要包含性能测试工具（LR）、性能监控工具（Jconsole）以及性能分析工具（Jprofiler）或其他工具等。
2、性能分析专栏；
主要针对JVM、系统资源、程序、日志等进行剖析说明
3、性能优化专栏
主要针对相关问题提供常见调优配置参考及说明
4、性能实例分析
针对某一实例（最好是）进行分析说明、指出分析思路及方法。
以上仅个人建议！收起
1、性能工具专栏：
主要包含性能测试工具（LR）、性能监控工具（Jconsole）以及性能分析工具（Jprofiler）或其他工具等。
2、性能分析专栏；
主要针对JVM、系统资源、程序、日志等进行剖析说明
3、性能优化专栏
主要针对相关问题提供常见调优配置参考及说明
4、性能实例分析
针对某一实例（最好是）进行分析说明、指出分析思路及方法。
以上仅个人建议！收起
浏览1021
大家都说如何如何调优，我倒觉得与其调优，不如做好基础。
我用了5年的weblogic才转到was上的，现在在WAS上又打滚了将近5年，回头想想，总结如下：
先介绍一下目前支持运营业务系统，PB+JAVA+ORACLE的标准三层架构，订单日均2万，销售额日均1300万左右，终端约2000人在线，业务高峰集中，7*24小时运营。
先说CLIENT这端，pb是个古老的东西，估计很多人都早已不记得了，但数据窗口确实是个好东西，尤其是对付报表。pb写的界面基本不含逻辑，做一些简单的数据校验，逻辑检核，之后通过自定义的DLL传给中间件，返回结果进行界面装载展现，功能简单通用，无需多解释。
中间件是WAS-ND版，用的SERVLET容器，没有EJB,没有JMS等，中间件分两个层面，一个层面是负责业务逻辑处理(当然含必要的数据检核)，一个层面是数据持久化，持久化直接用sql实现的，没有Hibernate，ibatis之类的“高级”数据持久化映射，第三方包用得很少，基本就用了个AXIS来做webservices，ORACLE jdbc等少数几个。
WAS是双机负载，IHS分发，优化只做了最基本的，IHS线程数修正,JVM修正，连接池修正，WEB容器修正。
数据库用的是ORACLE 10G,RAC环境，dataguard灾备，每天数据增长量在1G左右。
基础环境也就这些了，介绍完毕。
因为早已习惯了weblogic的代码编写方式，大对象，对象销毁什么的全然不在乎，想着两者都是商业型的中间件，应该大同小异，等采购回来拿到介质，找了两台高档服务器(毕竟是核心运营系统，不敢怠慢)，装上LINUX就开始部署了，来回折腾，前后共计重新安装不下15次(不是没装好，是因为想多熟悉，所以这么折腾)，搞定收工，部署完代码就开跑（呵呵，实际过程肯定要复杂得多，此处省略字数若干）。
正所谓不试不知道，一试吓一跳，首先遇到的就是补丁问题，时常报一些莫名其妙的错误，GOOGLE看看，问问厂家，才知道是补丁的问题，于是下了对应比较稳定度补丁这才算告一段落。
接下来就是著名的OOM，一天给你宕两次机，连大老板都站在你后面看你操作重启，那个惭愧啊，不言而喻，弄个HEAPDUMP文件分析器一看，大对象，1M左右，遂咒骂，NND啥破玩意，这么点屁大的对象都不支持，weblogic这么点大的对象就像塞牙缝(夸张点，呵呵)，当时的想法就是这玩意咋连TOMCAT都较不过呢？
骂归骂，问题总是要解决，总不能跟老板说咱们还是换个中间件吧(尽管这样可以，但俺丢不起这个脸啊)，于是查对象来源，原来是大数据集中返回CLIENT的时候出的问题，分页机制不对，问题查出来了，那就好办了，一个个的代码进行检核那无疑是一场梦魇，想了个法子，在框架上限值一下,在servlet打包返回CLIENT之前，大于多少行的数据就直接销毁掉，反对应的错误信息去前台，这样一点一点的改善需要分页的地方，最终无碍。
可好日子没过多久，死灰复燃了，又宕了，简直哭死，一看GC，问题在代码里，很多废弃的对象没有手动回收，io流打开了没关闭等诸于此类，反正都是些低级错误，于是，发动兄弟姐妹互相检核代码，再者找一些findbug之类的工具找出这些个虫子来一个一个的灭掉。
遂安稳。
当然，这些过程中还遇到了很多其他的问题，在此就不一一列举出来了。
总结一下这么多年应该有这么几点吧
1.技术和产品无所谓好与不好，关键看你怎么用。
2.根据你的需要和现状选择你的产品。
3.尽量少用第三方的东西，出问题时候那简直是噩梦来袭。
4.能自己写的东西尽量自己写，多把过程控制在自己的手里，虽然这样费劲点。
现在的企业，信息化建设正可谓是蒸蒸日上，大量的系统建设过程中应该充分考虑整体架构及其布局，尽量做技术及产品的整合，这样在后续的过程中可以节省很多精力。
这些年也用了WEBSPHERE产品线的很多东西，MQ,MB,ILOG,COGONOS等，说实在的，都会遇到调优的问题，不过我仍然建议从基础做起，还是那句，与其调优，不如做好基础，代码的功底其实是非常重要的一环。收起
我用了5年的weblogic才转到was上的，现在在WAS上又打滚了将近5年，回头想想，总结如下：
先介绍一下目前支持运营业务系统，PB+JAVA+ORACLE的标准三层架构，订单日均2万，销售额日均1300万左右，终端约2000人在线，业务高峰集中，7*24小时运营。
先说CLIENT这端，pb是个古老的东西，估计很多人都早已不记得了，但数据窗口确实是个好东西，尤其是对付报表。pb写的界面基本不含逻辑，做一些简单的数据校验，逻辑检核，之后通过自定义的DLL传给中间件，返回结果进行界面装载展现，功能简单通用，无需多解释。
中间件是WAS-ND版，用的SERVLET容器，没有EJB,没有JMS等，中间件分两个层面，一个层面是负责业务逻辑处理(当然含必要的数据检核)，一个层面是数据持久化，持久化直接用sql实现的，没有Hibernate，ibatis之类的“高级”数据持久化映射，第三方包用得很少，基本就用了个AXIS来做webservices，ORACLE jdbc等少数几个。
WAS是双机负载，IHS分发，优化只做了最基本的，IHS线程数修正,JVM修正，连接池修正，WEB容器修正。
数据库用的是ORACLE 10G,RAC环境，dataguard灾备，每天数据增长量在1G左右。
基础环境也就这些了，介绍完毕。
因为早已习惯了weblogic的代码编写方式，大对象，对象销毁什么的全然不在乎，想着两者都是商业型的中间件，应该大同小异，等采购回来拿到介质，找了两台高档服务器(毕竟是核心运营系统，不敢怠慢)，装上LINUX就开始部署了，来回折腾，前后共计重新安装不下15次(不是没装好，是因为想多熟悉，所以这么折腾)，搞定收工，部署完代码就开跑（呵呵，实际过程肯定要复杂得多，此处省略字数若干）。
正所谓不试不知道，一试吓一跳，首先遇到的就是补丁问题，时常报一些莫名其妙的错误，GOOGLE看看，问问厂家，才知道是补丁的问题，于是下了对应比较稳定度补丁这才算告一段落。
接下来就是著名的OOM，一天给你宕两次机，连大老板都站在你后面看你操作重启，那个惭愧啊，不言而喻，弄个HEAPDUMP文件分析器一看，大对象，1M左右，遂咒骂，NND啥破玩意，这么点屁大的对象都不支持，weblogic这么点大的对象就像塞牙缝(夸张点，呵呵)，当时的想法就是这玩意咋连TOMCAT都较不过呢？
骂归骂，问题总是要解决，总不能跟老板说咱们还是换个中间件吧(尽管这样可以，但俺丢不起这个脸啊)，于是查对象来源，原来是大数据集中返回CLIENT的时候出的问题，分页机制不对，问题查出来了，那就好办了，一个个的代码进行检核那无疑是一场梦魇，想了个法子，在框架上限值一下,在servlet打包返回CLIENT之前，大于多少行的数据就直接销毁掉，反对应的错误信息去前台，这样一点一点的改善需要分页的地方，最终无碍。
可好日子没过多久，死灰复燃了，又宕了，简直哭死，一看GC，问题在代码里，很多废弃的对象没有手动回收，io流打开了没关闭等诸于此类，反正都是些低级错误，于是，发动兄弟姐妹互相检核代码，再者找一些findbug之类的工具找出这些个虫子来一个一个的灭掉。
遂安稳。
当然，这些过程中还遇到了很多其他的问题，在此就不一一列举出来了。
总结一下这么多年应该有这么几点吧
1.技术和产品无所谓好与不好，关键看你怎么用。
2.根据你的需要和现状选择你的产品。
3.尽量少用第三方的东西，出问题时候那简直是噩梦来袭。
4.能自己写的东西尽量自己写，多把过程控制在自己的手里，虽然这样费劲点。
现在的企业，信息化建设正可谓是蒸蒸日上，大量的系统建设过程中应该充分考虑整体架构及其布局，尽量做技术及产品的整合，这样在后续的过程中可以节省很多精力。
这些年也用了WEBSPHERE产品线的很多东西，MQ,MB,ILOG,COGONOS等，说实在的，都会遇到调优的问题，不过我仍然建议从基础做起，还是那句，与其调优，不如做好基础，代码的功底其实是非常重要的一环。收起
浏览1048
工具的使用和监控结果需采取处理办法监控工具，日志分析工具，coredump文件分析工具收起
浏览1040
附件最好是一两个，太多了不方便下载收起
浏览1012