solr一次性重建所有内容的索引引发的问题及优化方案 solrreindexnginxproxy_bufferingtimeout

一、设定应用布署环境为Nginx+Tomcat

 

二、问题集：

1、Nginx下504 Timeout出错或Length出错

2、Nginx下502 Conntect Refused出错及solr使用域名时的安全问题

3、Java Heap Out of Memory出错

 

三、问题详细分析

1、由于请求时间太长，导致请求时间过期；在Nginx的缓存设置太小，导致Length出错

2、solr使用域名后，需要加上安全控制配置，这时需要确保当前的布署应用的ip是被允许访问solr的，否则会出现502错误。

3、由于一次性取出内容的数据列表对象太大，导致内存溢出。

 

四、问题的解决

1、nginx配置片短

 

server{

        listen 80;

        server_name sou.caidao8.com;//配置成域名访问  说明1

 

    location / {

 

        //ip限制  说明1

        deny 192.168.1.1;

        allow 192.168.90.0/24;你允许的内部外段

        allow ip;你指定的ip;

        deny all;

 

 

        proxy_pass http://192.168.90.24:8080;

        proxy_buffering off;//此处解决Length问题  说明2

        proxy_set_header        Host            $host;

        index index.html;

        client_max_body_size    1024m;

        #client_body_buffer_size 128k;

        //以下解决超时问题   说明3

        proxy_connect_timeout   6000;

        proxy_send_timeout      6000;

        proxy_read_timeout      6000;

       }

}

当然相关的应用调用sou.caidao8.com时，也要做相关的timeout配置    说明3

 

2、tomcat connector配置片段

<Connector executor="tomcatThreadPool"

               port="8080" protocol="HTTP/1.1" URIEncoding="UTF-8"

               maxHttpHeaderSize="8192"

               maxThreads="5000" minSpareThreads="1000"

               enableLookups="false" redirectPort="8443" acceptCount="3500"

               connectionTimeout="600000"   说明3 disableUploadTimeout="true"   compression="on" compressionMinSize="2048"

   compressableMimeType="text/html,text/xml,application/x-javascript,text/javascript,text/css,text/plain"

    />

 

3、为防止内存溢出，需指定jvm以下参数较大值，比如 -Xms1024m -Xmx1024m  说明4

 

说明1：solr支持分布式布署，使用域名调用更加灵活和便于分布式的实现。另外solr提供后台管理，若应用布署在远程机房，如果不使用域名，造成无法访问solr服务。由此还是有必要提供域名，但是这给solr的安全带来隐患，因此需要过虑和限制ip，比如我们这里只允许远程机房内部网段和公司的ip可访问solr域名。这样就达到了solr服务的安全性，又方便于以后分布式扩展及工作环境下访问solr的后台管理。

说明2：由于内容较大，需设置proxy_buffering off;

说明3：由于solr服务及其他调用solr服务的应用是在一个请求链上，因此相关的请求时间都需要设大。看上面的说明3标志，至少有三个地方需要相关的timeout设置

 

五、应用优化 

以上方法，虽然一时避免问题的出现，但如果数据量再次扩大，可能还是没有根本解决问题。需要从进一步优化应用。优化办法

1、尽可能使用增量重建索引，由于增量索引数据量小，可避免以上所有问题。

2、即使全文索引重建索引无法避免，必须按业务分段增量重建，比如每次取2000条记录，不要形成java大对象，这样也可避免以上所有问题。

 

六、在解决问题的过程中，一度尝试使用nginx HttpChunkinModule来解决问题，低版本的nginx需要安装 HttpChunkinModule，因此直接升级nginx到1.4.1版本，但此时设置chunkin on;重起nginx无法生效；

         最终在http://serverfault.com/questions/159313/enabling-nginx-chunked-transfer-encoding/187573#187573找到了解决问题的关键"proxy_buffering off;"//此处解决Length问题，也就没有必要进一步去研究HttpChunkinModule。

         进一步了解在HttpChunkinModule http://wiki.nginx.org/HttpChunkinModule