性能优化
jollyjumper
一点记录
展开
-
NUMA技术相关笔记
起源于在mongo启动脚本中看到numactl --interleave=all mongod ...。NUMA,非统一内存访问(Non-uniform Memory Access),介于SMP(对称多处理)和MPP(大规模并行处理)之间,各个节点自有内存(甚至IO子系统),访问其它节点的内存则通过高速网络通道。NUMA信息主要通过BIOS中的ACPI(高级配置和编程接口)进行配置,Linux原创 2013-12-06 16:33:55 · 27811 阅读 · 0 评论 -
关于numa
服务器是numa架构的,有两个node,经测试加入numactl --interleave启动searcher并没有加速。关于numa,淘宝莫枢的slides: http://www.slideshare.net/RednaxelaFX/usenuma-on-jdk6linux指出仅UseParallelGC,UseParallelOldGC可以配合-X:+UseNUMA,可以提高性能(e原创 2014-04-22 21:34:41 · 2142 阅读 · 0 评论 -
Lucene中Filter的性能问题
缘起于对geo filter的优化(http://blog.csdn.net/jollyjumper/article/details/23120197),当时模仿lucene的filter写了一个geo filter,其中getDocIdSet返回的时一个FixedSizeBitSet对象,在小的索引(1G)上测试出来性能比之前有明显提升,但在大的索引(23G)上反而比原来更慢。于是改成自己实现一原创 2014-04-13 08:56:38 · 1898 阅读 · 0 评论 -
圈图的geo query处理解决方案
一般的geo query是在一个点找附近多少米,几公里的poi点,现在有个产品可以在地图上圈一块地方找其中的poi点,“一块”其实是用户鼠标或触屏经过的点组成的多边形(可凹可凸)。目前的做法是找出x,y的最大最小四个坐标,这样构成一个矩形,但矩形不方便直接拿geo hash的grids, 所以取最长边,放大成一个矩形,再取它占用的grids,这样几个termquery最后再加个过滤操作。感觉上原创 2014-04-13 09:45:06 · 1591 阅读 · 0 评论 -
Java缓存服务器调优
搜索降级方案中xmn开始使用bizer默认的128M,非常慢。偶然改成1G,效果立马上来,但是xmx调大并没有明显效果。 100并发 200并发10G 53(17.3385) 110(25.7648)15G 53(17.7007) 111(25.5927)18G原创 2014-06-11 05:58:53 · 1972 阅读 · 0 评论 -
关于中文分词
目前全量索引17G,不到1300万document花费大约25分钟的时间(Lucene 4.0),吞吐量远远低于lucene nightly build宣称的170G/h的量。换用StandardAnalyzer,有34%的提高,比较下使用的KAnalyzer,mmseg4j1.9.2-snapshot,standardanalyzer,性能分别在1.7M/s,10M/s,20M/s这样量级。所以原创 2014-06-21 23:19:57 · 2213 阅读 · 0 评论 -
好用的OQL
jmap -dump:live,format=b,file=a.bin `cat bin/search_server.pid`jhat a.binOQL真心赞,只是jhat太慢了,增大内存不会变快反而会莫名挂掉。另外java6的oql似乎有点bug,有些应该支持的查询不能支持,java7的比较正常。原创 2015-01-09 22:07:03 · 1143 阅读 · 0 评论 -
文件广播的实现
商户搜索索引高达22G(压缩之后10G),而replication有17台,尽管现在索引机出口带宽高达2Gb/s,下载还要花费15~20分钟。用广播/组播方式可以节省出口,以及公用网络带宽, 早在两年前就有做广播工具的想法(当时是ipad会议系统,需要把文件分发到每台ipad上,ipad最多有700-800台,无线网络较差),憋了一段时间设计、整理思路、实现、调试,终于出结果了,感觉蛮有收原创 2015-01-09 23:09:30 · 1425 阅读 · 0 评论 -
direct io优化
下索引过程中,老索引仍提供服务,因此下载过程中新索引会把老索引从page cache挤出,造成性能下降。因此在下载时要使用O_DIRECT标志位做direct io,不通过page cache。原来以为只要在打开时放个O_DIRECT标志位就可以,因此用jna调用和反射构造出一个新的java FileDescriptor对象,结果发现不是这么回事。原来O_DIRECT是linux中比较新的原创 2015-11-13 17:07:11 · 1321 阅读 · 0 评论 -
记Lucene GEO Query的一点优化
目前我们使用的是Lucene 4.0,上面对GEO query的使用是这样的,索引阶段使用geo hash索引多个级别的geo grid,检索阶段获取geo grid做termquery,or起来,最后search之后在collector中按照距离做一次手动的过滤,这样做不方便的是geo query不能任意和其他query做or组合。又查看了lucene spatial中的实现,是直接确定精度原创 2014-04-07 18:05:33 · 2447 阅读 · 0 评论 -
Sun JDK 1.6中String Constructor的一个bug
Java Performance Tuning Guide中看到的: http://java-performance.info/inefficient-byte-to-string-constructor/大致是传递byte array,offset,len, 还有charset时其在内部会arrays.copyOf整个数组(而不是那个slice),这样如果数组本身很大,slice很小,byt原创 2014-04-21 21:25:17 · 1066 阅读 · 0 评论 -
HBase的Block Cache实现机制分析
原文在这里:http://www.cnblogs.com/panfeng412/archive/2012/09/24/hbase-block-cache-mechanism.htmlHBase上Regionserver的内存分为两个部分,一部分作为Memstore,主要用来写;另外一部分作为BlockCache,主要用于读。写请求会先写入Memstore,Regionserver会转载 2014-02-20 18:43:55 · 2637 阅读 · 0 评论 -
性能调优攻略
http://www.kuqin.com/system-analysis/20120620/320974.html补充:mpstat -a 1可以看多cpu的负载转载 2014-03-06 18:22:44 · 747 阅读 · 0 评论 -
Google Dense Hashmap和Sparse HashMap
google code上有个著名的hash map类库,今天看了一下文档,聊做记录:sparse hashmap: 空间高效dense hashmap:时间高效sparse hashmap使用的数组(sparsetable),按M分为一组,每组用数组存储数据(虽然链表速度更快,但空间多),bits做查找。M越大内存overhead越小,在323位机器上是2bits,64位机器上是2.5原创 2014-04-13 23:30:44 · 13567 阅读 · 0 评论 -
Linux下性能测试分析工具拾遗
1.cat /proc/loadavg得到:1.88 1.57 1.47 5/469 18927前面三个数据是load avg,是取前1,5,15的数据(与uptime,w的数据一样),代表内核中状态为R(Running)和D(Disk IO)的job平均值,如果有4个cpu,均值如果是1基本表示是使用率为25%.第四个数字表示内核正在运行的进程或线程数量(应少于等于CPU数),第原创 2014-03-16 23:35:33 · 1227 阅读 · 0 评论 -
Linux 的 splice 和sendfile系统调用
Linux内核有zero copy的函数。nginx和proftpd中用到sendfile(文件到socket),haproxy则用到slice(socket到socket),比较下来,haproxy仍然需要调用两次system call(与read,write一样),在网上没有找到相关的性能测试,如果有提高,估计是少了系统空间和用户空间的拷贝。原文:http://hi.baidu.com/w转载 2014-03-31 23:15:29 · 2975 阅读 · 0 评论 -
使用ByteRef加速String类型DocValues的加载
目前商户索引DocValues非常大,warmup时花费70-80秒(在beta环境),有62秒在加载DocValues,发现其中有54秒时间在加载string docvalues,string docvalues涉及的总数达到138M,平均一个字符串13字节,但如果只是读,只要花费大约2秒时间(之前已经通过cat加入page cache),为什么花这么多时间?大部分时间花在String(byte原创 2014-04-21 21:42:40 · 1964 阅读 · 0 评论 -
BooleanScorer和BooleanScorer2的差别
几个termquery or起来(全部and起来用ConjunctionScorer),如果collector acceptOutOfOrder返回true,默认使用BooleanScorer,它按照2048一个窗口一个窗口地计算分数,由于nextDocID没有顺序要求,速度较快。如果collector acceptOutOfOrder返回false,则使用BooleanScorer2,归并链表时原创 2014-04-08 13:36:46 · 1830 阅读 · 0 评论 -
关于Lucene Collector
Lucene Collector用于收集搜索之后的文档,可以方便做filter等,主要接口有setScorer,collect,setNextReader,acceptsDocsOutOfOrder。一般和scorer配合使用,acceptDocsOutOfOrder这个选项很重要,表明是否接受doc id乱序,返回true的话对于or操作,不需要从堆中选最小的将快很多,但对于分页时如果指定顺原创 2014-04-07 19:57:11 · 3069 阅读 · 0 评论 -
Locked-Free Data Structures笔记
Andrei Alexandrescu 07的文章:http://erdani.com/publications/cuj-2004-10.pdf03年Maurice Herlihy因为他91年的文章"Wait-Free Synchronization"被授予Dijkstra分布式计算奖,将来可能会导致硬件架构进行升级。他证明了要构建wait-free数据结构,哪些原语(primitive)是好原创 2016-12-15 21:19:26 · 443 阅读 · 0 评论