发表于: 2021-03-23 23:00:53
3 1278
今天完成的事情:
安装mysql,maven,tomcat,nginx
看了一下tomcat调优
明天计划的事情:
继续安装redis,Memcache,resin,Jetty,git
遇到的问题:
都是一些小错误,但是挺多的。很麻烦...
1.在MySQL登录时出现Access denied for user 'root'@'localhost' (using password: YES) 拒绝访问,并可修改MySQL密码
在mysql.conf中加上skip-grant-tables,跳过登录,然后重新修改密码
在修改密码过程中碰到无法修改,这时候输入命令,刷新权限:flush privileges,在修改就可以了
2.tomcat 直接在Xftp中使用记事本修改 servers.xml,报错,重装两次,然后使用vim修改servers.xml 就成功了
3.安装maven,好像会自动安装Open JDK,把我安装的Oracle JDK给覆盖了,是tomcat无法运行 卸载就可以了
4.安装nginx 报错nginx: [emerg] unexpected "}" in /usr/local/nginx/conf/nginx.conf:110
一个小问题,折腾了半个小时还是没解决
收获:
对mysql进行加固,修改端口等等之类的。参考这个:
===========
===========
Tomcat调优总结(Tomcat自身优化、Linux内核优化、JVM优化)
Tomcat自身的调优是针对conf/server.xml中的几个参数的调优设置。首先是对这几个参数的含义要有深刻而清楚的理解。以tomcat8.5为例,讲解参数。
同时也得认识到一点,tomcat调优也受制于linux内核。linux内核对tcp连接也有几个参数可以调优。
因此我们可以将tomcat调优分为linux内核优化、java虚拟机调优和tomcat自身的优化。
一、Tomcat自身优化
1. maxThreads :tomcat创建的最大线程数,也就是同时处理的请求最大并发数。默认值是200
maxThreads如何配置
一般的服务器操作都包括量方面:1计算(主要消耗cpu),2等待(io、数据库等)
第一种极端情况,如果我们的操作是纯粹的计算,那么系统响应时间的主要限制就是cpu的运算能力,此时maxThreads应该尽量设的小,降低同一时间内争抢cpu的线程个数,可以提高计算效率,提高系统的整体处理能力。
第二种极端情况,如果我们的操作纯粹是IO或者数据库,那么响应时间的主要限制就变为等待外部资源,此时maxThreads应该尽量设的大,这样才能提高同时处理请求的个数,从而提高系统整体的处理能力。此情况下因为tomcat同时处理的请求量会比较大,所以需要关注一下tomcat的虚拟机内存设置和linux的open file限制。
我在测试时遇到一个问题,maxThreads我设置的比较大比如3000,当服务的线程数大到一定程度时,一般是2000出头,单次请求的响应时间就会急剧的增加,
百思不得其解这是为什么,四处寻求答案无果,最后我总结的原因可能是cpu在线程切换时消耗的时间随着线程数量的增加越来越大,
cpu把大多数时间都用来在这2000多个线程直接切换上了,当然cpu就没有时间来处理我们的程序了。
以前一直简单的认为多线程=高效率。。其实多线程本身并不能提高cpu效率,线程过多反而会降低cpu效率。
当cpu核心数<线程数时,cpu就需要在多个线程直接来回切换,以保证每个线程都会获得cpu时间,即通常我们说的并发执行。
所以maxThreads的配置绝对不是越大越好。
现实应用中,我们的操作都会包含以上两种类型(计算、等待),所以maxThreads的配置并没有一个最优值,一定要根据具体情况来配置。
最好的做法是:在不断测试的基础上,不断调整、优化,才能得到最合理的配置。
2. acceptCount:当tomcat的线程数达到了最大时,接收排队的最大请求个数。默认值为100
官网:the maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 100.
maxThreads与acceptCount这两个值是如何起作用的呢?
情况1:接受一个请求,此时tomcat起动的线程数没有到达maxThreads,tomcat会起动一个线程来处理此请求。
情况2:接受一个请求,此时tomcat起动的线程数已经到达maxThreads,tomcat会把此请求放入等待队列,等待空闲线程。
情况3:接受一个请求,此时tomcat起动的线程数已经到达maxThreads,等待队列中的请求个数也达到了acceptCount,此时tomcat会直接拒绝此次请求,返回connection refused。
对于第3种情况,在看过一篇分析connection timeout问题产生的原因后,等待队列的请求个数这个值可能是由acceptCount参数决定,也有可能由linux内核参数net.core.somaxconn决定。
关联:我在网上看来一篇文章写分析linux上TCP connection timeout的原因,这篇文章中提到一个内核参数 net.core.somaxconn。
我就想tomcat的acceptCount与net.core.somaxconn到底是什么关系呢。
我做了一个实验,
1. 我将tomcat的acceptCount设置为3000 ,net.core.somaxconn设置为8192
那么我用ss -lt 指令查看在tomcat起的端口上的send_q值是3000 可见这是acceptCount的值。
2.我将tomcat的acceptCount设置为10000,net.core.somaxconn设置为8192
同样用ss -lt指令查看在tomcat起的端口上的send_q值是8192,可见这是somaxconn的值。
所以,我总结的是,acceptCount设置的值要一般小于net.core.somaxconn这个参数,这样acceptCount的值才会起作用。net.core.somaxconn 这个参数默认值是128 ,所以需要改这个参数值。后面再介绍改这个值的方法。
acceptCount如何配置?
我一般是设置的跟maxThreads一样大,这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。
如果设的较小,可以保证接受的请求较快相应,但是超出的请求可能就直接被拒绝
如果设的较大,可能就会出现大量的请求超时的情况,因为我们系统的处理能力是一定的。
评论