3. 需要重起计算机。
4. 如果机器上没有DNS服务，请安装，最好再安装系统的时候就安装了此项服务。如果安装系统时没有安装:
a) Control panel
b) Add or remove programs
c) Add or remove windows components
d) 选择“Networking Services” – Press “Detail”
e) 选择 “Domain Name System(DNS)”
f) 安装DNS服务 (确保安装光盘在光驱中)
5. Start->Administrative tools->DNS
6. 右键点击 – “Forward lookup zone” -〉 new Zone

其他都按照默认选项来配置。
7.  右键点击– “Reverse lookup zone” -〉 new Zone

其他都按照默认选项来配置。
8. 检查配置，看是否工作正常。

解释半天， 没有一个听得懂， 汗一个。

日本人， 听不懂也不能表明我们的工作就是没用用， 看我来解释解释。

 一般人的印象， 做应用工程师， 售前 ， enabling总归要有个产品。 我们的产品是什么呢 --- 多核CPU

前段时间MSN 中国上面有个科技的headline。 说现在软件面临的最大挑战是什么  ---  在多核CPU 上面性能还没有单核好。  MSN中国 不是intel 的枪手，上面多半是美女八卦，  突然在科技版面搞了个headline 把当今软件面临的最大挑战描述为多核 enabling ， 哇塞，绝对是给我们打广告。 看得我真是高兴啊。

    为什么高兴，  主要是自己的工作得到了稍稍的社会的重视。    以往软件哪有什么性能不性能的，主要是功能。 能跑不就ok了吗。 现在不一样了，  多核已成主流，  你一个软件多核上面比单核还跑得龊，end user 绝对在家里骂娘。

summary：

    英特尔做程序优化的多核应用工程师是IT 界默默无闻， 无私奉献， 解决现在软件面临的最大挑战的平凡的IT 民工。 对改变现在一个软件多核上面比单核还跑得龊，end user 在家里骂软件公司的现状有着无比积极的作用。

为了表彰英特尔^® 软件网络社区中最活跃的成员对我们一直以来的支持，我们希望授予他们荣誉头衔，让他们感受到尊崇。为此，我们推出了“英特尔^® 黑带软件开发人员”头衔，用于表彰拥有专业技术知识、与他人分享知识，并协同其他成员促进社区发展的人士。

    为何采用“黑带”一词？跆拳道中的“黑带”表示运动员的技术动作与思想修为均已臻成熟，而在我们的社区中，这个称号意味着社区成员具备高人一等的创新开发能力和深入理解能力。“黑带”是我们为答谢社区成员所做贡献的一种方式，是我们授予社区成员的最高荣誉。我们将为获得该头衔的人员提供多项工具及奖品，详情可点击这里了解。

Igor Levicki 和 Jim Dempsey 两位有幸率先获得“英特尔^® 黑带软件开发人员”荣誉称号:

• 来自塞尔维亚贝尔格莱德的Igor是一名软件工程师，最擅长代码优化、图片、视频和音频处理以及线程和 GPGPU 编程。相信 Igor 对大家来说一点也不陌生，因为他是论坛上的大忙人。
• Jim 曾在一些知名公司（如 Digital Equipment Corp和 EDUCOMP）工作，积累了丰富的经验。他经常在并行编程论坛发帖。最近，Jim 与英特尔^® 多核线程化社区社区经理 Aaron Tersteeg 一道参加了我们的研究@英特尔活动。

我们还会于今后几个月陆续颁发部分黑带称号，敬请关注。

    一切才刚刚开始 ……

    我们想听听您对这种认可方式、奖品等各方面的评价。您认为我们在哪些地方还有待改善？您作为认可的一分子还想看到什么呢？不妨将您的想法以邮件方式告诉我们。

lomount -diskimage /PATH/TO/Image.file -partition n /mnt

在mount前请注意以下事项：

1。 对于RHEL的虚拟机来说，这个命令不可以mount类型是LVM的分区。所以在安装虚拟机操作系统的时候请注意不要使用default分区。最好手动分区。

2。 对于SLES的虚拟机来说，这个命令不可以mount类型是refeies的分区。所以在安装虚拟机操作系统的时候请注意不要使用default分区。最好手动分区。

3。 请记住你要mount的分区号。

4。 修改完之后请记住umount.

在虚拟机中使用yast. 选择network service-> network device. 将原来的网卡删除掉。然后重新配置。注意必须先删除，不可以直接改，直接改是没有效果的。

2。 无法进行live migration：

