本文共 924 字，大约阅读时间需要 3 分钟。

最近遇到一个比较怪异的问题:

一个从HDFS读取计算好的数据写入ES的任务,3E条(134.6G)左右的数据量,正常同步时间为36min左右,但是时不时出现同步时间翻了好几倍的情况

首先怀疑是hadoop集群或者spark资源分配问题,(因为之前出现过集群配置问题导致读取HDFS文件慢的问题)于是在同步任务同时间做了一些读取相同文件夹下相同文件注释掉写入ES操作的测试:

发现读取HDFS文件都是40s左右,排除读取文件的原因 同时观察到ES集群在写入的时间, 网络流量较高(左边框是1月29日慢的时候,右边框是1月30日正常情况) IO很低 建立的TCP连接一直不释放,访问ES集群相应也很慢 在运维的协助下查看日志 发现任务线程有很多同步锁等待的情况,怀疑是多线程切换问题, 于是由原来的30个excutor 每个excutor 3核改为申请100个excutor 每个excutor 1核 (30个excutor就是开启30个yarn container = 开启30个JVM执行任务 3核就是每个JVM分配三个执行线程 共有90个task可以同时执行) 调整后仍然出现了卡顿问题 于是去查看ES日志,发现出问题的日期日志文件都很大:

里面大量在打:

然后发现原先结果应该为3.1E的数据,写入ES后变为1.9E 查看ES的字段"s23" 为"网站首次上架时间" 然后去查询index的mapping 发现有问题的index的s23的数据类型为"date",没问题的数据类型为text : 由于创建索引的时候没有对索引指定mapping,都是在数据写入的时候自动生成 所以当一天的第一条数据的s23不为空时,ES根据数据"yyyy-MM-dd"自动将这个字段解析成date格式,导致数据中s23为空的数据写入失败,既造成了数据丢失,又导致了在同步数据时一直在处理异常,JVM频繁发生FullGC 而第一条写入的数据为空时,ES将s23解析为text,则不会有问题

解决方案: 创建索引时 指定mapping

这个问题难以排查的原因是TCP的API报错日志都打在了服务器端，在任务客户端测难以排查，还是早日废除掉官方不建议的这种API比较好！

转载地址：http://mjzvi.baihongyu.com/