有两台服务器，配置如下：
CPU: 4核 XEON 3.0
内存：2G DDRII 667操作系统：windows 2003 server 前端：
squid 2.6 STABLE 13
apache 2.2.4
mod_jk 1.2.25
jdk 1.5.0_11
tomcat 5.5.25
apache 配置了 1000个最大连接，每个连接的最大服务次数是300
apache和tomcat通过8009端口相通信
tomcat配置了600个最大连接tomcat通过连接池和mysql通信，连接池配置的最大连接数是500后端：
mysql 5.0.45 64位
mysql配置的最大连接数是1000前端和后端通过局域网相连现象：
通过tomcat的自带manager工具发现：
出现大量的页面访问非常慢，然后Current thread count不断地上升，最终达到tomcat最大的600个连接，tomcat无法再提供服务，最终出现
Service temporary unavaliable.出现这种现象的时候tomcat的session数大概为5000左右，但是曾经达到6200的时候也没有当过！
这时候查看cpu使用率，前端的web服务器大概30%,Tomcat的内存使用率也就900mb(最大配置1024MB)
后端的mysql服务器10%左右，但是mysql的连接数很大，最大能够达到300
查看mod_jk的日志，没有异常
查看tomcat日志，也没有异常目前可能的原因分析
1、google的robot在固定时间访问大量页面，导致服务器反应不过来(但是cpu得利用率很低，TOMCAT的内存使用率也不高)
2、前端和后端的连接可能出现短暂中断，导致数据库无法访问，造成程序阻塞(但是mysql的300多个连接好像又反驳了这个推断)
3、windows server 2003的连接数达到最大(还没有通过netstat查看，暂不确定)
4、程序本省的问题，是不是数据库连接没有释放？我们使用的是开源的框架mmbase，用得人很多，这个不太确定！！我现在希望能够找到一款数据库连接池监控工具，能够监控数据库连接的状态(在web前端使用)
不知道有没有哪个dd曾经遇到过类似的问题，能够指点一下！！在下万分感谢！
CPU: 4核 XEON 3.0
内存：2G DDRII 667操作系统：windows 2003 server 前端：
squid 2.6 STABLE 13
apache 2.2.4
mod_jk 1.2.25
jdk 1.5.0_11
tomcat 5.5.25
apache 配置了 1000个最大连接，每个连接的最大服务次数是300
apache和tomcat通过8009端口相通信
tomcat配置了600个最大连接tomcat通过连接池和mysql通信，连接池配置的最大连接数是500后端：
mysql 5.0.45 64位
mysql配置的最大连接数是1000前端和后端通过局域网相连现象：
通过tomcat的自带manager工具发现：
出现大量的页面访问非常慢，然后Current thread count不断地上升，最终达到tomcat最大的600个连接，tomcat无法再提供服务，最终出现
Service temporary unavaliable.出现这种现象的时候tomcat的session数大概为5000左右，但是曾经达到6200的时候也没有当过！
这时候查看cpu使用率，前端的web服务器大概30%,Tomcat的内存使用率也就900mb(最大配置1024MB)
后端的mysql服务器10%左右，但是mysql的连接数很大，最大能够达到300
查看mod_jk的日志，没有异常
查看tomcat日志，也没有异常目前可能的原因分析
1、google的robot在固定时间访问大量页面，导致服务器反应不过来(但是cpu得利用率很低，TOMCAT的内存使用率也不高)
2、前端和后端的连接可能出现短暂中断，导致数据库无法访问，造成程序阻塞(但是mysql的300多个连接好像又反驳了这个推断)
3、windows server 2003的连接数达到最大(还没有通过netstat查看，暂不确定)
4、程序本省的问题，是不是数据库连接没有释放？我们使用的是开源的框架mmbase，用得人很多，这个不太确定！！我现在希望能够找到一款数据库连接池监控工具，能够监控数据库连接的状态(在web前端使用)
不知道有没有哪个dd曾经遇到过类似的问题，能够指点一下！！在下万分感谢！
4 用的人很多不代表什么 检查数据连接的代码 释放连接！ 即使一处不是释放 后果也不可料
寄托据库连接池监控工具，也是个办法
不过建议优化数据连接的代码 把他做的好点 就是用模式处理下
RE:数据库用的是底层的mmbase框架代码，不会有太大的问题，很多人都在用，至今也没有由于数据库连接而出现的泄漏的bug。to gl74gs48
用proxool数据库连接池,有监控功能.
RE:多谢，我试试！
发现是一个关键业务占用了太多的处理时间
那个业务单独调用大约需要900ms左右。
5个用户并发也需要3-4秒
100个用户并发访问怎会平均需要40ms看来是需要优化这个业务了！
mmbase这个框架是采用所有的表都共享键值的方式来处理主键的
有一个程序负责更新这个id原来的程序中每次插入一条记录都会update numberTable set number=number+1
这样执行那个业务需要10多个update后来配置mmbase采用缓存的方式，每插入100个记录才更新一次数据库这样处理以后，性能提升了一倍。总结：
看来，关键时候分析sql的日志记录是很有必要的，尤其是从外部现象无法找到突破口！