2013年整个三月份学习元系统很不稳定，并发人数一多系统就崩溃报out of memory的错误，而且tomcat运行一段时间也会报out of memory的错误。

第一阶段

  由于tomcat中报错是 java.SQLException:out of memory。所以开始定位为数据库的问题，重点在检查数据库本身的配置和程序中连接数据库部分。mysql本身的配置主要在my.ini文件中，思路是减少每个线程占用内存数，从而增大并发处理数。

处理过程如下：

一、2013.3.17my.ini   在2013.3.15基础上进行修改
read_buffer_size(6M---1M)

二、2013.3.18my.ini   在2013.3.17基础上进行修改

sort_buffer_size（32M---16M）：排序缓存   sort_buffer_size  一开始从32M改为4M，tomcat报排序缓冲区不足，又改成了16M
join_buffer_size（12M---4M）：连接查询缓存
read_rnd_buffer_size( 16M---8M)：随机读写缓存
这三个参数都是每线程独享内存，感觉设置的太大了
这里配置的时候也参考了 key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections 算出mysql占用的内存值；key_cache_miss_rate = Key_reads / Key_read_requests * 100%（解释：key_cache_miss_rate在0.1%以下都很好(每1000个请求有一个直接读硬盘)，如果key_cache_miss_rate在0.01%以下的话，key_buffer_size分配的过多，可以适当减少。）


三、2013.3.19my.ini   在2013.3.18基础上进行修改

max_connection  4000----2000
table_cache   16000----8000    
说明：在mysql默认安装情况下，table_cache的值在2G内存以下的机器中的值默认时256到512，如果机器有4G内存,则默认这个值是2048，但这决意味着机器内存越大，这个值应该越大，因为table_cache加大后，使得mysql对SQL响应的速度更快了，不可避免的会产生更多的死锁（dead lock），这样反而使得数据库整个一套操作慢了下来，严重影响性能。所以平时维护中还是要根据库的实际情况去作出判断，找到最适合你维护的库的table_cache值。


四、2013.3.22my.ini  在2013.3.19基础上进行修改

table_cache   8000---1024

五、my.ini 在2013.3.22基础上进行修改

key_buffer_size  512M----2G

由于数据库配置比较复杂，参数之间有相互制约条件，改动一个参数可能与之相关的其他参数也需要修改，而且针对不同的系统、程序应用也会不同，在经过一系列调整后，还是报了out of memory 错误。原因一是配置还是不合适，二可能mysql不是瓶颈所在，有其他地方如tomcat、程序处理、服务器影响了性能。

第二阶段

彭飞师兄过来指导了一次，建议可以查看导致out of memory错误的语句有哪些，分析程序如何导致了异常。余老师过来指导，了解服务器状况，一起查看各种配置、测试各个页面。解决思路是

1. 对导致out of memory 的语句进行整理修改，从程序上解决问题；===>整理了tomcat中所有导致out of memory错误的地方，分配给每人进行修改。

2. 将tomcat、应用程序和数据库统一放在一起，减小不同服务器访问之间的压力；===>将三者都集中放在了一起

3. 请海箭师兄讲一下学习元底层，了解具体配置过程；

4. 对tomcat中连接数（maxThreads）、超时时间(timeout)、占用内存（-Xxs -Xxm）进行修改，进行压力测试，观察并发情况。

第三阶段

 清明节期间，杨师兄过来一起尝试各种解决方案。进行压力测试的时候，丁师兄在Jprofile中观察占用内存、创建实例异常的方法，定位到具体程序，进行修改。再次检查学习元中hibernate相关配置，对hibernate session未关闭的地方进行检查；还原tomcat最初配置等。

在这个过程中发现，最影响性能的两个地方一是tomcat的配置，另一个就是程序处理中的不当，导致页面某些程序创建实例过多。

处理过程

1. 之前的tomcat配置

<Connector port="8070" protocol="HTTP/1.1" maxHttpHeaderSize="8192" useBodyEncodingForURI="true" minSpareThreads="25" maxSpareThreads="75" maxThreads="1000" acceptCount="800" enableLookups="false" compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" disableUploadTimeout="true"  connectionTimeout="200000" redirectPort="8444" URIEncoding="UTF-8"/>

配置后删除了minSpareThreads="25" maxSpareThreads="75" maxThreads="1000" acceptCount="800" 这两个配置。 （参照了vclass的配置）

minSpareThreads ：Tomcat初始化时创建的线程数。默认值4。
maxSpareThreads ：一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。默认值50。

maxThreads：tomcat起动的最大线程数，即同时处理的任务个数，默认值为200 

acceptCount：当tomcat起动的线程数达到最大时，接受排队的请求个数，默认值为100

这里很奇怪，从网上搜索资料：maxThreads：Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。默认值200。 可以根据机器的时期性能和内存大小调整，一般可以在400-500。最大可以在800左右。

2.  对压力测试中实例创建过多的页面程序进行优化。（还需要继续做，对主要页面进行压力测试分析）

3.  对学习元hibernate session配置了解清楚，何时该关闭session（需要大家继续讨论一下，关闭不必要的session）

学习元tomcat去掉上面配置的4个参数，对首页程序优化后，压力测试2000并发，tomcat不会挂掉，测试完后学习元可正常访问。

1. 参数配置的时候一定要慎重，要结合学习元系统并发请求、服务器性能进行调整，这也是最头疼最麻烦的，所以修改参数后需要进行压力测试，参数调整后系统性能是降低了还是提升了，实践出真知吧

2. 要做好各次修改的版本记录和修改说明（日期、出现了什么问题、为什么修改、修改参数说明、压力测试记录等），这样便于定位问题。

3. 写程序时要考虑自己的需求和实际的效率，不然之后出现问题还要优化，实际加重了工作量。

1. 知识群二级页面没有显示 我浏览的知识群、和热门知识群，这2个查询语句是否可以去掉？

2.CourseService.getInstance(),多次新建，可以用CourseService cs = CourseService.getInstance()复用，减少反复创建数据库连接。

用 select count(*) from XXX,  而不是 select * from XXX，然后再用size()方法。