]]>
首先创徏两个试表：
create table test_long (a int primary key,b long);
create table test_clob (a int primary key,b clob);
用附件java代码Q往两个表里面各插入100条数据，保证插入数据是一LQlob字段长度?0kQ如果小?kQoracle可以把它保存到到表内Q不会存储在表外Q性能没有问题Q这个我基本定Q而且我们应用中这个字D늻怼过4kQ?
做一个简单查询对比一下：
SQL> set autotrace traceonly;
SQL> select * from test_clob where a=1;
l计信息
----------------------------------------------------------
331 recursive calls
0 db block gets
69 consistent gets
4 physical reads
0 redo size
1278 bytes sent via SQL*Net to client
837 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
12 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select * from test_long where a=1;
l计信息
----------------------------------------------------------
236 recursive calls
0 db block gets
43 consistent gets
0 physical reads
0 redo size
675 bytes sent via SQL*Net to client
531 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
1 rows processed
Ҏ一下，long开销比lob，当然你可以把lob字段启用~存Q把4ơ物理读LQ但q是多了Q?3-43Q次逻辑读，update也试了一下，lob产生的redo比long大，׃列出来了Q有兴趣的可以自p?
试下来Q看来之前的认识不对Q不定的东西最好还是动手试试，当然对于新应用，q是不徏议用longQ毕竟oracle已经废弃它了?
]]>
也就是说Q服务器的连接数已经满了Q很多时候，可能是别人异常断开q接Q导致连接没有释放，一般这时候你需要去机房d服务器断开q接Q其实windows提供了tsdiscon命o来做q事?/p>
]]>
1、政府反映非常迅?br /> 2、子弟兵真好
2、有一个好ȝ
3、地Ҏ府不作ؓQ官话套话（被采访的那个什么何彪，真想抽丫的）
4、ؓ什么L学校Q处于地址多发地带的学校和其他公共设施Z么都是豆腐渣
为所有受隄人祈P为我们饱受磨隄国祷Q?br />
公司员工捐款20WQ尽点?br />
]]>
后面再重新测试的时候，加上了gc logQ用gc分析工具分析了一下gc的吞吐量Q发现吞吐量奇低Q竟然只?7%左右Q很是奇怪，看了一下gc日志Q所有都是global gcQ?怀疑gc{略有问题，查了一下资料，参考了下面一文章： 阅读全文
]]>
一个用户在某个旉点上当然只能发v一个用戯求，一个用戯求就是一个ƈ?br>
我们一般纠~在同一事物q发q是不同事务q发?br>
可能在一个时间点上，?00个用户在发送浏览，查询动作Q?0个用户在下订单，5个用户在做付Ƒ֊作，你说q个旉点上有多个q发hQ当然是115个了
衡量一个系l性能主要靠的是q个吞吐量（tpsQ?br>
当然我们也非常关心同?00个用户ƈ发下订单的时候系l是否能支撑Q这是通常我们大部分h理解的ƈ发）Q我们会说这是核心业务，我们要得出数据（是否要考虑背景业务呢，呵呵Q很难说的清楚，我一般就不考虑Q?/p>
Ҏ环境Q?4bit Solaris + 32bit JDKQ，客户把Heap最大设|ؓ2GQ开始怀?2bit JDK无法分配q么大的HeapQ经q验证，不存在这L问题Qsun|站也有相关说明Q在solaris 64bitpȝ上，32bit jdk最大可以设|到4GQ?/p>
但是从dump看到application classes loader大小已经C60M以上Q有Ҏ疑Perm|太导_查了一下sun的文，Perm区缺省大ؓ64MQ估计是应用加蝲太多classesDPerm区溢出，
我们也简单模拟了一下Perm溢出Q强制设|max perm大小?2MQƈ对GCq行了监控，l果和我们预想的一_看下面的gc logQ?
151.836: [Full GC 151.836: [Tenured: 25735K->25736K(1048576K), 0.8380858 secs] 25911K->25736K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8382804 secs]
152.676: [Full GC 152.676: [Tenured: 25736K->25722K(1048576K), 0.8464782 secs] 25752K->25722K(1557568K), [Perm : 32767K->32766K(32768K)], 0.8466638 secs]
153.525: [Full GC 153.525: [Tenured: 25722K->25724K(1048576K), 0.8419056 secs] 25738K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8420986 secs]
154.368: [Full GC 154.368: [Tenured: 25724K->25724K(1048576K), 0.8398816 secs] 25724K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8400498 secs]
155.212: [Full GC 155.212: [Tenured: 25724K->25725K(1048576K), 0.8365448 secs] 25788K->25725K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8367370 secs]
156.050: [Full GC 156.050: [Tenured: 25725K->25722K(1048576K), 0.8422488 secs] 25725K->25722K(1557568K), [Perm : 32767K->32766K(32768K)], 0.8424328 secs]
156.895: [Full GC 156.895: [Tenured: 25722K->25724K(1048576K), 0.8443532 secs] 25738K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8445450 secs]
157.740: [Full GC 157.741: [Tenured: 25724K->25724K(1048576K), 0.8427754 secs] 25740K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8429634 secs]
158.587: [Full GC 158.588: [Tenured: 25724K->25726K(1048576K), 0.8352290 secs] 25820K->25726K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8354212 secs]
159.424: [Full GC 159.424: [Tenured: 25726K->25723K(1048576K), 0.8435336 secs] 25726K->25723K(1557568K), [Perm : 32767K->32766K(32768K)], 0.8437092 secs]
160.270: [Full GC 160.270: [Tenured: 25723K->25725K(1048576K), 0.8477722 secs] 25739K->25725K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8479596 secs]
161.119: [Full GC 161.119: [Tenured: 25725K->25725K(1048576K), 0.8543338 secs] 25725K->25725K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8545040 secs
从日志看Q和我们现场的状况非常相|heapI间充Q但是perm已经C32MQ无法再q一步分配空_直接Djvm频繁做Full GCQ控制台也开始抛出OOMQPerm引v的回攉是full gcQ，q样看基本我们判断是Perm太小Q导致无法加载classesD?
和客h通之后，我们本来打算q一步验证（在生产环节打开PrintGCDetailQ获取详l的GC logQ，后面仔细查nohup.out,发现里面已经抛出?OutOfMemoryError:PermGen SpaceQ至此我们确定是Perm讄不合理导致了本次事故Q和客户认之后Q我们在启动参数中加上了MaxPermSize
后面惛_中间上了集群之后Qeos加蝲了大量的jboss cache classQ这也直接解释了Z么这D|间OOM出现的频率比之前更频J的原因
q里ȝ一下，希望对碰到类似问题的tx有借鉴意义Q强烈徏议用sun jdk 1.4.2的同学升U到>=1.4.2_12Q便于对OOM问题的诊断，q加上GC log协助验证?
q里再介l一下JVM发生OOM的几U情况：
1、java.lang.OutOfMemoryError: Java heap space
q是我们q_理解的OOMQ是׃heap space实没有I间分配Q这U一般是׃内存泄漏DQ也有可能是heap space讄太小。需要具体分?
2、java.lang.OutOfMemoryError: PermGen space
jvm规范里面有定义一个method spaceQ这里主要放classes和method list和一个string poolQstring有一个internҎQ通过q个Ҏ定义的string都放在这里（好像不常用）Q这里设|不太小会导致OOMQ缺?4MQ主要由于现在应用依赖的W三方类来多Q导致这c问题频J发生，需要引起重?
3、Requested array size exceeds VM limit
q种是由于申Larray size出了heap space大小Q比如在一?56M的heap space中申请一?12M的arrayQ这U基本都是应用bugD
4、request <size> bytes for <reason>. Out of swap space?
q种是由于heap size讄相对于系l物理内存太大，Dpȝswap space不Q这U的解决办法是减小heap size大小
5?lt;reason> <stack trace> (Native method)
q种估计是最ȝ的了Q也是最碰到的Q是׃jni或native methodDQ如果自己没有写q类的东西，基本可以说是jdk问题
]]>