elasticsearch（35）
在一个节点的一个分片，不设置副本，测试性能在完全默认设置上记录性能数据，作为测试的基准线确保性能测试持续30分钟以上以确认长时间的性能；短时间的测试可能不会碰到segment合并和GC，无法确认这些因素的影响每次基于默认基准线更改一个参数，如果性能有提升就保留设置，并基于此设置做后续的测试
bulk使用建议
每个请求大小建议在5-15MB，逐步增大测试,当接收到EsRejectedExecutionException，就说明已经到达节点的瓶颈了，就需要减少并发或者升级硬件增加节点当写入数据时，确保bulk请求时轮询访问所有节点，不要发送所有请求到一个结点导致这一个节点要在内存存储所有请求的数据去处理
优化磁盘IO
使用SSD使用RAID 0，不用镜像备份，用replicas保证数据正确性，增大磁盘IO使用多个磁盘给Elasticsearch访问，通过在path.data中添加不使用远程存储，如NFS／SMB／CIFS；延时将成为性能瓶颈
段合并是很消耗计算资源和磁盘IO的操作，特别是出现比较大的段合并。&
当出现段合并的速度落后于索引写入的速度，Elasticsearch为了避免出现堆积的段数量爆发，会降低单个线程的索引写入速度，并且会在INFO的log里记录“now throttling indexing“
Elasticsearch默认比较保守，不想让搜索的性能被后台的段合并影响，默认的段合并速率限制比较低，默认是20MB/s，但如果使用的是SSD，可以考虑把这个参数设置到100-200MB/s
PUT /_cluster/settings
&persistent& : {
&indices.store.throttle.max_bytes_per_sec& : &100mb&
}123456123456
如果你只是用bulk导入数据而不关注查询性能，可以关闭合并的阈值
PUT /_cluster/settings
&transient& : {
&indices.store.throttle.type& : &none&
}123456123456
然后在导入完数据之后恢复成“merge”来恢复这个阈值设置
如果是机械硬盘，你需要增加下面的配置到elasticsearch.yml中
index.merge.scheduler.max_thread_count: 111
机械硬盘的并发IO性能较差，我们需要减少每个索引并发访问磁盘的线程数，这个设置会有max_thread_count＋2个线程并发访问磁盘&
如果是SSD可以忽略这个参数，默认线程数是Math.min(3, Runtime.getRuntime().availableProcessors() / 2)，对于SSD来说没有问题。
可以增大index.translog.flush_threshold_size参数，默认是200M，可以增大到如1GB。增大这个参数可以允许translog在flush前存放更大的段(segment);更大的段的创建会减少flush的频率，并且更大的段合并越少，会减少磁盘IO，索引性能更高。
如果不需要实时精确的查询结果，可以把每个索引的index.refresh_interval设置为30s，如果在导入大量的数据，可以把这个值先设置为－1，完成数据导入之后在设置回来如果在用bulk导入大量的数据，可以考虑不要副本，设置index.number_of_replicas: 0。有副本存在的时候，导入数据需要同步到副本，并且副本也要完成分析，索引和段合并的操作，影响导入性能。可以不设置副本导入数据然后在恢复副本。如果导入的文档没有唯一的ID，可以使用Elasticsearch自动生成的唯一ID
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：181590次
积分：3733
积分：3733
排名：第18617名
原创：153篇
转载：280篇
评论：14条
(6)(7)(10)(27)(13)(7)(11)(4)(8)(6)(3)(2)(1)(8)(6)(17)(41)(11)(15)(6)(11)(12)(19)(20)(11)(22)(7)(1)(43)(37)(24)(1)(2)(1)(1)(1)(5)(4)(1)下次自动登录
现在的位置:
& 综合 & 正文
IO系统性能之二：缓存和RAID如何提高磁盘IO性能
计算中我们可以看到一个15k转速的磁盘在随机读写访问的情况下IOPS竟然只有140左右，但在实际应用中我们却能看到很多标有5000IOPS甚至更
高的存储系统，有这么大IOPS的存储系统怎么来的呢？这就要归结于各种存储技术的使用了，在这些存储技术中使用最广的就是高速缓存(Cache)和磁盘
冗余阵列(RAID)了，本文就将探讨缓存和磁盘阵列提高存储IO性能的方法。
高速缓存(Cache)
在当下的各种存储产品中，按照速度从快到慢应该就是内存&闪存&磁盘&磁带
然而速度越快也就意味着价格越高，闪存虽然说是发展势头很好，但目前来说却还是因为价格问题无法普及，因此现在还是一个磁盘作霸王的时代。与CPU和内存
速度相比，磁盘的速度无疑是计算机系统中最大的瓶颈了，所以在必须使用磁盘而又想提高性能的情况下，人们想出了在磁盘中嵌入一块高速的内存用来保存经常访
问的数据从而提高读写效率的方法来折中的解决，这块嵌入的内存就被称为高速缓存。
到缓存，这东西应用现在已经是无处不在，从处于上层的应用，到操作系统层，再到磁盘控制器，还有CPU内部，单个磁盘的内部也都存在缓存，所有这些缓存存
在的目的都是相同的，就是提高系统执行的效率。当然在这里我们只关心跟IO性能相关的缓存，与IO性能直接相关的几个缓存分别是文件系统缓存(File
System Cache)、磁盘控制器缓存(Disk Controller Cache)和磁盘缓存(Disk Cache,也称为Disk
Buffer)，不过当在计算一个磁盘系统性能的时候文件系统缓存也是不会考虑在内的，因此我们重点考察的就是磁盘控制器缓存和磁盘缓存。
不管是控制器缓存还是磁盘缓存，他们所起的作用主要是分为三部分：缓存数据、预读(Read-ahead)和回写(Write-back)。
首先是系统读取过的数据会被缓存在高速缓存中，这样下次再次需要读取相同的数据的时候就不用在访问磁盘，直接从缓存中取数据就可以了。当然使用过的数据也不可能在缓存中永久保留的，缓存的数据一般那是采取
来进行管理，目的是将长时间不用的数据清除出缓存，那些经常被访问的却能一直保留在缓存中，直到缓存被清空。
读是指采用预读在没有系统的IO请求的时候事先将数据从磁盘中读入到缓存中，然后在系统发出读IO请求的时候，就会实现去检查看看缓存里面是否存在要
读取的数据，如果存在（即命中）的话就直接将结果返回，这时候的磁盘不再需要寻址、旋转等待、读取数据这一序列的操作了，这样是能节省很多时间的；如果没
有命中则再发出真正的读取磁盘的命令去取所需要的数据。
存的命中率跟缓存的大小有很大的关系，理论上是缓存越大的话，所能缓存的数据也就越多，这样命中率也自然越高，当然缓存不可能太大，毕竟成本在那儿呢。如
果一个容量很大的存储系统配备了一个很小的读缓存的话，这时候问题会比较大的，因为小缓存缓存的数据量非常小，相比整个存储系统来说比例非常低，这样随机
读取（数据库系统的大多数情况）的时候命中率也自然就很低，这样的缓存不但不能提高效率（因为绝大部分读IO都还要读取磁盘），反而会因为每次去匹配缓存
而浪费时间。
行读IO操作是读取数据存在于缓存中的数量与全部要读取数据的比值称为缓存命中率(Read Cache Hit
Radio)，假设一个存储系统在不使用缓存的情况下随机小IO读取能达到150IOPS，而它的缓存能提供10%的缓存命中率的话，那么实际上它的
IOPS可以达到150/(1-10%)=166。
首先说一下，用于回写功能的那部分缓存被称为写缓存(Write Cache)
在一套写缓存打开的存储中，操作系统所发出的一系列写IO命令并不会被挨个的执行，这些写IO的命令会先写入缓存中，然后再一次性的将缓存中的修改推到磁
盘中，这就相当于将那些相同的多个IO合并成一个，多个连续操作的小IO合并成一个大的IO，还有就是将多个随机的写IO变成一组连续的写IO，这样就能
减少磁盘寻址等操作所消耗的时间，大大的提高磁盘写入的效率。
缓存虽然对效率提高是很明显的，但是它所带来的问题也比较严重，因为缓存和普通内存一样，掉点以后数据会全部丢失，当操作系统发出的写IO命令写入到缓存
中后即被认为是写入成功，而实际上数据是没有被真正写入磁盘的，此时如果掉电，缓存中的数据就会永远的丢失了，这个对应用来说是灾难性的，目前解决这个问
题最好的方法就是给缓存配备电池了，保证存储掉电之后缓存数据能如数保存下来。
和读一样，写缓存也存在一个写缓存命中率(Write Cache Hit Radio)，不过和读缓存命中情况不一样的是，尽管缓存命中，也不能将实际的IO操作免掉，只是被合并了而已。
控制器缓存和磁盘缓存除了上面的作用之外还承当着其他的作用，比如磁盘缓存有保存IO命令队列的功能，单个的磁盘一次只能处理一个IO命令，但却能接收多个IO命令，这些进入到磁盘而未被处理的命令就保存在缓存中的IO队列中。
RAID(Redundant Array Of Inexpensive Disks)
如果你是一位数据库管理员或者经常接触服务器，那对RAID应该很熟悉了，作为最廉价的存储解决方案，RAID早已在服务器存储中得到了普及。在RAID的各个级别中，应当以RAID10和RAID5（不过RAID5已经基本走到头了，RAID6正在崛起中，看看
解下原因）应用最广了。下面将就RAID0，RAID1，RAID5，RAID6，RAID10这几种级别的RAID展开说一下磁盘阵列对于磁盘性能的影
响，当然在阅读下面的内容之前你必须对各个级别的RAID的结构和工作原理要熟悉才行，这样才不至于满头雾水，推荐查看
上面的如下条目：
将数据条带化(striping)将连续的数据分散在多个磁盘上进行存取，系统发出的IO命令（不管读IO和写IO都一样）就可以在磁盘上被并行的执行，
每个磁盘单独执行自己的那一部分请求，这样的并行的IO操作能大大的增强整个存储系统的性能。假设一个RAID0阵列有n(n&=2)个磁盘组成，
每个磁盘的随机读写的IO能力都达到140的话，那么整个磁盘阵列的IO能力将是140*n。同时如果在阵列总线的传输能力允许的话RAID0的吞吐率也
将是单个磁盘的n倍。
RAID1在容量上相当于是将两个磁盘合并成一个磁盘来使用了，互为镜像的两个磁盘里面保存的数据是完全一样的，因此在并行读取的时候速度将是n个磁盘速度的总和，但是写入就不一样了，每次写入都必须同时写入到两个磁盘中，因此写入速度只有n/2。
们那一个有n(n&=3)个磁盘的RAID5阵列来看，首先看看RAID5阵列的读IO，RAID5是支持并行IO的，而磁盘上的数据呈条带状的分
布在所有的磁盘上，因此读IO的速度相当于所有磁盘速度的总和。不过这是在没有磁盘损坏的情况下，当有一个磁盘故障的时候读取速度也是会下降的，因为中间
需要花时间来计算丢失磁盘上面的数据。
取数据的情况相对就要复杂的多了，先来看下RAID5奇偶校验数据写入的过程，我们把写入的数据称为D1，当磁盘拿到一个写IO的命令的时候，它首先会读
取一次要入的地址的数据块中修改之前的数据D0，然后再读取到当前条带中的校验信息P0，接下来就根据D0，P0，D1这三组数据计算出数据写入之后的条
带的奇偶校验信息P1，最后发出两个写IO的命令，一个写入D1，另一个写入奇偶校验信息P1。可以看出阵列在实际操作的时候需要读、读、写、写一共4个
IO才能完成一次写IO操作，也就是实际上的写入速度只有所有磁盘速度总和的1/4。从这点可以看出RAID5是非常不适合用在要大批量写入数据的系统上
RAID6和RAID5很类似，差别就在于RAID6多了一个用于校验的磁盘。就写IO速度上来说这两个是完全一样的，都是所有磁盘IO速度的总和。
在写IO上也很是类似，不同的是RAID将一个命令分成了三次读、三次写一共6次IO命令才能完成，也就是RAID6实际写入磁盘的速度是全部磁盘速度之和的1/6。可以看出从写IO看RAID6比RAID5差别是很大的。
读写速度都很好，却没有冗余保护；RAID5和RAID6都有同样的毛病就是写入的时候慢，读取的时候快。那么RAID1呢？嗯，这里要说的就是
RAID1，其实不管是RAID10还是RAID01，其实都是组合大于2块磁盘时候的RAID1，当先镜像后条带时候就称为RAID10，先条带后镜像
的时候称为RAID01。从性能上看RAID01和RAID10都是一样的，都是RAID1嘛，但是RAID10在重建故障磁盘的时候性能比RAID01
因为RAID10其实就是RAID1，所以它的性能与RAID1也就是一样的了，这里不需要再做过多的讨论。
四个性能指标的变化
IO响应时间(IO Response Time)
任何时候IO响应时间值得都是单个IO的响应时间，因此，不管磁盘是否组成了磁盘阵列，它的IO响应时间应该都是一样的。从前面的计算中我们可以看到，如
果IO响应时间在10ms左右的话是很正常的，但是当IO响应时间比这个值超出太多的时候，你就要开始注意了，很可能就意味着此时你的磁盘系统已经成为了
一个瓶颈。
综合上面两个部分的讨论我们来估算一下阵列下的磁盘总体IOPS，在这里我们先假设组成阵列的单个磁盘的随机读写的IOPS为140，读写缓存命中率都为10%，组成阵列的磁盘个数为4。
因为不管是那种阵列，磁盘的读取性能都是所有磁盘之和，所以可以得出下面的读取IOPS：
read_cache_hit_ratio
而写入性能就完全不一样了，根据上面的讨论我们可以得出下面结论：
由此我们也可以计算出写入IOPS估算公式：
write_cache_hit_ratio
acture_IO_num
write_cache_hit_ratio
acture_IO_num
write_cache_hit_ratio
acture_IO_num
write_cache_hit_ratio
acture_IO_num
实际上从通过上面的计算方法我们还可以估算当给定一个要求的IOPS的情况下，估计下使用各个阵列级别所需要的磁盘的数量。当然我们上面的计算方法只是一个估算，我们忽略很多其他的因素，得出的只是一个大概的数值，不过在实际的应用还是有一定的参考作用的。
本篇最后附送一个计算磁盘系统IOPS的网站――
，这个网站提供的计算公式还考虑了诸如阵列条带大小以及主机方面的因素，很有参考价值，至于怎么选择合适的条带大小，请参考【延伸阅读】部分。
传输速度(Transfer Rate)/吞吐率(Throughput)
实际上估算除了随机读写的IOPS也就知道了随机读写的吞吐率。对于顺序读写的呢，还是跟前一篇所讲的一样，主要受限于磁盘的限制，不能再拿IOPS来衡量了。
random_throughtput
random_IOPS
IO_chunk_size
&&&&推荐文章:
【上篇】【下篇】如何提高ES的性能
不要返回较大的结果集
ES是设计成一个搜索引擎的，只擅长返回匹配查询较少文档，如果需要返回非常多的文档需要使用Scroll。
因为ES是基于Lucene来索引和存储数据的，所以对稠密的数据更有效。Lucene能够有效的确定文档是通过一个整数的文档id，无论有没有数据都会话费一个字节存储id。稀疏主要影响norms和doc_values，一些可以避免稀疏的推荐：
避免将不相关的数据放到相同的索引中
规范的文档结构
使用相同的字段名来保存同样的数据。
不用norms和doc_values在稀疏字段
调整索引速度
使用bulk请求
并且每个请求不超过几十M，因为太大会导致内存使用过大
使用 multiple workers/threads发送数据到ES
多进程或者线程，如果看到TOO_MANY_REQUESTS (429)和EsRejectedExecutionException则说明ES跟不上索引的速度，当集群的I/O或者CPU饱和就得到了工作者的数量。
增加刷新间隔
index.refresh_interval默认是1s，可以改成30s以减少合并压力。
在加载大量数据时候可以暂时不用refresh和repliccas
index.refresh_interval to -1 and index.number_of_replicas to 0
禁用swapping
给文件缓存分配内存
缓存是用来缓存I/O操作的，至少用一般的内存来运行ES文件缓存。
使用更快的硬件
使用SSD作为存储设备。
使用本地存储，避免使用NFS或者SMB
注意使用虚拟存储，比如亚马逊的EBS
索引缓冲大小
indices.memory.index_buffer_size通常是JVM的0.1，确保他足够处理至多512MB的索引。
调整搜索速度
给文件系统缓存大内存
至少给可用内存的一半到文件系统缓存。
使用更快的硬件
使用SSD作为存储设备。
使用性能更好的CPU，高并发
使用本地存储，避免使用NFS或者SMB
注意使用虚拟存储，比如亚马逊的EBS
避免链接，嵌套会使查询慢几倍，而亲自关系能使查询慢几百倍，所以如果同样的问题可以通过没有链接的非规范回答就可以提升速度。
预索引数据
数值型数据不一定要映射成整形或者长整型
避免scripts
如果实在要使用，就用painless和expressions
不要强势合并正在写的索引
准备全局顺序
准备文件系统缓存
index.store.preload，如果内存不是很大会使搜索变得缓慢。
禁用不需要的功能
不需要过滤时可以禁用索引“index”：false
如果你不需要text字段的score，可以禁用”norms”：false
如果不需要短语查询可以不索引positions&indexe_options&:&freqs&
使用best_compression
使用最小的足够用的数值类型
byte,short,integer,long
half_float,float,double
阅读(...) 评论()> 博客详情
由于Solr和ElasticSearch都是基于Lucene构建的，所以他们之间有很大程度的相似性，故而他们的一些优化策略基本也是通用的，面对越来越多的海量数据，如何优化全量索引的写入性能呢？ 散仙简单总结了下面几个方向的优化策略，如有疑问，欢迎拍砖。&
（一）硬件优化：& （1）CPU加大，有利于并发写入& （2）内存提升，加大写入缓冲& （3）磁盘IO，使用SSD或者IO读写更快的磁盘& （4）网络IO，保证客户端与服务端的通信带宽充足&
（二）服务端框架优化：& （1）加大shard的数目，理论上shard越多，写入速度越快& （2）设置较大的索引flush触发条件，ramBufferSizeMB 或者 maxBufferedDocs& （3）写索引时，关闭副本，因为同步索引会大大降低写入速度& （4）监控GC，调整JVM参数& 如果Full GC频繁，加大JVM堆内存，& 如果Yong GC频繁，加大新生代的比例，如果使用的是CMS垃圾收集器，必要时，可以关闭survive区，避免survive区和Eden区来回拷贝& （5）尽量使用稳定的新版本如JDK和框架本身& （6）内存大的，可以尝试G1垃圾收集器&
（三） 客户端优化& （1）如果公司有大数据部门，可以使用Hadoop或者Spark分布式集群构建索引& （2）如果公司没有大数据产品，可以使用多线程或者多进程并行构建索引& （3）使用批量提交& （4）减少commit次数，让服务端控制flush索引，索引完成之后，可手动commit一次。&
有什么问题可以扫码关注微信公众号：我是攻城师(woshigcs)，在后台留言咨询。& 技术债不能欠，健康债更不能欠， 求道之路，我们同行。&
人打赏支持
码字总数 110832
支付宝支付
微信扫码支付
打赏金额: ￥
已支付成功
打赏金额: ￥}