需要注意以下几点：

        a> 目前来看，只要在虚拟机中使用了PV Driver我们就无法成功地进行实时迁移。这个是个bug.我们已经通过开发人员向SUSE报了bug.相信会在下一次版本的发布中会解决此问题。

        b> 如果发现虚拟机中安装了PV Driver. 最好用rpm -e的方式将PV Driver卸载掉，这样比较好。之后重新启动虚拟机，再对网卡进行配置，需要配置那个8139的网卡，不应该配置那个XEN virtual network card.

        c> 检查NFS的配置，看是否配置成为RW.(在/etc/exports）。

        d> 检查两个host的网络，看虚拟机的网络是不是对应同一个bridge.

3。 如果想修改host的网络设置，在Domain0中是无法实现的，必须重起host然后进入到native模式（即非XEN虚拟化模式）中将网络设置好之后再重起进入domain0.

4。 TO BE CONTINUED........

sar -a

sar -b buffer

sar -c

sar -k

sar -m

sar -d

sar -q

sar -r

sar -v

sar-w

sar -y tty

非常推荐英特尔软件学院的多线程化配套课程，里面有有关多线程化分析设计的基本思路和方法，多线程化实现的多种方法，以及多线程化方案的性能优化方法。

这里我再补充一点是有关基于COM组件实现的应用系统进行多线程化时候的实现方式。当前COM已经没有继续技术上的发展了，但是遗留下来的相关系统可能采用了基于COM的实现方案。那么这一情况就是我们在实现多线程优化的时候需要考虑的实现环境，因为它有别于基本的Windows Thread API，或是Linux PThread API。COM的多线程支持采用了微软自定义的套间（Apartment）的多线程模型，对多线程之间私有数据隔离采用了单套间的实现方式，对于多线程之间的数据共享采用了多套间的实现方式。采用套间方式实现COM组件多线程调用之间的交互，避免使用更高级别的进程之间的数据共享，会给基于COM组件的应用带来多线程优化方面的性能提升。

当然，毫无疑问COM技术已经不是主流。我上面的补充建议旨在考虑基于COM组件的遗留系统进行优化时的多线程可选方案，如果是非COM组件的运行环境，就可以轻松采用Intel软件学院的多线程编程课程中的相关多线程化实现技术了。例如基于编译器的OpenMP，Windows Thread API等等。

最后，还有一个好消息，大家可以看看英特尔在多核多线程软件战略中的新发展——Intel Parallel Studio (http://www3.intel.com/cd/software/products/asmo-na/eng/399359.htm)。

JRockit Runtime Analyzer（JRA）是一个JVM分析器，是一个随需应变的“动态记录器”。它记录了Java应用程序和JVM在一段预定的时间内的详细记录。然后通过JRA应用程序对记录下来的文件进行离线分析。所记录的数据包括对方法的调用跟踪、错误的同步、锁定的分析，还有垃圾收集统计信息，优化决策以及对象统计信息和其他重要的应用程序/JVM行为。它的目的是让JRockit开发人员能够找到良好的方法来基于现实应用程序优化JVM，对于帮助客户在生产和开发环境中解决问题十分有用。

2.性能数据分析和调优

在本次项目中，操作|A和操作B的百人并发脚本执行完成的时间接近两分钟，因此我们使用JRA进行了2分钟(120秒)的记录。在GC常规信息中，我们发现在短短两分钟时间内，垃圾收集的总数高达365次，而由此造成的暂停时间有42.5秒之多。也就是说35%的执行时间是在做垃圾收集。

因为最大堆尺寸已经设置成1024M，对于32位操作系统上的Java应用已经是足够大了（在IA32构架下，由于操作系统给每个进程的最大内存寻址空间为1.8G，因此最大堆尺寸不能超过1.8G），因此堆的大小并不是造成频繁垃圾收集的原因。那么在高并发度的场景下，可能的影响因素很可能是Nursery大小。

Nursery 也称为新代，是指运行分代式垃圾收集器时，在堆中分配 新对象 的可用块区域。当 Nursery 变满时，会在新垃圾收集中单独对其进行垃圾收集。Nursery 大小决定了新收集的频率和持续时间。较大 Nursery 会降低收集的频率，但是会稍微增加每个新收集的持续时间。 Nursery 之所以具有价值，是因为 Java 应用程序中的大多数对象都是在新代中夭亡的。与收集整个堆相比，应首选从新空间中收集垃圾，因为该收集过程的开销更低，而且在触发收集时，新空间中的大多数对象均已死亡。在新收集过程中，JVM 首先确定 Nursery 中的哪些对象是活动的，此后将它们提升到旧空间，并释放 Nursery，供分配新的小对象使用。

Nursery的默认缺省值是10M/CPU，对于我们Clovertown服务器来说，只有20M。由于出现频繁收集的情况，那么我们推断是由于Nursery的默认值太低的原因。一方面在高并发用户的场景下，肯定是有大量的新对象产生，那么Nursery的空闲空间很容易就被耗尽。因此Nursery发生垃圾收集频率就会比较高。另一方面更短的垃圾收集间隔会使得新对象在Nursery的存活率提高因为很多新对象可能还没来得及使用完毕就已经发生垃圾收集。这样更多的对象会被提升到旧代，使得旧代的对象也会急剧增加，从而使得旧代发生垃圾收集的频率也增加。

因为JRockit JVM可以使用-Xns:<size>来设置Nursery的尺寸，我们要在保证垃圾回收停顿时间（garbage collection-pause）尽可能短的同时，尽量加大Nursery的尺寸，这在创建了大量的临时对象时尤其重要。推荐值是最大堆尺寸的10%，因此我们在JRockit的运行时参数上添加了 –Xns100m。再次运行脚本后，JRA收集的信息显示GC暂停时间骤降到15.3s，次数也有所减少，降到296：

此外，我们从方法信息中可以看到调用次数最多耗时间最长的两个方法分别是jrockit.vm.Locks.monitorEnterSecondStage和com.ABC.StateManager.makeState两个方法。展开前置任务后发现调用这两个方法最多的方法是com.ABC.SqlQueryAction.query。而jrockit.vm.Locks.monitorEnterSecondStage显然是JRockit实现锁机制的特定的API。因此我们怀疑是对数据库的操作时有资源互斥的现象发现。

考虑到高并发用户的场景下，对数据库操作的并发度也很高，因此对数据库连接的争用比较激烈。我们察看了一下当时WebLogic JDBC的配置，发现connection pool的大小只是缺省值20，相对来说偏小了，对性能会有一定的影响。因此我们增大connection pool的大小到100。重新运行测试脚本后发现性能有较大提升。

在性能调优完成后，我们又进行了功能测试（回归测试），以验证上述改动没有影响系统的功能性正确。

四、小结

其实利用Mission Control对Java应用进行调优并不难，对吧？希望本次性能分析调优的过程可以给大家一些启发，今后可以应用到日常工作中。