本文讲述了作者在测试Elasticsearch和MySQL查询效率时，发现Elasticsearch表现较慢的问题及排查过程。问题源于Elasticsearch的远程调用、事务注解、内存设置和数据存储方式。通过调整，如减少远程调用、优化内存配置、简化数据结构，Elasticsearch的查询速度得到提升，证明其并不必然比MySQL慢。
最近笔者在测试elasticsearch和mysql的查询效率的时候竟然意外的发现es查询效率比mysql还慢.
es查询一个简单的语句,竟然要四五百毫秒,而mysql只需要一百多毫秒.
最初的判断:
1.es的服务器硬件资源不足:内存不够,搭建的是两台es,用作日志收集存储,每台的es内存设置的是2g(最后查到es的内存最好设置为服务器内存的一半以内.然后查看服务器内存为16g,然后我就设置了es的内存为7g,发现查询效率还是不如mysql)
2.es服务器的系统负载比较高.四核的cpu,竟然负载到了5到6,想着应该是两台服务器都搭建了es,kafka,kibana,logstash,zookeeper导致的负载变高 的.然后询问阿里云得知我的ubuntu系统内核查询如下:
该内核存在一个bug,就是https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg5697979.html
发现Ubuntu官方有发布过一个BUG，目前ubuntu18系统有将usleep以及nanosleep统计计算到cpu load中，因此会存在这种问题现象(也就是系统负载比较高,即使啥也没运行,也会很高),但是不影响使用.想要升级的话只能自己手动升级内核.
3.采用的spring-data-elastisearch进行的复杂查询(不认为有多复杂啊),如下:难道是排序造成的(测试了没啥大改变)
最低0.47元/天 解锁文章
141
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
