聚沙成塔-小哈的记事薄

之前看的很多was优化案例，包括自己实施过程中都只从WebSphere的角度来考虑问题，虽然WAS的优化中包括了操作系统层面的优化，比如对AIX、HPUX的系统参数做出调整，对于网络tcp的参数做出改动，但并没有更进一步，在进行LPAR分区前就做出完整的规划。

WebSphere管理员和硬件与操作系统管理员往往交流不多，且是串行的实施顺序。虽说也就那么做下来了，但是是否充分发挥了硬件的资源，是否达到了最好的性能，最稳定的运行，还是可以有改进的余地？都值得探讨。IBM网站上这三篇文章可谓打通了两种管理员之间的任督二脉，看懂了总有好处。

本书提供了整体系统观点，重点关注在 Power System 和 AIX 上运行 WebSphere Application Server 负载的环境的端到端系统部署、调优和管理方法。因而，本书为两类截然不同的技术读者架起了一座桥梁，也就是硬件和操作系统管理员与 WebSphere Application Server 应用软件工程师。我们都了解，在典型的企业环境中，这两类技术读者需要密切合作，但仍然有着不同的视角和职责。然而，对于企业来说，在度量 Power System 和 AIX 上运行的 WebSphere Application Server 投资的成败时，最终要取决于所有系统架构师能否很好地理解如何同心协力地利用每种产品的特有优势。因而，我们首先要做的是澄清各种观点。

在 Power System 上优化 WebSphere Application Server，第 1 部分: 入门以及优化策略

在 Power System 上优化 WebSphere Application Server，第 2 部分: 设置 Power System 硬件和分区（上）

在 Power System 上优化 WebSphere Application Server，第 3 部分: 设置 Power System 硬件和分区（下）

有空么可以再看看《WebSphere Application Server V6.1 Planning and Design WebSphere Handbook Series》

转自BEA，原文链接已经无法访问，文中的许多链接也更改过地址，我把能找到的都重新做了连接。以前一直以为Jrockit和Sun的JVM配置差不多，看了这篇文章和最后参考资料中的信息，发现区别不是一点点，很多常用参数的使用都不一样。Jrockit的自动化设置应该说做的不错，在WebLogic上我很少更改它的默认配置（除了堆最大最小值），不过不影响这篇文章存在的价值。

摘要

本文的目的是以清单的方式提供BEA JRockit JVM的调优信息。从深奥的命令行选项到迭代性能测试，本文涵盖了许多方面。大部分数据都是我与用户合作过程中收集的。您要是也有什么技巧的话，请告诉我，在本文的下一版中，我会尝试将它们添加进去。

具体的产品版本信息都已在适当的地方列出；但是，本文所提供的通用指南适用于JRockit的大多数版本。每个版本的JRockit都增加了新的设置和优化，所以请查看 发行说明 和 JRockit产品中心。

验证当前的JRockit环境

首先需要确定您的运行时应用程序服务器所使用的JRockit的版本。为此，可以查看相应应用程序服务器的日志文件。也可以使用适当的脚本设置系统环境，然后执行java –version命令来确定JRockit的版本。

接着，收集当前JVM标志，开发和/或生产阶段需要用到它们：

-server -Xms1024m -Xmx1536m -Xverboselog:gc.log -Xverbose:memory-Xgcprio:throughput

这将告诉您当前JRockit实例的配置情况。

确定应用程序的目标

确定应用程序的目标是什么。是“响应快”还是“性能高”？根据目标的不同，需要设置不同的垃圾收集算法。

例如，如果应用程序的目标是实现高性能，则确保设置了Dynamic Garbage Collector "-Xgcprio:throughput" 选项。如果目标是响应时间短，那么需要将-Xgcprio:pausetime -Xpausetarget=XXX’中的pausetarget设置为最佳值。有关更多细节，请查看JRockit 调优文档。

收集故障诊断数据

如果JVM性能有问题，那么最好是先收集一些分析数据。该工作可以由团队中有相关经验的人员来完成，您也可以将这些信息发送给BEA Support做进一步分析。

