该项目是一个同学在09年年底做的，属于XX省的会计从业人员管理系统，09年年底上线的，由于是新做的项目，用户比较重视，对硬件投入也比较大，应用服务器和数据库服务器的配置CPU都是8C，内存都是16G，操作系统是linux，中间件是weblogic10，数据库是oracle10.2.0，系统运行了1年多，基本没出现什么大的性能问题。
直至到2010年年底，该省会计监管部门出台相关政策，规定所有会计人员必须更新相关信息，所以这段时间是系统使用的高峰期，平均的并发量大概有1000左右，此时有很多用户反映系统非常慢，无法操作业务，同学跟我说了一下大概的现象，了解一下便开始一起查找问题原因：
在业务高峰期时使用top命令分别查看应用服务器和数据库服务器的运行情况，应用服务器的CPU和内存使用率都比较低，数据库的cpu使用率也不高，但内存占用特别高，16G几乎全部耗尽，登录oracle，使用show parameters session查了一下oracle的最大支持session数为170，再使用show parameters process，查了一下，支持的最大进程数为150，由此可以判断该oracle是下载版，不属于正式的商用版,但也应该不至于出这个问题。在v$process视图中查了一下，也没有发现占用内存特别多的后台进程，停掉oracle服务之后，物理内存也没有释放，问题可能会出在哪儿呢？
当时对linux内存管理和oracle性能调优方面的知识了解的不是很多，于是没有太在意这个问题，我找了以前公司几个对oracle比较熟的人，他们也没找到这个问题的原因。
于是决定从数据库本身开始查找原因，了解了一下数据表结构，有几张调用比较频繁的表都有1百多个字段，而且这几张表要做连接查询，其中有两张表的数据量大概在30万条左右，还有一张表有100多万条，可以判断表设计不是很合理，做了大量的优化，包括建索引，优化sql、调大连接数等，但内存耗尽问题还是没有得到解决，运行几天后，内存又耗尽了。这个问题只能暂时不了了之，等业务高峰期已过，用户已经不是很重视，这个问题再放一放。
7月份的一个星期六，本来要去给另外一个朋友做的系统做压力测试，这个朋友是以前银行的一个客户，后来自己开公司，做社交网站的，做的还比较大，有负载均衡设备，应用服务器有10台，数据服务器也有好几台，配置都是不错的，于是就答应了，星期五晚上突然接到电话，要去这个同学家里，帮他搬家，请的搬家公司，让我过去看一下东西，于是调整了一下计划，周六一大早就去了，去的时候发现朋友搬家已经差不多了，此时大概早上9点左右，想着下午还得做压力测试，于是我跟他大概交代一下准备离开，走的时候突然想起来问他那个项目的进度，他说现在又到业务高峰期了，又有很多用户反映无法办理业务，同学现在已经是部门经理了，这个问题不解决，以后估计会很麻烦，上个月他已经把中间件换成tomcat6了，JVM也重新配置了一下，大概配置如下：-Xms 4G –Xmx 4G –Xmn 2G –Xss 256M，对于这个配置我的看法是：
1、JVM设的太大，最多2G,新生代也不合理，太大，新生代太大会导致老年代太小，老年代太小容易出发full GC，会导致系统阻塞。另外栈内存也太大，256K就足够了，当时我建议他把JVM调到2G，新生代设为初始堆内存的1/4-1/3比较合适,栈内存永久代调到256K。
2、另外了解到现在session的超时时间是30分钟，我觉得太大，10分钟以内比较合适，太大会导致长时间占用系统资源不释放，用户量一上来，系统资源消耗比较大。
3、确认一下系统有没有签退功能，如果有的话，看一下有没有做资源回收的相关操作。
4、最后重点还是放在数据库上，回家之后跟他说了一下我的想法，并给出具体的操作建议，具体为：
A、高峰期时登录数据库服务器，执行top和free，关注以下值:
total used free shared buffers cached
Mem: 2066896 1837280 229616 0 136088 875560
-/+ buffers/cache: 825632（该值表示真正已消耗的物理内存） 1241264（该值表示真正剩余的物理内存）
Swap: 4128760（虚拟内存） 0 4128760
B、导出最近7天oracle的运行分析报告，步骤：登录oracle，执行@?/rdbms/admin/awrrpt.sql，导出格式选择html格式，确定有无消耗内存比较多的sql。
C、分别查询v$session,v$session_wait,dba_locks,v$locked_object，确认是否有会话阻塞或死锁
D、查询v$process（查看PGA占用的内存之和以及orcle占用的内存最多的进程）
2天过去了，再给同学打电话，同学说已经找到问题了，高峰期时使用free命令查了一下发现Cache的值特别大，将近10个G，而free的值却只有100多M，就是linux缓存的问题。因为一开始部署项目的时候给oracle分了6个G的内存，linux的cache将近10个G，运行一段时间之后liunx的free内存只有100M，此时处理业务时就会导致特别慢。
（符合之前分析的现象，就是停掉oracle服务之后，内存也不释放，其实已经可以判断内存不释放的原因应该是linux本身的问题。）
于是释放Cache Memory(缓存内存)：用该命令可以释放Cache Memory：echo 3 > /proc/sys/vm/drop_caches，终于解决问题。
其他原因分析：
1、oracle服务器IO比较高，但是磁盘效率比较低，导致IO等待太高，建议做RAID0，如果条件支持，可以做RAID10，或者更换更高效率的磁盘。
2、oracle数据库表设计不合理，没有做分区处理，由于IO读写非常大，加上磁盘效率低，这是导致free资源消耗严重的根本原因，建议对数据库大表进行分区处理。
