• 线程池 最大线程数


    一个flume agent异常的解决过程记录 - 施文涛 - 博客园 https://www.cnblogs.com/dongqingswt/p/5287778.html

    一个flume agent异常的解决过程记录

    今天在使用flume agent的时候,遇到了一个异常,  现把解决的过程记录如下:

    问题的背景:

    我使用flume agent 来接收从storm topology发送下来的accesslog , 做本地文件落盘。flume配置文件如下:

    #用于syslog和accesslog的本地文件滚动。
     
    a1.sources=r1
    a1.sinks = sink1
    a1.channels = c1
     
    #thrift source;
    a1.sources.r1.type= thrift
    a1.sources.r1.channels = c1
    a1.sources.r1.bind = 127.0.0.1
    a1.sources.r1.port = 8081
     
     
     
    #先用内存通道测试。
    #a1.channels.c1.type = memory
    #a1.channels.c1.capacity = 10000000
    #a1.channels.c1.byteCapacity = 524288000
     
    a1.channels.c1.type = file
    a1.channels.c1.checkpointDir=/Users/dongqingswt/workdir/logs/checkpoint
    a1.channels.c1.dataDirs = /Users/dongqingswt/workdir/logs/datadir
     
     
     
    #使用自定义的文件滚动sink
    a1.sinks.sink1.type=  com.beibei.datahamal.flume.extend.sink.roll.FileRollSink
    a1.sinks.sink1.channel = c1
     
     
     
     
    启动flume agent以后, thrift source在本机建立套接字监听,然后用flume-ng-sdk提供的RpcClientFactory 创建thrift rpc client , 进行消息发送的压测。
    发现rpcclient 发送消息到一定量(100000) 时, FileRollSink就无法从memory channel拉取数据了, 而thrift rpc client 也得到了如下异常:
    Exception in thread "main" org.apache.flume.EventDeliveryException: Failed to send event.
    at org.apache.flume.api.ThriftRpcClient.append(ThriftRpcClient.java:155)
    at com.beibei.datahamal.flume.extend.sink.rolling.FilerRollSinkSender.main(FilerRollSinkSender.java:42)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
    Caused by: java.util.concurrent.TimeoutException
    at java.util.concurrent.FutureTask.get(FutureTask.java:201)
    at org.apache.flume.api.ThriftRpcClient.append(ThriftRpcClient.java:134)
    ... 6 more

     查看源码, 发现thrift client有一个20s的请求超时,这时候 , 查看thrift 错误日志,发现了如下异常:

    java.lang.OutOfMemoryError: unable to create new native thread
    at java.lang.Thread.start0(Native Method) ~[na:1.7.0_45]
    at java.lang.Thread.start(Thread.java:713) ~[na:1.7.0_45]
    at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:949) ~[na:1.7.0_45]
    at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1360) ~[na:1.7.0_45]
    at org.apache.thrift.server.TThreadedSelectorServer.requestInvoke(TThreadedSelectorServer.java:306) ~[libthrift-0.9.3.jar:0.9.3]
    at org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:210) ~[libthrift-0.9.3.jar:0.9.3]
    at org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.select(TThreadedSelectorServer.java:586) ~[libthrift-0.9.3.jar:0.9.3]
    at org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:541) ~[libthrift-0.9.3.jar:0.9.3]

    直观的看这个异常,会让人想到是堆内存不够用, 调节-Xmx1024m 参数以后,问题依旧。

    接着用jconsole attach到flume agent这个进程,查看堆内存的使用量, 远没有达到预设的xmx阈值。

    但是·有一个表现就是线程数猛涨到2000以后,直接掉到了20左右,为什么会创建这么多线程呢, 都是什么线程呢?

    结合thrift source 的源码, 发现thrift server 采用的也是java nio   , 有SelectorThread做socket的read/write 就绪select 

    AcceptorThread做socket的accept的select ,而socket读就绪以后,收到的FrameBuffer会被包装成一个Runnable丢到线程池处理(查看

    TThreadedSelectorServer的304 行),代码如下:
    protected boolean requestInvoke(FrameBuffer frameBuffer) {
    Runnable invocation = getRunnable(frameBuffer);
    if (invoker != null) {
    try {
    invoker.execute(invocation);
    return true;
    } catch (RejectedExecutionException rx) {
    LOGGER.warn("ExecutorService rejected execution!", rx);
    return false;
    }
    } else {
    // Invoke on the caller's thread
    invocation.run();
    return true;
    }
    }

    这个任务invocation的处理逻辑是在ThriftSource的ThriftSourceHandler定义的,也就是把thrift flume event直接丢到memchannel以后返回。起初 ,我怀疑是不是flume event丢到memchannel处理太慢(比如有线程死锁),导致线程堆积, 但后面换成file channel
    问题依旧,于是继续看jconsole上thrift 的Flume 线程,因为线程工厂在创建线程的时候,指定了线程名:
    ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat(
    "Flume Thrift IPC Thread %d").build();
    if (maxThreads == 0) {
    sourceService = Executors.newCachedThreadPool(threadFactory);
    } else {
    sourceService = Executors.newFixedThreadPool(maxThreads, threadFactory);
    }

    所以, 查看这些线程发现这些线程:
    堆栈跟踪:
    sun.misc.Unsafe.park(Native Method)
    java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
    java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
    java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    java.lang.Thread.run(Thread.java:744)
     
    说明线程池中的这些线程都在等任务工作, 既然大量的线程都在等任务,为什么还要创建这么多线程呢?是不是因为超过了单进程最大可建立的线程数呢,
    结合ThriftSource源码,发现不指定最大线程数时, thrift server的线程池的确是不停的新建线程,而maxThreads又是一个Integer.MAX_VALUE,
    if (maxThreads == 0) {
    sourceService = Executors.newCachedThreadPool(threadFactory);
    } else {
    sourceService = Executors.newFixedThreadPool(maxThreads, threadFactory);
    }


    试着在flume 配置文件中指定最大线程数:
    a1.channels.r1.threads=10

    问题解决。
     这个问题的解决也让我们反思线程池的使用,不要设定太大的最大线程数。



  • 相关阅读:
    一次select一个socket的测试结果
    一次select多个socket的测试结果
    NFS服务器的工作原理
    静态局部变量
    openstack controller ha测试环境搭建记录(十一)——配置neutron(网络节点)
    openstack controller ha测试环境搭建记录(十)——配置neutron(控制节点)
    openstack controller ha测试环境搭建记录(九)——配置nova(计算节点)
    openstack controller ha测试环境搭建记录(八)——配置nova(控制节点)
    openstack controller ha测试环境搭建记录(七)——配置glance
    openstack controller ha测试环境搭建记录(六)——配置keystone
  • 原文地址:https://www.cnblogs.com/rsapaper/p/9374267.html
Copyright © 2020-2023  润新知