1.数据库最大连接数太小导致报错

Ø发现：从tomcat日志catalina.out中发现此报错，初步怀疑mysql配置文件中max_connections过小，vi /etc/my.cnf ，发现这个值仅为10。

Ø分析：一般来说，max_used_connections/max_connections*100%，在85%左右算比较理想。用show status like "%max_used_connection%"查看，max_used_connectons仅为11。

Ø解决：按照max_used_connections/max_connections*100%=85%，最大连接数需设置为13，但考虑到与最初的值10差别不大，决定设置的大一点，这里设为100，然后重启mysql，问题得到解决。

2.数据库communications link failure

Ø发现：从tomcat日志catalina.out中发现此报错，根据报错信息，问题同样出在mysql。

Ø分析：应用程序和数据库建立连接，如果超过8个小时，应用程序不去访问数据库，数据库就会出现断掉连接的现象，这时再次访问就会抛出异常。

Ø解决：涉及两个参数interactive_timeout和wait_timeout，默认是8小时，改为24小时(86400秒)。vi /etc/my.cnf， 在[mysqld]区域添加这两项，保存之后，重启mysql，问题得到解决。

3.Linux内核：java.net.SocketException 打开的文件过多

Ø发现：：在JMeter的查看结果树中发现此报错

Ø分析：：属于linux内核问题，涉及以下2个参数：

noproc：某用户被允许开启的最大进程数

nofile某用户被允许打开的最大文件数

Ø解决：：vi /etc/security/limits.conf，当前设置的为102，数值太小，这里设置为10240，保存之后，重启虚机，问题得到解决。

4.首页接口存在慢查询

Ø发现：从慢查询日志中，利用如下语句：

mysqldumpslow -s t -t 5 /var/log/mysql/slow_query_xiaoqiang.log

筛选出耗时最多的5条语句，查询时间均大于要求的1s

Ø分析：使用explain语句进一步分析，发现type、key、rows、Extra这几个字段均符合慢查询的特征

说明：

type：一般取值all、index、range、ref、eq_ref、const、null(从左往右，最差-->最好)

key：Null表示没有使用索引

rows：此查询一共扫描了多少行(值越大越不好)

Extra：出现using filesort、using temporary表明效率不好

通常，sql语句效率不高，有以下两个原因：

第一：sql语句本身的问题，比如大sql，连表查询等；

第二：索引问题，没有加索引，或者索引失效(不起作用，或起反作用)

因为这里没有加索引，所以怀疑有可能是没加索引导致的慢查询。

Ø解决：对表d_product中的add_time加索引，然后再次运行测试，慢查询日志中不再有不满足条件的语句。再次使用explain分析，语句性能好了很多。

5. 存在内存泄漏

Ø发现：利用JConsole监控JVM，下图可以看出，回落点不断抬高，说明存在内存泄漏，长期下去可能会导致OOM。

Ø分析：内存泄漏的根本原因，是因为垃圾回收时那些无任何引用的对象所占用的内存空间没有被回收造成的。

有两个方向去排查，一是检查JVM和GC的相关参数是否设置合理，二是去排查代码。

先检查JVM和GC的参数设置，发现并没有设置关键参数，如下：

Ø解决：尝试配置JVM关键参数、GC参数，如下：

再次运行测试，基本上解决了这个内存泄漏的问题，如下：

6.无效的404请求

Ø发现：通过前端页面，F12，发现有好多404无效请求

Ø分析：如果能减少这些无效的http请求数，有利于提升性能。

Ø解决：确认这些404请求，如果仍有用，就修复；如果无用，就删除，从而减少请求，提升性能。

7. 前端页面存在待优化项

Ø分析：使用PageSpeed分析，存在以下6个问题

Ø分析：这些是前端页面存在的问题，如果能优化，系统的整体性能会提升。

Ø解决：根据PageSpeed给出的建议解决。