服务器 发布日期:2024/12/29 浏览次数:1
一.分析思路
1.排除本机自身原因
2.服务器性能分析
3.项目本身分析(不详细说)
4.虚拟机分析
5.数据库分析
二.详细分析方法
1.排除本机自身原因
可以使用站长工具测试网站速度。
2.服务器性能分析
使用top命令查看服务器的资源使用情况,主要分析CPU和内存的使用情况(top 命令是 Linux 下常用的性能分析工具,能够实时显示系统中各个进程的资源占用状况,默认5秒刷新一下进程列表,所以类似于 Windows 的任务管理器。):
第三行显示的是Cpu的使用情况,详细含义如下:
us---用户空间占用CPU的百分比、sy---内核空间占用CPU的百分比、ni---改变过优先级的进程占用CPU的百分比、id---空闲CPU百分比、wa---IO等待占用CPU的百分比、hi---硬中断(Hardware IRQ)占用CPU的百分比、si---软中断(Software Interrupts)占用CPU的百分比、st---Steal Time,分配给运行在主机上其它虚拟机的任务的实际CPU时间,一般只有在虚拟机OS。
第4行是当前的内存情况,服务器总内存8054352k,已使用2879468k,剩余5174884k,缓冲265728k。
我个人的理解是:当us的百分比小于50%时,是不需要去考虑服务器的配置问题的,如果服务器的us百分比长时间在70%以上时,可以考虑加强服务器的硬件配置。此外,还需要查看服务器的网络情况,下载一个大型文件基本就可以确定网络情况了。
3.项目本身分析
如果使用JDBC连接池,需要对连接池的配置进行分析(分析线程池的最大数量和释放时间等等)。
这里以C3P0为例,下面是我曾经做的一个项目的配置,如下图:
这里本来只是本地测试的配置方案,由于粗心,上线后忘记修改了,当多人访问时,会出现等待连接超时的情况,我们需要根据项目的实际情况设定合适的配置数据。
还有可能项目的设计方面不合理导致响应缓慢,这里就不详细说明了。
checkoutTimeout---当连接池连接耗尽时,客户端调用getConnection()后等待获取新连接的时间,超时后将抛出SQLException,如设为0则无限期等待。单位毫秒。默认: 0
minPoolSize---连接池中保留的最小连接数,默认为:3
maxPoolSize---连接池中保留的最大连接数。默认值: 15
maxIdleTime---最大空闲时间,设定时间内未使用则连接被丢弃。若为0则永不丢弃。默认值: 0
maxIdleTimeExcessConnections---default : 0 单位 s 这个配置主要是为了减轻连接池的负载,比如连接池中连接数因为某次数据访问高峰导致创建了很多数据连接 ,但是后面的时间段需要的数据库连接数很少,则此时连接池完全没有必要维护那么多的连接,所以有必要将断开丢弃掉一些连接来减轻负载,必须小于maxIdleTime。配置不为0,则会将连接池中的连接数量保持到minPoolSize。为0则不处理
acquireIncrement---当连接池中的连接耗尽的时候c3p0一次同时获取的连接数。默认值: 3
4.虚拟机分析
使用top指令查看虚拟机的内存占用情况,有时候可以发现虽然虚拟机占用内存的百分比不大却有明显的上限值,我们就需要去查看虚拟机的配置情况。
解决方法(以tomcat为例):
具体的数值根据实际情况而定。
5.数据库分析(MySql)
数据库的分析内容和需要考虑的方面有很多,这里只说本人遇到过的几种情况:
a.最大连接数
show variables like '%max_connections%'; 查看最大连接数
show status like 'Threads%';当前连接的使用情况
Threads_connected---打开的连接数
Threads_running---这个数值指的是激活的连接数,这个数值一般远低于connected数值
如果最大连接数的值太小可以根据实际情况进行修改,一般修改为1000即可,设置方法有两种:
1.临时设置,重启服务后将失效
2.修改数据库配置文件
在/etc/my.cnf 文件的[mysqld]下增减一行:max_connections = 1000
b.超时控制
mysql存在一项属性“wait_timeout”,默认值为28800秒(8小时),wait_timeout的值可以设定,但最多只能是2147483,不能再大了。也就是约24.85天 ,可以通过show global variables like 'wait_timeout';命令来查看。
wait_timeout的含义是:一个connection空闲超过8个小时,Mysql将自动断开该connection,通俗的讲就是一个连接在8小时内没有活动,就会自动断开该连接。由于dbcp没有检验该connection是否有效,用其进行数据操作便会出现异常。
如果是由超时控制引起的问题,不建议修改wait_timeout的值,在数据库连接的url的后面加上“&autoReconnect=true&failOverReadOnly=false”即可解决。
c.DNS反向解析
MySQL数据库收到一个网络连接后,首先拿到对方的IP地址,然后对这个IP地址进行反向DNS解析从而得到这个IP地址对应的主机名。用主机名在权限系统里面进行权限判断。反向DNS解析是耗费时间的,有可能让用户感觉起来很慢。甚至有的时候,反向解析出来的主机名并没有指向这个IP地址,这时候就无法连接成功了。 可以在配置文件里面禁止MySQL进行反向DNS解析,只需在my.cnf的[mysqld]段落中加入如下行即可:
skip-name-resolve (windows与linux下一样的)
d.表高速缓存
show global status like 'open%tables%';查看打开的表的数量:
open_tables:是当前在缓存中打开表的数量。
opened_tables:是mysql自启动起,打开表的数量。
当Opened_tables数值非常大,说明cache太小,导致要频繁地open table,可以查看下当前的table_open_cache设置:
show variables like 'table_open_cache'; 查看缓存的上限值
设置table_open_cache的值有两种方式(如果是4G左右内存的服务器,建议设为2048):
1.临时设置,重启服务后将失效
set global table_open_cache=2048;
2.修改数据库配置文件
在/etc/my.cnf 文件的[mysqld]下增减一行:table_open_cache = 2048
e.慢查询日志
记录的慢查询日志的目的是确认是否是由于某些语句执行缓慢而导致的服务器响应慢。
慢查询就不详细说了,网上可以查到很多。
不过,最后,根据我实际的项目分析,这些都没有问题,是MongoDb的CPU直接满了,注释掉就好了
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。