【问题标题】:Highly Concurrent Apache Async HTTP Client IOReactor issues高度并发的 Apache Async HTTP 客户端 IOReactor 问题
【发布时间】:2016-10-21 15:53:01
【问题描述】:

应用说明:

  • 我正在使用由 Comsat 的 Quasar FiberHttpClient(版本 0.7.0)包装的 Apache HTTP 异步客户端(版本 4.1.1)来运行和执行一个高度并发的 Java 应用程序,该应用程序使用光纤在内部将 http 请求发送到多个 HTTP终点
  • 应用程序在 tomcat 之上运行(但是,纤程仅用于内部请求调度。tomcat servlet 请求仍以标准阻塞方式处理)
  • 每个外部请求在内部打开 15-20 个 Fiber,每个 Fiber 构建一个 HTTP 请求并使用 FiberHttpClient 进行调度
  • 我正在使用 c44xlarge 服务器(16 核)来测试我的应用程序
  • 我正在连接的端点抢占保持活动连接,这意味着如果我尝试通过重用套接字来维护,则在请求执行尝试期间连接会关闭。因此,我禁用连接回收。
  • 根据以上部分,这是我的光纤 http 客户端的调整(当然我使用的是单个实例):

    PoolingNHttpClientConnectionManager connectionManager = 
    new PoolingNHttpClientConnectionManager(
        new DefaultConnectingIOReactor(
            IOReactorConfig.
                custom().
                setIoThreadCount(16).
                setSoKeepAlive(false).
                setSoLinger(0).
                setSoReuseAddress(false).
                setSelectInterval(10).
                build()
                )
        );
    
    connectionManager.setDefaultMaxPerRoute(32768);
    connectionManager.setMaxTotal(131072);
    FiberHttpClientBuilder fiberClientBuilder = FiberHttpClientBuilder.
            create().
            setDefaultRequestConfig(
                    RequestConfig.
                    custom().
                    setSocketTimeout(1500).
                    setConnectTimeout(1000).
                    build()
            ).
           setConnectionReuseStrategy(NoConnectionReuseStrategy.INSTANCE).
           setConnectionManager(connectionManager).
           build();
    
  • 打开文件的 ulimit 设置超高(软硬值均为 131072)

  • Eden 设置为 18GB,总堆大小为 24GB
  • OS Tcp 堆栈也经过了很好的调整:

kernel.printk = 8 4 1 7 kernel.printk_ratelimit_burst = 10 kernel.printk_ratelimit = 5 net.ipv4.ip_local_port_range = 8192 65535 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.core.rmem_default = 16777216 net.core.wmem_default = 16777216 net.core.optmem_max = 40960 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.core.netdev_max_backlog = 100000 net.ipv4.tcp_max_syn_backlog = 100000 net.ipv4.tcp_max_tw_buckets = 2000000 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_sack = 0 net.ipv4.tcp_timestamps = 1

问题描述

  • 在中低负载下一切正常,连接被租用、关闭和池补充
  • 在某个并发点之外,IOReactor 线程(其中 16 个)似乎在死亡之前停止正常运行。
  • 我编写了一个小线程来获取池统计信息并每秒打印一次。在大约 25K 的租用连接处,实际数据不再通过套接字连接发送,Pending stat clibms 也向猛增的 30K 未决连接请求发送
  • 这种情况持续存在并且基本上使应用程序无用。在某些时候,I/O Reactor 线程会死掉,不知道什么时候,到目前为止我还无法捕捉到异常
  • lsofjava 进程,我可以看到它有数以万计的文件描述符,几乎所有文件描述符都在 CLOSE_WAIT 中(这是有道理的,因为 I/O 反应器线程死亡/停止运行并且永远不会真正关闭它们
  • 在应用程序中断期间,服务器没有严重过载/cpu 压力

问题

  • 我猜我正在某个地方到达某种边界,尽管我对它可能驻留的内容或位置一无所知。以下情况除外
  • 我是否有可能到达操作系统端口(毕竟所有应用请求都源自单个内部 IP)限制并创建一个错误,导致 IO Reactor 线程死亡(类似于打开文件限制错误)?

【问题讨论】:

    标签: java nio apache-httpclient-4.x quasar


    【解决方案1】:

    忘了回答这个问题,但我在发布问题大约一周后就知道了发生了什么:

    1. 存在某种配置错误,导致 io-reactor 仅使用 2 个线程生成。

    2. 即使在提供更多反应器线程后,问题仍然存在。事实证明,我们发出的请求主要是 SSL。 Apache SSL 连接处理将核心处理传播到 JVM 的 SSL 设施,这些设施的效率不足以每秒处理数千个 SSL 连接请求。更具体地说,SSLEngine 中的一些方法(如果我没记错的话)是同步的。在高负载下执行线程转储显示 IORecator 线程在尝试打开 SSL 连接时相互阻塞。

    3. 即使尝试以连接租约超时的形式创建压力释放阀也没有用,因为创建的积压工作太大,导致应用程序无用。

    4. 将 SSL 传出请求处理卸载到 nginx 执行得更糟 - 因为远程端点抢先终止请求,无法使用 SSL 客户端会话缓存(JVM 实现也是如此)。

      李>

    最终在整个模块前面放置一个信号量,在任何给定时刻将整个信号量限制在 ~6000,从而解决了问题。

    【讨论】:

    • 您好,我正在尝试了解如何配置 IOReactor 线程的数量。我的应用程序总是从其中一个开始。调度程序线程是通过“IOReactorConfig.custom().setIoThreadCount()”正确创建的。你能分享你的配置吗?
    • 不确定你的问题IOReactorConfig.custom().setIoThreadCount() 是什么设置了反应器线程数。如果它正常工作,您应该使用此方法设置的尽可能多的线程。请分享您的整个配置
    • IOReactorConfig.custom().setIoThreadCount() 设置调度程序线程的数量。我试图增加遍历事件循环的线程数,但这似乎不是反应器模式背后的想法,对吧?它为此使用单个线程。我的具体问题是我的应用程序的吞吐量非常差。我有空闲的 CPU 和内存,但无论调度程序线程的数量如何,http-client 似乎都以相同的速度工作。
    • 似乎我的吞吐量问题与后端服务器性能不佳有关。改正之后,蔚来的表现变得非常好。
    • @marciopd 很高兴您解决了您的问题。你提到的是“接受者线程”,我相信,是的,你通常不会看到超过一两个。
    猜你喜欢
    • 2019-08-17
    • 1970-01-01
    • 2020-07-07
    • 2018-03-02
    • 2018-08-17
    • 1970-01-01
    • 2014-01-09
    • 2018-12-10
    • 2015-11-11
    相关资源
    最近更新 更多