GeTrace系统的所有搜索都是用ElasticSearch来做的，在使用ElasticSearch的过程中碰到了一些问题，这里记录一下。
一 . 在查找调用链的时候。整体数据量大（每天60G * 7 = 420G），但是结果集比较少(只有几百行)的时候，查询时间经常会超过1分钟，慢的甚至需要5，6分钟.
优化1：经过深入测试发现，是因为batchSize设置过大（一开始设置为Integer.Max），具体原因还未分析过
SearchRequestBuilder searchRequestBuilder = client.prepareSearch(indices).setTypes(type)
.setQuery(builderQueryBuilder(matches)).setSearchType(searchType).setScroll(new TimeValue(500000)).setSize(batchSize)；
优化2：业务上做优化，原先查找调用链的时候是查找所有日志的，现在设置为默认查找当天日志，如果当天日志查不到，再查找所有日志。这样查找当天的调用链的时候都是非常快的
优化后大部分查询都在30秒以内
二. 在查询应用的接口调用分析数据时，如果搜索的时间跨度很长，并且数据是一次性读入到内存，这样就可能会出现内存不够的情况
优化1： 为了解决这个问题，采用了分批查询接口，每次查询500条数据，因为业务上需要对日志做排序，在查询的时候需要在查询接口上添加排序参数
三. 随着调用链日志量的增多，经常会出现Redis日志堆积的情况。调用链日志写入EL的速度在2000-3000行每秒。 经过分析，堆积的原因可能在两方面，一是EL集群本身性能需要优化，二是logstash写入EL时可能发生了阻塞。
优化1：修改了EL的配置，让EL刷新日志的时间变为30分钟
优化2：通过日志分析logstash经常会出现Full GC，因为日志在流过logstash的时候，会创建很多临时对象，如果年轻代过小的话，会导致年轻代很快就被塞满，从发生Yong GC，多次Yong GC之后，本来是很快就会被释放的临时变量也会被迁移到年老代。导致年老代频繁被塞满，从而经常发生Full GC。解决的办法是调大年轻代的比例，让临时变量在年轻代尽量多保留一段时间，这样当Yong GC的时候就可以释放掉很多临时变量。