（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 避免跨机房网络传输。
（6）上新时间点会频繁更新doc，导致cpu利用率过高，采用timeline的方式，以时间轴的方式去判定状态。
方向：
是否可以做读写分离，分片的意义是不是不大
搜索服务中的问题：
（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 过大 则准确率降低，但是召回率升高