首先，出现问题时需要收集大约10分钟的运行时JRockit Recording（JRA)数据。可以使用jrcmd.sh实用工具或JRockit Mission Control（JRMC）完成此操作。请阅读“性能测试期间的JRCMD/JRA”和“JRockit Mission Control”两节的内容。有关详细信息，请参阅 JRockit Mission Control文档。Latency Analysis一节提供许多有价值的内容，我们可以从中了解任何潜在的延迟问题（在JRockit中需要一个许可证就可以使用它）。

然后，需要收集问题发生时的一些详细日志。方法是在启动服务器实例的时候在JVM命令行输入以下参数：

-Xverboselog:perTestGC.log-Xverbose:opt,memory,gcpause,memdbg,compaction,gc,license-Xverbosetimestamp -Xgcreport

这样会将有价值的分析数据收集到刚才配置的perTestGC.log文件中。团队成员和/或BEA Support可以对这些数据进行分析。

最后一点：通常，应用程序不会请求执行垃圾收集（也就是在应用程序代码中调用System.gc()）。但如果您怀疑它有问题，那么可以在启动服务器实例的时候，在Java命令行使用-XXnoSystemGC参数来禁用它。

现在，我将介绍如何通过迭代性能测试方法解决这些问题。

阅读全文…

[1]SQL Server 索引结构及其使用

数据查询的快慢往往影响着一个应用的生与死。这个系列4篇文章是针对SQL Server的索引结构，介绍了聚集索引（clustered index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）的区别，使用的环境、策略，并比较了不同索引策略造成的不同结果。对于书中的一些说法，文章也通过实验给出了不同的看法。

下面的表总结了何时使用聚集索引或非聚集索引（很重要）：

动作描述	使用聚集索引	使用非聚集索引
列经常被分组排序	应	应
返回某范围内的数据	应	不应
一个或极少不同值	不应	不应
小数目的不同值	应	不应
大数目的不同值	不应	应
频繁更新的列	不应	应
外键列	应	应
主键列	应	应
频繁修改索引列	不应	应

第一篇 http://www.vckbase.com/document/viewdoc/?id=1307

第二篇 http://www.vckbase.com/document/viewdoc/?id=1308

第三篇 http://www.vckbase.com/document/viewdoc/?id=1309

第四篇 http://www.vckbase.com/document/viewdoc/?id=1310

[2] 一个RoR的站点性能优化的故事

俗话说：是骡子是马，拉出来溜溜。压力低的应用，客户有钱买硬件，那随便你怎么折腾都没关系。不过面对日上百万PV的web2.0站点，优化的能力就不可小觑，优秀的开发团队还是拙劣的队伍立分高下。

虽然你我也许没有遇到这样的情况，但是就算当故事书来读，也是很有趣的。

http://ityum.net/2009/08/01/00/02/一个ror的站点性能优化的故事.html （原站MS无法打开了）

暂时google了一个 http://blog.donews.com/chinaz/archive/2009/08/04/1546463.aspx

[3] 互联网草根的故事

互联网大佬的故事往往让人汹涌澎湃却也望之兴叹，于是草根站长的故事就平易近人的多。不过虽说草根，也不是睡个觉就能数钱的。考实力还是搏出位，背后还都离不了“偏执”在里头。

 蔡文胜 李兴平从竞争到合作 共铸站长之王

在《编写符合GC胃口的程序》一文中我分享了两篇PDF，javaProgrammingPerformanceTips和GCFriendlyProgramming，但是没有展开介绍，看过的同学可能知道了how，但是不清楚why。这里分享编程随想的博客中的几篇关于java性能优化的文章，感兴趣的同学可以去看看，我就不转了。

1. Java性能优化[0]：概述
2. Java性能优化[1]：基本类型 vs 引用类型
3. Java性能优化[2]：字符串过滤实战
4. Java性能优化[3]：垃圾回收(GC)
5. Java性能优化[4]：关于finalize函数

