solr es调优化和问题排查

koflover

　　（1）TOP 显示当前进程状态，结合 ps -aux 可以看是哪一个服务。mpstat 可以看是cpu的负载
　　（2）TOP -H -u 用户名 显示该用户下 所有的线程。 还有pstree
　　（3）jstat -gc pid 1000 100 查看当前程序的GC问题
　　（4）jstack pid 看 有哪些进程是 RUNNING WAITING
　　（5）jmap -histo:live 24715 | less 查看java中内存的分配情况 jmap -heap pid 当前堆内存中分配情况
　　（6）cat /proc/net/sockstat 看当前的socket是否有异常
　　降低solr CPU和 内存的使用：
　　autowarmCount设为0，filterCache的大小都调到3000 减少内存的使用和CPU的使用
　　通过进行日志挖掘，限制最大最大可以查询的数据量，避免深分页
　　降低错误率，不要返回exception 返回 “”
　　ES优化
　　（1）多个分片放在一台服务器下（这多个分片组成的数据是完整的），有个属性可以优先设置优先读取当前服务器中的其他节点。
　　（2）缓存 set get 改为异步方法，而非同步方法
　　（3）将构建索引构建选择在请求量不大的时间段（假的读写分离），因为构建索引的时候会消耗cpu，会影响Query使用cpu.
　　（4）close 不需要的index，释放非必需index所占用的内存和CPU。
　　（5）search preference 可设置为local 避免跨机房网络传输。
　　方向：
　　是否可以做读写分离，分片的意义是不是不大
　　搜索服务中的问题：
　　（1）用线程的问题，如果请求量过多的话，线程有可能阻塞。
　　（2）打分公式中 累计取redis的时间会比较长，造成整体时间长，统计数据量，加入超时限制callable future get
　　（3）该filter的进行filter 关键字的匹配从filter中去除，只filter一些通用条件，减少query中的重复计算
　　（4）打分脚本script采用store的方式
　　（5）增加service层的缓存区间，比如用户请求20条数据，设置发送到es端为100条并进行缓存，以此减少对es频繁的访问
　　（6）挖掘搜索日志，限制size 避免深分页。
　　（7）采用游标curosr和scroll
　　（8）full gc 导致 队列中的请求过多，造成swap memeory https://www.cubrid.org/blog/maxclients-in-apache-and-its-effect-on-tomcat-during-full-gc
　　搜索的准确率和召回率：
　　（1）slop 过大 则准确率降低，但是召回率升高