序言
企业级应用系统软件通常有着对并发数和响应时间的要求,这就要求大量的用
户能在高响应时间内完成业务操作。这两个性能指标往往决定着一个应用系统
软件能否成功上线,而这也决定了一个项目最终能否验收成功,能否得到客户
认同,能否继续在一个行业发展壮大下去。由此可见性能对于一个应用系统的
重要性,当然这似乎也成了软件行业的不可言说的痛 —— 绝大多数的应用系统
在上线之前,项目组成员都要经历一个脱胎换骨的过程。
生产环境的建立包含众多方面,如存储规划、操作系统参数调整、数据库调优、
应用系统调优等等。这几方面互相影响,只有经过不断的调整优化,才能达到
资源的最大利用率,满足客户对系统吞吐量和响应时间的要求。在无数次的实
践经验中,很多软件专家能够达成一致的是:应用系统本身的优化是至关重要
的,否则即使有再大的内存,也会被消耗殆尽,尤其是产生 OOM(Out Of
Memory)的错误的时候,它会贪婪地吃掉你的内存空间,直到系统宕机。
内存泄露 — 难啃的骨头
产生 OOM 的原因有很多种,大体上可以简单地分为两种情况,一种就是物理
内存确实有限,发生这种情况时,我们很容易找到原因,但是它一般不会发生
在实际的生产环境中。因为生产环境往往有足以满足应用系统要求的配置,这
在项目最初就是根据系统要求进行购置的。
另外一种引起 OOM 的原因就是应用系统本身对资源的的不恰当使用、配置,
引起内存使用持续增加,最终导致 JVM Heap Memory 被耗尽,如没有正确
释放 JDBC 的 Connection Pool 中的对象,使用 Cache 时没有限制 Cache
的大小等等。本文并不针对各种情况做讨论,而是以一个项目案例为背景,探
索解决这类问题的方式方法,并总结一些最佳实践,供广大开发工程师借鉴参
考。
项目背景介绍
项目背景:
1 内网用户 500 人,需要同时在线进行业务操作(中午休息一小时,晚 6
点下班)。
2 生产环境采用传统的主从式,未做 Cluster ,提供 HA 高可用性。
3 服务器为 AIX P570,8U,16G,但是只有一半的资源,即 4U,8G 供
新系统使用。
项目三月初上线,此前笔者与架构师曾去客户现场简单部署过一两次,主要是
软件的安装,应用的部署,测一下应用是不是能够跑起来,算作是上线前的准
备工作。应用上线(试运行)当天,项目组全体入住客户现场,看着用户登录
数不断攀升,大家心里都没有底,高峰时候到了 440,系统开始有点反应变慢,
不过还是扛下来了,最后归结为目前的资源有限,等把另一半资源划过来,就
肯定没问题了。(须知增加资源,调优的工作大部分都要重新做一遍,系统级、
数据库级等等,这也是后面为什么建议如果资源可用,最好一步到位的原
因。)为了临时解决资源有限的问题,通过和客户协商,决定中午 12 点半和
晚上 11 点通过系统调度重启一次应用服务器,这样,就达到了相隔几个小时,
手动清理内存的目的。
项目在试运行阶段,仍旧有新的子应用开始投入联调,同时客户每天都会提出
这样那样的需求变更,如果要的很急的话,就要随时修改,隔天修正使用。修
改后没有充分的时间进行回归测试,新部署的代码难免会有这样那样的问题,