这位同学的主博看起来应该是blogspot上的，虽然在csdn上都有相应的镜像，但是链接做的都是blogspot，所以各位准备好梯子。

技术是需要钻研的，但是IT的发展一日千里，闭门造车难免会固步自封；作为公司的初级员工，老板让干啥就干啥又容易成为井底之蛙。所以欢迎添加jaintkiller at gmail dot com为好友，通过Google Reader一起分享优秀文章。当然我也会把自己觉得好的内容以每周一期的形式写在博客上，“问泉哪得清如许，为有源头活水来”。（其实我是偷懒不想更新）

[1]《豆瓣网技术架构变迁》

豆瓣网从2005年到现在的架构发展历程，PPT很早推出了，这次演讲视频总算是千呼万唤始出来。关注架构、关注大型web站点技术内幕的同学可以看看。

地址：http://www.infoq.com/cn/presentations/hongqn-douban

豆瓣的架构—专访豆瓣网站的技术总监洪强宁

[2]虚拟化扑面而来

虚拟化真是越来越近了，以前还只是听到个概念，去年Vmware来公司介绍VMware Infrastructure时还在考虑“一般的企业用不起，用得起的企业看不上”的问题。但现在虚拟化后对服务器利用率的提高、对电力消耗的降低、物理服务器管理的简化等好处已经深入人心，虽然还面对着几大厂商各自为政的窘境和把所有鸡蛋都放一个篮子里的担忧，但是已经有客户主动提出要把现有的非关键应用转移到虚拟机上去了。上次Red Hat来公司介绍的也是他们的RHEL5.0 Advanced Server中的虚拟化技术，所以趁早熟悉一下虚拟机的安装、管理、故障转移是正道——对于系统管理员来说。

服务器市场成本压倒一切

虚拟化整合之势凸显

[3]Java性能分析和监控

现在的主业不能丢：

使用Perf4J进行性能分析和监控

使用Jprofile解决应用服务器内存泄露问题诊断一例

WebSphere 2009年发展方向

要进行gc performance tuning，不得不对gc log进行分析。之前说到了“人肉”的方法，总觉得不够形象，无法让不了解的开发人员抑或是技术负责人有个直观的了解，所以本文介绍几个分析GC log的工具。

首先需要下载IBM Support Assistant，下载之后就可以从Update-Tools add on中下载我们需要的工具了，ISA使用方法。ISA把所有的工具集成在一个界面内，省去了设置启动参数的麻烦，同时能保持最及时的更新。分析垃圾回收日志，我主要用“The IBM Monitoring and Diagnostic Tools for Java™ – Garbage Collection and Memory Visualizer”和“IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT)”这两个工具。我会用实际例子来说明如何使用这个工具。

用Garbage Collection and Memory Visualizer载入native_stderr.log，首先你会看到

点击展开大图

这是一个500分钟的垃圾回收曲线图，可以观察到一天以内的大致情况。总的来说，蓝色的Used heap（after collection）运行在“平行通道”内，没有走“上升通道”（炒股的朋友应该知道上升通道的图形是咋样的）。所以在Report这个标签内，可以看到“The memory usage of the application does not indicate any obvious leaks.”。

Report中的Summary是需要关注的，它向我们显示了GC发生的次数，所用的policy（optthruput），平均停顿时间248ms，平均间隔时间3.37分钟，还有垃圾回收的速率（垃圾产生多并非不好，反而是吞吐率高的一种表现）。

让我们再切回Line plot视图，现在可以框选某一个时间段进行放大，同时在右边Axes中选择X轴的坐标系，默认的是相对时间，以分钟为单位，适用于你的应用程序总在启动N个小时后出现问题。如果是每天固定时间发生性能问题，那么应该选用绝对时间。

默认的曲线开启了Heap size和Used heap（after collection），你可以根据需要，在VGC Pause Date和VGC Date、VGC Heap Data中勾选你需要查看的曲线。比如你觉得程序响应时间很长，那么可以勾选上Intervals between garbage collection triggers和Pause time，看看上一条曲线是否和下面一条靠的“太近”。

阅读全文…