之前生产服务器平均几天自动重启一次。近期每天自动重启了多次。
查看log，heapdump.
中间又遇到了问题 ， 这种应用产生溢出几乎没有产生存储快照
〈因为要产生十几GB 乃至E大的DumpX件〉，产生了的也几乎无法进行分昕－
2）new 出来的对象均是 强引用，jvm宁愿抛出OutOfMemory异常，代码中写了一个HashMap,不断存放大量数据，而没有在使用完之后null.
一）每隔几天自动重启，重启时间不定，会影响业务。改进：定时每天晚上重启。
例如， 一个15 万PY／天左右的在蜡立档提型间站最近更换丁硬件罩统， 新的硬件为4
个CPU 、16G B 物理内存，操作罩统为64 位Co"tOS 5.4, Ro，；＂作为Wob 服务器． 整个服务
器暂时世有部署别的应用，所有硬件黄面都可阻挺供结迫出问量并不算太大的罔站使用． 管
理员为了尽量利用硬件贤相适用T 64 位的JDK 1.5 ，并通过－Xmx 和－ Xm• 参敢将Jm 堆固
定在12GB . 使用一段时间后盎现使用效果并不理想，同站经常不定期出现长时间失去响应
的情扭．
监控服务器运行状况后发现同站失去响应是由GC 停牺导致的，虚拟机运行在Server 模
式，默认使用吞吐量优先收集器，回收12GB 的堆， 一次FullGC 的停顿时间高达14 非． 并
员和l骨Jll!bl感到相泪丧．
店里先不延伸时论程l芋代码问题， 程序部暑上的主要问题!l酣是过大的推向存进行l日l收
时带来的长时间的停顿． 硬件到辑前使用32 位系统l.SGB 的雄，闸户只感觉到使用间站比
较理僧，但不垂直生十分明显的停咽，因此才考监升级H件U提升程序效能． 如果重新蜻小
姑Java h在分配的内存，那么使件t的世班就显碍咀浪费．
在高性能硬件上部署程序，目前主要有两种方式：
1. 通过64 位JDK 来使用大内存．
2. 使用若干个32 位虚拟机建立逻辑集群来利用硬件资源．
此案例中的管理员果用丁如一种部’警方式．对于Ill户主互性强、时停顿时间敏感的革
统，“m拮Jm 虚拙机分配剧大雄的前键是有把握把应用程序的F "ll GC 捶率控制得足够
~＼.至少要配到不会影响用尸使闸，譬如才几个小时乃至－天~出现一次Foll GC ， 这样可
山画过在部夜执行定时任务的万式融2/F" ll GC 甚至自动量启应用服务器来保持内存可用空
间在一个程定的水平．
控制F"ll GC 颇率的关幢是肝应用中绝大多世Ml民能有持告“明l生夕页”的原则j 即大
多散时象的生存时间不应太长，尤Jt业不能有成批匪的、i＜生存时间的大对盘产生，过样才
能由障在年代空间的吕定．
在大事墨宝同站形式的应用血，主要时聋的生存周期都应国是请求辑或者页面盟的，全面
姐和1圭局级的位生命刑且相对很少． 只要代码写得合理，应当部能主理在超大堆中正常使用
而世有Full GC ，这样的话，使用越大堆内存时！同站响应速血才生比较有保证． 除此之外，
如果it者汁剧使用64 位JDK 来管理大内存，还需要考虑下面可能面临的问题
口内存回收导致的妖时间停顿．
口班阶段. 64 位JDK 的性能制国结呆曾届低于3 2 位JDK ,
口需要w 证程序足够稳定，因为这种应用要是产生粮溢出几乎就无法产生维特储快阳
〈因为要产生十几GB 乃至E大的DumpX件〉，哪怕产生丁恤阳也几乎无法进行分昕－
D 相同在序在64 位JDK In蜒的内存一般比32 也JD K 大， 这是白于指针睡胀， U且盘
据提到时齐补白等因章导放的．
上固的问题听起来有点吓人，所四国阶段不少管理且还是击得第二种方式使用若于个
JL位虚拟帆建立逻辑集群来利用硬怦如视具体做苗是在古物理韧情上启动多个应用服
务器进程亨每个服务器进程分配不同喘口，措后在前瑞搭建一个负载均衡器，以且由优理'1'1-
苏式电分配萌问请求． 出者在需要太过在意均衡部转监脾消耗的性能，即使使用肿位JDK,
i是多应用也不止有一台服务器，因此在i乍多应用中前端的均衡器且是要在在曲．
考虑到在一位物理机器上建主逻辑靠群的目的仅但应为了思可能和朋硬僻资源，并不需
要芫心状态保阔1 热转移之费的高可用性需求， 也不需要悻证每个虚拟机进程有结对准确件
均衡负载，因此使用xs.,, ; ,.;11:制的亲告式集群是个相当不错的选择． 我们扭扭需要保
障集群具备亲合性，也就是均衡器挂一直的规则算法〈一般根据Se,,innlD 分配）将一个固
定的用户请求永远分配到固定的个靠群节点进行处理即可，这样程序开盎阶段就基本不用
为集群环境做什么特别的考虑了．
当悟， IR少有世有缺点的方案， 如果读者计划使用E崛靠群的方式来部署程序，可能会
遇到下面一些问题
0 思量避免节点竞争全局的资源7 最典型的就是磁盘竞争1 各个节点如果同时t方向某个
瞄盘文件的话（尤直是并监写操作窑晶出现问题〉，咽窑岛导致10 异常．
0 根难且商效率地利用某些野源地，譬如连接池， 一般都是在各个节点建立自己独立的
直接池，这样有可能导草一些节点池描丁而另外些节点仍有较多空余． 厚管可且使
用集中式的JND I ，但这个有定盟杂性并且可能带来额外的性能开销
口各个节点仍照不可避免地查到32 位的内存阻制，在32 位Windows 平台中每个进程
只能使用2GB 的内存，考虑到堆山外的内再开圃，堆一般最多只能开到1.50 8. 在
某些Linu＇茸UNIXll\统（如Snlori,J 中，可山提升到JGB 乃至接近408 的内存？
但32 位中仍然圭最高4GB (2＂）内存的限制g
口大量使用本地援存〈如大量使用H"hMop 作为KN 缓存〉的应用，在逻辑靠群中全
造成曹大的内存浪费l 因为每个逻辑节点上都有一柑级非，这时候可U考虑把本地组
存改为靠中式缀存．
介细完这两种部署方式，再重新回到这个案例之中，最后的部署方案调整为建立5 个
32 位JDK 的逻辑集群，每个进程挂2GB 内存计算〈其中堆固定为I.SO时，占用7 IOGB
内存． 另外建立一个Apocho 服务作为前瑞均衡代理由问门户． 考虑到用户时响应直匮比辑
关心，并且主挡服务的主要压力集中在瞌盘和内存前间， CPU 贤源敏感匪较低。
