java程序偶尔卡顿,并发访问超过一定数字就偶尔会卡顿

本文描述了一个Java Web应用程序在并发访问量较大时偶尔出现卡顿的问题。通过对日志分析,怀疑与HTTP请求头解析错误和数组越界有关。通过监控在线人数,发现并发访问量可能达到200+,对系统性能提出较高要求。调整Tomcat配置如maxThreads、acceptCount和maxConnections,以及优化内存和网络资源,尝试解决问题。作者还探讨了线程池大小对CPU效率的影响,并提出开启多个Tomcat实例和使用负载均衡的可能解决方案。

现状描述:

平台注册人数3W,使用起来大部分时间正常,偶尔会出现卡顿,卡顿后系统报错,过几分钟后恢复。

由于日志较多,猜测卡顿时候报错的日志为

INFO: Error parsing HTTP request header
 Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.ArrayIndexOutOfBoundsException

看上去数组越界,也不好定位是哪里数组越界的。

由于系统特殊性,同时访问量比较大,就做了个在线人数监控,看到底是不是并发访问问题。

--------------------------------------------------

javaweb中实现在线人数统计https://www.cnblogs.com/tianguook/p/6115695.html】方法如下:

session并不是浏览器关闭时销毁的,而是在session失效的时候销毁下列代码就是监测session创建、销毁

package com.my.count;

import javax.servlet.http.*;

public class SessionCounter implements HttpSessionListener {

    private static int activeSessions = 0;
    //session创建时执行
    public void sessionCreated(HttpSessionEvent se) {
        activeSessions++;
    }
    //session销毁时执行
    public void sessionDestroyed(HttpSessionEvent se) {
        if (activeSessions > 0)
            activeSessions--;
    }
    //获取活动的session个数(在线人数)
    public static int getActiveSessions() {
        return activeSessions;
    }

}

接下来就是配置web.xml

<listener>
      <listener-class>
          com.my.count.SessionCounter  //这里是包名加类名
      </listener-class>
  </listener>

下面属性是session失效30分钟

  <session-config>
    <session-timeout>30</session-timeout>
  </session-config>

接下来就可以在jsp页面中使用

<%@ page language="java" import="java.util.*" pageEncoding="utf-8"%>
<%@ page import="com.my.count.SessionCounter"%>
<%
String path = request.getContextPath();
String basePath = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/";
%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <base href="<%=basePath%>">
    
    <title>My JSP 'ApplicationTest.jsp' starting page</title>
    
    <meta http-equiv="pragma" content="no-cache">
    <meta http-equiv="cache-control" content="no-cache">
    <meta http-equiv="expires" content="0">    
    <meta http-equiv="keywords" content="keyword1,keyword2,keyword3">
    <meta http-equiv="description" content="This is my page">
    <!--
    <link rel="stylesheet" type="text/css" href="styles.css">
    -->

  </head>
  
  <body>
        在线人数为:<%=SessionCounter.getActiveSessions() %>
  </body>
</html>

--------------------------------------------------------------

session释放用到参数:

通过监控程序两个小时在线数为2000+,按照10%的并发,就有200人。对网络和内存的要求比较高。

配置tomcat的访问量

修改:server.xml

<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
               connectionTimeout="20000"
           maxHttpHeaderSize="900000"
               maxThreads="1600"
               acceptCount="2000"
           maxConnections="10000"
               redirectPort="8443" URIEncoding="UTF-8"/>

牵涉到访问量的参数为maxThreads、acceptCount、maxConnections三个参数进行设置。

服务器配置:16核 16G,网络100M(共享)

转载:https://blog.youkuaiyun.com/jackpk/article/details/32137483

其中最后两个参数意义如下:

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

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

connectionTimeout

网络连接超时,假设设置为0表示永不超时,这样设置隐患巨大,通常可设置为30000ms,默认60000ms。

这两个值如何起作用,请看下面三种情况

情况1:接受一个请求,此时tomcat起动的线程数没有到达maxThreads,tomcat会起动一个线程来处理此请求。

情况2:接受一个请求,此时tomcat起动的线程数已经到达maxThreads,tomcat会把此请求放入等待队列,等待空闲线程。

情况3:接受一个请求,此时tomcat起动的线程数已经到达maxThreads,等待队列中的请求个数也达到了acceptCount,此时tomcat会直接拒绝此次请求,返回connection refused

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的配置并没有一个最优值,一定要根据具体情况来配置。

最好的做法是:在不断测试的基础上,不断调整、优化,才能得到最合理的配置。

acceptCount的配置,我一般是设置的跟maxThreads一样大,这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。

如果设的较小,可以保证接受的请求较快相应,但是超出的请求可能就直接被拒绝

如果设的较大,可能就会出现大量的请求超时的情况,因为我们系统的处理能力是一定的。

 

https://www.jianshu.com/p/8cfaff5d4bd6  这个也可以参考下

https://blog.youkuaiyun.com/JustinQin/article/details/79530038

Windows Tomcat允许每个进程maxThreads(最大线程数)2000
Linux Tomcat允许每个进程maxThreads(最大线程数)1000

------

我把16G的内存改为32G内存,偶尔还是会有卡顿情况,证明实际没有解决问题。

还有一种可能就是网络资源被占用,我的访问量2000+,按照10%并发同时操作,就是200人,网络100M的话,每人大概500K,这个待验证。

如果不是网络的问题,还有一个猜测就是,Windows Tomcat允许每个进程maxThreads(最大线程数)2000,我启动一个tomcaat,访问量接近2000的时候,是不是受到【Windows Tomcat允许每个进程maxThreads(最大线程数)2000】的限制。

如果是,开启多个tomcat进行测试,通过nginx做tomcat的负载均衡 看是否会遇到同样的问题。

----

bug解决中,谁有更好的方案可以一起评论交流,或者发邮件6725508119@qq.com

 

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值