1. es的scroll查询,查询如果比较集中,查询量大的话会报内存溢出
问题原因:es是jvm的,默认启动的话jvm的内存使用是128M。也就相当于如果你一个ES集群三台机器每台128M一共使用内存还不到1G,现在的机器一般都是16,32G所以造成性能浪费并且es容易出问题。
解决方案:ES启动脚本elasticsearch中增加一行,export ES_HEAP_SIZE=8G。内存大小自由分配
2.mongo-connector同步报错Read timed out. (read timeout=10),并且es比mongo的数据少,证明有些数据没有同步过来。
问题原因:查看es的日志发现并没有报错,只是相同时间段的gc日志显示,该时段发生了fullGC,gc时间是32s,默认的mongo-connector请求es的超时时间是10s,32s没有回应mongo-connector直接报错并且该时间段数据会永久丢失,及时之后mongo有update这些数据也不会同步,同步回报没有该条数据没法更新的错误。
解决方案:找到elastic2_doc_mannager中的elastic2_doc_manager.py文件,pip安装的话路径在 /usr/local/lib/python2.7/site-packages/mongo_connector/doc_managers/elastic2_doc_manager.py,也可全局搜索名称查找。找到文件后修改self.elastic = Elasticsearch(hosts=url,**client_options),修改为self.elastic = Elasticsearch(hosts=url, timeout=200,**client_options),单位是s,超时时间可自行调整。