Q:有两个人掉到陷阱里了,死的人叫死人,活人叫什么?

TransportClient连接管理问题

Elasticsearch | 作者 zhsusn | 发布于2016年10月27日 | 阅读数:8285

请教一下,如何管理TransportClient的连接。
我用spark Streaming将实时数据插入到ES中,开始时采用单例获取TransportClient,但这样造成spark的任务延迟很多,上一个批次还没处理完,下一个就到了,数据到达后获取不到连接。
后来改为类似线程池的管理,用静态list维护一个TransportClient列表,列表最大数设置为10,这样每个服务器就最多产生10个TransportClient连接ES,但查看端口发现产生了上5百多个9300的链接,并且还在增加,而ES的Bulk列表也堆积了很多,造成拒绝访问。ES的9300连接数达到上千个.

 
问题1:spark Streaming访问ES时如何管理TransportClient的实例?
问题2:TransportClient实例个数和bulk的连接数有什么关系?
 
另外目前入库很慢,不知道和这个连接有没有关系

16/10/27 15:21:25 INFO mng.HdfsPersistHandler: --------------------HDFS write success [docs: 100000, latency: 4374 ms ]. 16/10/27 15:21:29 INFO mng.EsPersistHandler: --------------------------ES commit success [docs: 102148, latency: 17784 ms ].
 
es.png
已邀请:

medcl - 今晚打老虎。

赞同来自:

TransportClient单例不代表只有一个连接,他自己有自己的连接池的,连接堆积的根本原因来源 es 处理不过来,连接池不用动,连接再多,es 处理不过来也没有用,需要找到 es 瓶颈点优化或者扩容

zhsusn

赞同来自:

9300的socket连接数过多是问题吗?
es优化了一些参数,但没有效果,目前是10台服务器、一个master节点,一个master的备份节点,8个数据节点。日志中一个线程提交时间10W条数据需要40多秒,感觉不正常。
通过bigdesk观察,没发现瓶颈在哪儿。
 
spark Streaming运行一段时间后,发现任务delay了5分钟,但es的bulk队列并不多,Indexing requests per second 峰值为150k。 不知道是代码调用方式不对还是ES性能问题。代码见附件。
 
另外发现一个异常现象,某台服务器负载很大,不知道这是不是瓶颈,如果是采用什么方式解决。
 
 

medcl - 今晚打老虎。

赞同来自:

@zhsusn 负载很大的那台可能是瓶颈,你系统监控做了么?看看慢在什么地方

要回复问题请先登录注册