分享未来 ^Internet _Technology

近日在elasticsearch按照网上的教程添加拼音支持后发行搜索性能衰减非常大，以前几百万的数据搜索关键字也只需要三四是毫秒，加入了多字段的拼音支持后搜索指定字段性能衰减了6-8倍。类似于网上的配置如下：

在索引分词器中配置如下：

这种模式配置的字段映射会极大的降低搜索性能，如果想用拼音搜索关键字建议单独设立一个独立的字段来做，不要用multi_field复合字段的方式来配置，这样会大大降低在指定字段中搜索的性能，我猜测如果使用nGram方式来生成分词，会导致生成的token非常多，导致搜索匹配的数据太多导致查询太慢。

在使用elasticsearch-rtf 2.2.0版本时使用analyze命令测试配置的自定义分词器是否生效，结果运行后日志报错，我测试的url命令如下：

http://10.0.18.123:9200/_analyze?text=中文测试&analyzer=ik_syno

[code="plain"]
[ERROR][transport ] [Cassiopea] failed to handle exception for action [indices:admin/analyze[s]], handler [org.elasticsearch.action.support.single.shard.TransportSingleShar[email protected] ]
java.lang.NullPointerException
at org.elasticsearch.action.support.single.shard.TransportSingleShardAction$AsyncSingleAction.perform(TransportSingleShardAction.java:195)
at org.elasticsearch.action.support.single.shard.TransportSingleShardAction$AsyncSingleAction.access$700(TransportSingleShardAction.java:115)
at org.elasticsearch.action.support.single.shard.TransportSingleShardAction$AsyncSingleAction$1.handleException(TransportSingleShardAction.java:174)
at org.elasticsearch.transport.TransportService$DirectResponseChannel.processException(TransportService.java:821)
at org.elasticsearch.transport.TransportService$DirectResponseChannel.sendResponse(TransportService.java:799)
at org.elasticsearch.transport.TransportService$4.onFailure(TransportService.java:361)
at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:39)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
[/code]

查询google得知为最新的bug一枚，https://github.com/elastic/elasticsearch/pull/15447 ，做个记号。测试的时候需要在设置的索引上运行analyze来避免这个bug被触发。

http://10.0.18.123:9200/indexName/_analyze?text=中文测试&analyzer=ik_syno

今日整合git到jenkins是遇到一个极其坑爹的问题，在工程中添加git地址同时配置连接用户名和密码后，老是提示类似如下错误

Failed to connect to repository : Command "git config --local credential.helper store --file=/tmp/gitXXXXXXXXXXXXXXXXX.credentials

我在jenkins中用的git版本是centos6.3自带的1.7的版本，导致jenkins始终不能正常执行git参数，故升级git版本到最新版本后问题解决。请注意就算使用jenkins自带的插件中的git版本也有可能遇到类似问题，请自行编译安装最新版本的git即可，btw我现在用的版本是git-2.4

      今日捣鼓cubieboard开发板，打算通过netbeans远程开发主机模式将linux c/c++远程编译在arm板上。以前笔者用的是Netbeans 7的版本，是可以完美运行编译环境的，但是今日升级到8.0.2版本后就无法配置C++构建主机了，填写好IP和账号密码怎么也没法识别到开发板上的gcc环境,提示为None()。查阅Netbeans官方的bugzilla记录（https://netbeans.org/bugzilla/show_bug.cgi?id=245243），发现也有好多人反馈和笔者一样的问题，在arm开发板上无法配置构建主机。于是逐篇翻阅反馈记录发现了一些解决问题的方法，估记录下来。

netbeans在配置远程主机的时候会在远程linux的/var/tmp目录下创建一个和ssh连接的账号名相关的目录，比如我用root连接主机，那么会创建dlight_root名字的目录。进入这个目录会发现在其子目录下会创建一个pty的二进制文件，我们用ldd的方式去跟踪这个二进制可执行文件所调用的so时会发现：

其调用的libc动态链接库路径为/lib/arm-linux-gnueabi/libc.so.6。

       我们可以看到这里的so放在arm-linux-gnueabi的目录下，这个目录是什么含义呢？查阅资料可知这个目录存放的是arm体系中的armel浮点运算单元模式，而如果我们的远程主机系统中没有此so文件，那么pty这个可执行文件就无法正常运行，也就会导致我们的构建主机配置失败，导致怎么都无法识别到我们的gnu开发环境，同时我们配置samba的映射目录也是会失败的。因此当我们的Netbeans C++构建主机配置失败的时候我们首先去远端确认pty文件是否能正常执行。

        找到了原因就好办了，我的cubieboard开发板默认只安装了armhf浮点运算的libc库，没安装armel版本的，故导致pty文件运行的失败。执行

[code="bash"]
apt-get install libc6:armel
[/code] 

命令即解决问题。