docker与虚拟机性能比较

Geek小A 发表了文章 • 0 个评论 • 2322 次浏览 • 2015-10-12 19:14 • 来自相关话题

概要

docker是近年来新兴的虚拟化工具,它可以和虚拟机一样实现资源和系统环境的隔离。本文将主要根据IBM发表的研究报告,论述docker与传统虚拟化方式的不同之处,并比较物理机、docker容器、虚拟机三者的性能差异及差异产生的原理。

docker与虚拟机实现原理比较

如下图分别是虚拟机与docker的实现框架。



比较两图的差异,左图虚拟机的Guest OS层和Hypervisor层在docker中被Docker Engine层所替代。虚拟机的Guest OS即为虚拟机安装的操作系统,它是一个完整操作系统内核;虚拟机的Hypervisor层可以简单理解为一个硬件虚拟化平台,它在Host OS是以内核态的驱动存在的。
 虚拟机实现资源隔离的方法是利用独立的OS,并利用Hypervisor虚拟化CPU、内存、IO设备等实现的。例如,为了虚拟CPU,Hypervisor会为每个虚拟的CPU创建一个数据结构,模拟CPU的全部寄存器的值,在适当的时候跟踪并修改这些值。需要指出的是在大多数情况下,虚拟机软件代码是直接跑在硬件上的,而不需要Hypervisor介入。只有在一些权限高的请求下,Guest OS需要运行内核态修改CPU的寄存器数据,Hypervisor会介入,修改并维护虚拟的CPU状态。

Hypervisor虚拟化内存的方法是创建一个shadow page table。正常的情况下,一个page table可以用来实现从虚拟内存到物理内存的翻译。在虚拟化的情况下,由于所谓的物理内存仍然是虚拟的,因此shadow page table就要做到:虚拟内存->虚拟的物理内存->真正的物理内存。

对于IO设备虚拟化,当Hypervisor接到page fault,并发现实际上虚拟的物理内存地址对应的是一个I/O设备,Hypervisor就用软件模拟这个设备的工作情况,并返回。比如当CPU想要写磁盘时,Hypervisor就把相应的数据写到一个host OS的文件上,这个文件实际上就模拟了虚拟的磁盘。
对比虚拟机实现资源和环境隔离的方案,docker就显得简练很多。docker Engine可以简单看成对Linux的NameSpace、Cgroup、镜像管理文件系统操作的封装。docker并没有和虚拟机一样利用一个完全独立的Guest OS实现环境隔离,它利用的是目前Linux内核本身支持的容器方式实现资源和环境隔离。简单的说,docker利用namespace实现系统环境的隔离;利用Cgroup实现资源限制;利用镜像实现根目录环境的隔离。通过docker和虚拟机实现原理的比较,我们大致可以得出一些结论:(1)docker有着比虚拟机更少的抽象层。由于docker不需要Hypervisor实现硬件资源虚拟化,运行在docker容器上的程序直接使用的都是实际物理机的硬件资源。因此在CPU、内存利用率上docker将会在效率上有优势,具体的效率对比在下几个小节里给出。在IO设备虚拟化上,docker的镜像管理有多种方案,比如利用Aufs文件系统或者Device Mapper实现docker的文件管理,各种实现方案的效率略有不同。(2)docker利用的是宿主机的内核,而不需要Guest OS。因此,当新建一个容器时,docker不需要和虚拟机一样重新加载一个操作系统内核。我们知道,引导、加载操作系统内核是一个比较费时费资源的过程,当新建一个虚拟机时,虚拟机软件需要加载Guest OS,这个新建过程是分钟级别的。而docker由于直接利用宿主机的操作系统,则省略了这个过程,因此新建一个docker容器只需要几秒钟。另外,现代操作系统是复杂的系统,在一台物理机上新增加一个操作系统的资源开销是比较大的,因此,docker对比虚拟机在资源消耗上也占有比较大的优势。事实上,在一台物理机上我们可以很容易建立成百上千的容器,而只能建立几个虚拟机。

docker与虚拟机计算效率比较

在上一节我们从原理的角度推测docker应当在CPU和内存的利用效率上比虚拟机高。在这一节我们将根据IBM发表的论文给出的数据进行分析。以下的数据均是在IBM x3650 M4服务器测得,其主要的硬件参数是: (1)2颗英特尔xeon E5-2655 处理器,主频2.4-3.0 GHz。每颗处理器有8个核,因此总共有16个核。(2)256 GB RAM.在测试中是通过运算Linpack程序来获得计算能力数据的。结果如下图所示: 



图中从左往右分别是物理机、docker和虚拟机的计算能力数据。可见docker相对于物理机其计算能力几乎没有损耗,而虚拟机对比物理机则有着非常明显的损耗。虚拟机的计算能力损耗在50%左右。 为什么会有这么大的性能损耗呢?一方面是因为虚拟机增加了一层虚拟硬件层,运行在虚拟机上的应用程序在进行数值计算时是运行在Hypervisor虚拟的CPU上的;另外一方面是由于计算程序本身的特性导致的差异。虚拟机虚拟的cpu架构不同于实际cpu架构,数值计算程序一般针对特定的cpu架构有一定的优化措施,虚拟化使这些措施作废,甚至起到反效果。比如对于本次实验的平台,实际的CPU架构是2块物理CPU,每块CPU拥有16个核,共32个核,采用的是NUMA架构;而虚拟机则将CPU虚拟化成一块拥有32个核的CPU。这就导致了计算程序在进行计算时无法根据实际的CPU架构进行优化,大大减低了计算效率。

docker与虚拟机内存访问效率比较

内存访问效率的比较相对比较复杂一点,主要是内存访问有多种场景: (1)大批量的,连续地址块的内存数据读写。这种测试环境下得到的性能数据是内存带宽,性能瓶颈主要在内存芯片的性能上; (2)随机内存访问性能。这种测试环境下的性能数据主要与内存带宽、cache的命中率和虚拟地址与物理地址转换的效率等因素有关。以下将主要针对这两种内存访问场景进行分析。在分析之前我们先概要说明一下docker和虚拟机的内存访问模型差异。下图是docker与虚拟机内存访问模型: 



可见在应用程序内存访问上,虚拟机的应用程序要进行2次的虚拟内存到物理内存的映射,读写内存的代价比docker的应用程序高。下图是场景(1)的测试数据,即内存带宽数据。左图是程序运行在一块CPU(即8核)上的数据,右图是程序运行在2块CPU(即16核)上的数据。单位均为GB/s。 







从图中数据可以看出,在内存带宽性能上docker与虚拟机的性能差异并不大。这是因为在内存带宽测试中,读写的内存地址是连续的,大批量的,内核对这种操作会进行优化(数据预存取)。因此虚拟内存到物理内存的映射次数比较少,性能瓶颈主要在物理内存的读写速度上,因此这种情况docker和虚拟机的测试性能差别不大; 内存带宽测试中docker与虚拟机内存访问性能差异不大的原因是由于内存带宽测试中需要进行虚拟地址到物理地址的映射次数比较少。根据这个假设,我们推测,当进行随机内存访问测试时这两者的性能差距将会变大,因为随机内存访问测试中需要进行虚拟内存地址到物理内存地址的映射次数将会变多。结果如下图所示:







1图是程序运行在一个CPU上的数据,右图是程序运行在2块CPU上的数据。从左图可以看出,确实如我们所预测的,在随机内存访问性能上容器与虚拟机的性能差距变得比较明显,容器的内存访问性能明显比虚拟机优秀;但出乎我们意料的是在2块CPU上运行测试程序时容器与虚拟机的随机内存访问性能的差距却又变的不明显。针对这个现象,IBM的论文给出了一个合理解释。这是因为当有2块CPU同时对内存进行访问时,内存读写的控制将会变得比较复杂,因为两块CPU可能同时读写同一个地址的数据,需要对内存数据进行一些同步操作,从而导致内存读写性能的损耗。这种损耗即使对于物理机也是存在的,可以看出右图的内存访问性能数据是低于左图的。2块CPU对内存读写性能的损耗影响是非常大的,这个损耗占据的比例远大于虚拟机和docker由于内存访问模型的不同产生的差异,因此在右图中docker与虚拟机的随机内存访问性能上我们看不出明显差异。

docker与虚拟机启动时间及资源耗费比较

上面两个小节主要从运行在docker里的程序和运行在虚拟机里的程序进行性能比较。事实上,docker之所以如此受到开发者关注的另外一个重要原因是启动docker的系统代价比启动一台虚拟机的代价要低得多:无论从启动时间还是从启动资源耗费角度来说。docker直接利用宿主机的系统内核,避免了虚拟机启动时所需的系统引导时间和操作系统运行的资源消耗。利用docker能在几秒钟之内启动大量的容器,这是虚拟机无法办到的。快速启动、低系统资源消耗的优点使docker在弹性云平台和自动运维系统方面有着很好的应用前景。

docker的劣势

前面的内容主要论述docker相对于虚拟机的优势,但docker也不是完美的系统。相对于虚拟机,docker还存在着以下几个缺点:1.资源隔离方面不如虚拟机,docker是利用cgroup实现资源限制的,只能限制资源消耗的最大值,而不能隔绝其他程序占用自己的资源。2.安全性问题。docker目前并不能分辨具体执行指令的用户,只要一个用户拥有执行docker的权限,那么他就可以对docker的容器进行所有操作,不管该容器是否是由该用户创建。比如A和B都拥有执行docker的权限,由于docker的server端并不会具体判断docker cline是由哪个用户发起的,A可以删除B创建的容器,存在一定的安全风险。 3.docker目前还在版本的快速更新中,细节功能调整比较大。一些核心模块依赖于高版本内核,存在版本兼容问题

原文作者:chenbiaolong
 
 
分享原文地址:http://blog.csdn.net/cbl709/article/details/43955687 查看全部


概要


docker是近年来新兴的虚拟化工具,它可以和虚拟机一样实现资源和系统环境的隔离。本文将主要根据IBM发表的研究报告,论述docker与传统虚拟化方式的不同之处,并比较物理机、docker容器、虚拟机三者的性能差异及差异产生的原理。 


docker与虚拟机实现原理比较


如下图分别是虚拟机与docker的实现框架。
dvk1.png
比较两图的差异,左图虚拟机的Guest OS层和Hypervisor层在docker中被Docker Engine层所替代。虚拟机的Guest OS即为虚拟机安装的操作系统,它是一个完整操作系统内核;虚拟机的Hypervisor层可以简单理解为一个硬件虚拟化平台,它在Host OS是以内核态的驱动存在的。
 
虚拟机实现资源隔离的方法是利用独立的OS,并利用Hypervisor虚拟化CPU、内存、IO设备等实现的。例如,为了虚拟CPU,Hypervisor会为每个虚拟的CPU创建一个数据结构,模拟CPU的全部寄存器的值,在适当的时候跟踪并修改这些值。需要指出的是在大多数情况下,虚拟机软件代码是直接跑在硬件上的,而不需要Hypervisor介入。只有在一些权限高的请求下,Guest OS需要运行内核态修改CPU的寄存器数据,Hypervisor会介入,修改并维护虚拟的CPU状态。 

Hypervisor虚拟化内存的方法是创建一个shadow page table。正常的情况下,一个page table可以用来实现从虚拟内存到物理内存的翻译。在虚拟化的情况下,由于所谓的物理内存仍然是虚拟的,因此shadow page table就要做到:虚拟内存->虚拟的物理内存->真正的物理内存。

对于IO设备虚拟化,当Hypervisor接到page fault,并发现实际上虚拟的物理内存地址对应的是一个I/O设备,Hypervisor就用软件模拟这个设备的工作情况,并返回。比如当CPU想要写磁盘时,Hypervisor就把相应的数据写到一个host OS的文件上,这个文件实际上就模拟了虚拟的磁盘。
对比虚拟机实现资源和环境隔离的方案,docker就显得简练很多。docker Engine可以简单看成对Linux的NameSpace、Cgroup、镜像管理文件系统操作的封装。docker并没有和虚拟机一样利用一个完全独立的Guest OS实现环境隔离,它利用的是目前Linux内核本身支持的容器方式实现资源和环境隔离。简单的说,docker利用namespace实现系统环境的隔离;利用Cgroup实现资源限制;利用镜像实现根目录环境的隔离。
通过docker和虚拟机实现原理的比较,我们大致可以得出一些结论:
(1)docker有着比虚拟机更少的抽象层。由于docker不需要Hypervisor实现硬件资源虚拟化,运行在docker容器上的程序直接使用的都是实际物理机的硬件资源。因此在CPU、内存利用率上docker将会在效率上有优势,具体的效率对比在下几个小节里给出。在IO设备虚拟化上,docker的镜像管理有多种方案,比如利用Aufs文件系统或者Device Mapper实现docker的文件管理,各种实现方案的效率略有不同。
(2)docker利用的是宿主机的内核,而不需要Guest OS。因此,当新建一个容器时,docker不需要和虚拟机一样重新加载一个操作系统内核。我们知道,引导、加载操作系统内核是一个比较费时费资源的过程,当新建一个虚拟机时,虚拟机软件需要加载Guest OS,这个新建过程是分钟级别的。而docker由于直接利用宿主机的操作系统,则省略了这个过程,因此新建一个docker容器只需要几秒钟。另外,现代操作系统是复杂的系统,在一台物理机上新增加一个操作系统的资源开销是比较大的,因此,docker对比虚拟机在资源消耗上也占有比较大的优势。事实上,在一台物理机上我们可以很容易建立成百上千的容器,而只能建立几个虚拟机。


docker与虚拟机计算效率比较


在上一节我们从原理的角度推测docker应当在CPU和内存的利用效率上比虚拟机高。在这一节我们将根据IBM发表的论文给出的数据进行分析。以下的数据均是在IBM x3650 M4服务器测得,其主要的硬件参数是: 
(1)2颗英特尔xeon E5-2655 处理器,主频2.4-3.0 GHz。每颗处理器有8个核,因此总共有16个核。
(2)256 GB RAM.
在测试中是通过运算Linpack程序来获得计算能力数据的。结果如下图所示: 
dvk2.png
图中从左往右分别是物理机、docker和虚拟机的计算能力数据。可见docker相对于物理机其计算能力几乎没有损耗,而虚拟机对比物理机则有着非常明显的损耗。虚拟机的计算能力损耗在50%左右。 
为什么会有这么大的性能损耗呢?一方面是因为虚拟机增加了一层虚拟硬件层,运行在虚拟机上的应用程序在进行数值计算时是运行在Hypervisor虚拟的CPU上的;另外一方面是由于计算程序本身的特性导致的差异。虚拟机虚拟的cpu架构不同于实际cpu架构,数值计算程序一般针对特定的cpu架构有一定的优化措施,虚拟化使这些措施作废,甚至起到反效果。
比如对于本次实验的平台,实际的CPU架构是2块物理CPU,每块CPU拥有16个核,共32个核,采用的是NUMA架构;而虚拟机则将CPU虚拟化成一块拥有32个核的CPU。这就导致了计算程序在进行计算时无法根据实际的CPU架构进行优化,大大减低了计算效率。


docker与虚拟机内存访问效率比较


内存访问效率的比较相对比较复杂一点,主要是内存访问有多种场景: 
(1)大批量的,连续地址块的内存数据读写。这种测试环境下得到的性能数据是内存带宽,性能瓶颈主要在内存芯片的性能上; 
(2)随机内存访问性能。这种测试环境下的性能数据主要与内存带宽、cache的命中率和虚拟地址与物理地址转换的效率等因素有关。
以下将主要针对这两种内存访问场景进行分析。在分析之前我们先概要说明一下docker和虚拟机的内存访问模型差异。下图是docker与虚拟机内存访问模型: 
dvk3.png
可见在应用程序内存访问上,虚拟机的应用程序要进行2次的虚拟内存到物理内存的映射,读写内存的代价比docker的应用程序高。
下图是场景(1)的测试数据,即内存带宽数据。左图是程序运行在一块CPU(即8核)上的数据,右图是程序运行在2块CPU(即16核)上的数据。单位均为GB/s。 
dvk4.png

dvk5.png
从图中数据可以看出,在内存带宽性能上docker与虚拟机的性能差异并不大。这是因为在内存带宽测试中,读写的内存地址是连续的,大批量的,内核对这种操作会进行优化(数据预存取)。因此虚拟内存到物理内存的映射次数比较少,性能瓶颈主要在物理内存的读写速度上,因此这种情况docker和虚拟机的测试性能差别不大; 
内存带宽测试中docker与虚拟机内存访问性能差异不大的原因是由于内存带宽测试中需要进行虚拟地址到物理地址的映射次数比较少。根据这个假设,我们推测,当进行随机内存访问测试时这两者的性能差距将会变大,因为随机内存访问测试中需要进行虚拟内存地址到物理内存地址的映射次数将会变多。
结果如下图所示:
dvk6.png

dvk7.png
1图是程序运行在一个CPU上的数据,右图是程序运行在2块CPU上的数据。从左图可以看出,确实如我们所预测的,在随机内存访问性能上容器与虚拟机的性能差距变得比较明显,容器的内存访问性能明显比虚拟机优秀;但出乎我们意料的是在2块CPU上运行测试程序时容器与虚拟机的随机内存访问性能的差距却又变的不明显。
针对这个现象,IBM的论文给出了一个合理解释。这是因为当有2块CPU同时对内存进行访问时,内存读写的控制将会变得比较复杂,因为两块CPU可能同时读写同一个地址的数据,需要对内存数据进行一些同步操作,从而导致内存读写性能的损耗。这种损耗即使对于物理机也是存在的,可以看出右图的内存访问性能数据是低于左图的。2块CPU对内存读写性能的损耗影响是非常大的,这个损耗占据的比例远大于虚拟机和docker由于内存访问模型的不同产生的差异,因此在右图中docker与虚拟机的随机内存访问性能上我们看不出明显差异。


docker与虚拟机启动时间及资源耗费比较


上面两个小节主要从运行在docker里的程序和运行在虚拟机里的程序进行性能比较。
事实上,docker之所以如此受到开发者关注的另外一个重要原因是启动docker的系统代价比启动一台虚拟机的代价要低得多:无论从启动时间还是从启动资源耗费角度来说。docker直接利用宿主机的系统内核,避免了虚拟机启动时所需的系统引导时间和操作系统运行的资源消耗。利用docker能在几秒钟之内启动大量的容器,这是虚拟机无法办到的。快速启动、低系统资源消耗的优点使docker在弹性云平台和自动运维系统方面有着很好的应用前景。


docker的劣势


前面的内容主要论述docker相对于虚拟机的优势,但docker也不是完美的系统。相对于虚拟机,docker还存在着以下几个缺点:
1.资源隔离方面不如虚拟机,docker是利用cgroup实现资源限制的,只能限制资源消耗的最大值,而不能隔绝其他程序占用自己的资源。
2.安全性问题。docker目前并不能分辨具体执行指令的用户,只要一个用户拥有执行docker的权限,那么他就可以对docker的容器进行所有操作,不管该容器是否是由该用户创建。比如A和B都拥有执行docker的权限,由于docker的server端并不会具体判断docker cline是由哪个用户发起的,A可以删除B创建的容器,存在一定的安全风险。 
3.docker目前还在版本的快速更新中,细节功能调整比较大。一些核心模块依赖于高版本内核,存在版本兼容问题


原文作者:chenbiaolong
 
 
分享原文地址:http://blog.csdn.net/cbl709/article/details/43955687


怎么限制docker容器的磁盘和带宽

Ansible 回复了问题 • 2 人关注 • 1 个回复 • 2269 次浏览 • 2015-10-12 18:10 • 来自相关话题

elasticsearch中文分词插件IK使用

采菊篱下 发表了文章 • 0 个评论 • 1677 次浏览 • 2015-09-21 11:40 • 来自相关话题

ES支持中文的前提是安装正确的分词组件,比如elasticsearch-analysis-ik。
版本支持如下:





安装

# git clone https://github.com/medcl/elasticsearch-analysis-ik.git --depth 1
# cd elasticsearch-analysis-ik/
# mvn package
# unzip ./target/releases/elasticsearch-analysis-ik-1.2.9.zip
OR# git clone https://github.com/medcl/elasticsearch-analysis-ik
# cd elasticsearch-analysis-ik
# mvn compile
# mvn package
# plugin --install analysis-ik --url file:///#{project_path}/elasticsearch-analysis-ik/target/releases/elasticsearch-analysis-ik-1.3.0.zipzip解压得到5个jar包:
[]- elasticsearch-analysis-ik-1.2.9.jar[/][]- httpclient-4.3.5.jar[/][]- httpcore-4.3.2.jar[/][]- commons-logging-1.1.3.jar[/][]- commons-codec-1.6.jar[/]
 
返回ES目录,新建路径./plugins/analysis-ik并把上述jar包全部移进去。
第二步,把elasticsearch-analysis-ik/config/ik文件夹(IK自带的词典)复制到ES目录的./config路径下。
第三步,在./config/elasticsearch.yml文件的最后加上:index:
analysis:
analyzer:
ik:
alias: [news_analyzer_ik,ik_analyzer]
type: org.elasticsearch.index.analysis.IkAnalyzerProvider

index.analysis.analyzer.default.type : "ik"
OR[b]index.analysis.analyzer.ik.type : "ik"[/b]注意配置分词组件必须在创建索引之前,否则是无效的。

Example

1.create a index# curl -XPUT http://localhost:9200/index2.create a mapping# curl -XPUT http://localhost:9200/index
create a mapping
curl -XPOST http://localhost:9200/index/fulltext/_mapping -d'
{
"fulltext": {
"_all": {
"indexAnalyzer": "ik",
"searchAnalyzer": "ik",
"term_vector": "no",
"store": "false"
},
"properties": {
"content": {
"type": "string",
"store": "no",
"term_vector": "with_positions_offsets",
"indexAnalyzer": "ik",
"searchAnalyzer": "ik",
"include_in_all": "true",
"boost": 8
}
}
}
}'3.index some docs# curl -XPOST http://localhost:9200/index/fulltext/1 -d'
{"content":"美国留给伊拉克的是个烂摊子吗"}
'# curl -XPOST http://localhost:9200/index/fulltext/2 -d'
{"content":"公安部:各地校车将享最高路权"}
'# curl -XPOST http://localhost:9200/index/fulltext/3 -d'
{"content":"中韩渔警冲突调查:韩警平均每天扣1艘中国渔船"}
' # curl -XPOST http://localhost:9200/index/fulltext/4 -d'
{"content":"中国驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首"}
'4.query with highlighting# curl -XPOST http://localhost:9200/index/fulltext/_search -d'
{
"query" : { "term" : { "content" : "中国" }},
"highlight" : {
"pre_tags" : ["<tag1>", "<tag2>"],
"post_tags" : ["</tag1>", "</tag2>"],
"fields" : {
"content" : {}
}
}
}
'Result{
"took": 14,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 2,
"max_score": 2,
"hits": [
{
"_index": "index",
"_type": "fulltext",
"_id": "4",
"_score": 2,
"_source": {
"content": "中国驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首"
},
"highlight": {
"content": [
"<tag1>中国</tag1>驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首 "
]
}
},
{
"_index": "index",
"_type": "fulltext",
"_id": "3",
"_score": 2,
"_source": {
"content": "中韩渔警冲突调查:韩警平均每天扣1艘中国渔船"
},
"highlight": {
"content": [
"均每天扣1艘<tag1>中国</tag1>渔船 "
]
}
}
]
}
} 查看全部
eslogo.png

ES支持中文的前提是安装正确的分词组件,比如elasticsearch-analysis-ik
版本支持如下:
ik1.png


安装


# git clone https://github.com/medcl/elasticsearch-analysis-ik.git --depth 1
# cd elasticsearch-analysis-ik/
# mvn package
# unzip ./target/releases/elasticsearch-analysis-ik-1.2.9.zip

OR
# git clone https://github.com/medcl/elasticsearch-analysis-ik
# cd elasticsearch-analysis-ik
# mvn compile
# mvn package
# plugin --install analysis-ik --url file:///#{project_path}/elasticsearch-analysis-ik/target/releases/elasticsearch-analysis-ik-1.3.0.zip
zip解压得到5个jar包:
    []- elasticsearch-analysis-ik-1.2.9.jar[/][]- httpclient-4.3.5.jar[/][]- httpcore-4.3.2.jar[/][]- commons-logging-1.1.3.jar[/][]- commons-codec-1.6.jar[/]

 
返回ES目录,新建路径./plugins/analysis-ik并把上述jar包全部移进去。
第二步,把elasticsearch-analysis-ik/config/ik文件夹(IK自带的词典)复制到ES目录的./config路径下。
第三步,在./config/elasticsearch.yml文件的最后加上:
index:
analysis:
analyzer:
ik:
alias: [news_analyzer_ik,ik_analyzer]
type: org.elasticsearch.index.analysis.IkAnalyzerProvider

index.analysis.analyzer.default.type : "ik"

OR
[b]index.analysis.analyzer.ik.type : "ik"[/b]
注意配置分词组件必须在创建索引之前,否则是无效的。


Example


1.create a index
# curl -XPUT http://localhost:9200/index
2.create a mapping
# curl -XPUT http://localhost:9200/index
create a mapping
curl -XPOST http://localhost:9200/index/fulltext/_mapping -d'
{
"fulltext": {
"_all": {
"indexAnalyzer": "ik",
"searchAnalyzer": "ik",
"term_vector": "no",
"store": "false"
},
"properties": {
"content": {
"type": "string",
"store": "no",
"term_vector": "with_positions_offsets",
"indexAnalyzer": "ik",
"searchAnalyzer": "ik",
"include_in_all": "true",
"boost": 8
}
}
}
}'
3.index some docs
# curl -XPOST http://localhost:9200/index/fulltext/1 -d'
{"content":"美国留给伊拉克的是个烂摊子吗"}
'
# curl -XPOST http://localhost:9200/index/fulltext/2 -d'
{"content":"公安部:各地校车将享最高路权"}
'
# curl -XPOST http://localhost:9200/index/fulltext/3 -d'
{"content":"中韩渔警冲突调查:韩警平均每天扣1艘中国渔船"}
# curl -XPOST http://localhost:9200/index/fulltext/4 -d'
{"content":"中国驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首"}
'
4.query with highlighting
# curl -XPOST http://localhost:9200/index/fulltext/_search  -d'
{
"query" : { "term" : { "content" : "中国" }},
"highlight" : {
"pre_tags" : ["<tag1>", "<tag2>"],
"post_tags" : ["</tag1>", "</tag2>"],
"fields" : {
"content" : {}
}
}
}
'
Result
{
"took": 14,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 2,
"max_score": 2,
"hits": [
{
"_index": "index",
"_type": "fulltext",
"_id": "4",
"_score": 2,
"_source": {
"content": "中国驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首"
},
"highlight": {
"content": [
"<tag1>中国</tag1>驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首 "
]
}
},
{
"_index": "index",
"_type": "fulltext",
"_id": "3",
"_score": 2,
"_source": {
"content": "中韩渔警冲突调查:韩警平均每天扣1艘中国渔船"
},
"highlight": {
"content": [
"均每天扣1艘<tag1>中国</tag1>渔船 "
]
}
}
]
}
}

Elasticsearch索引存储类型

采菊篱下 发表了文章 • 0 个评论 • 2475 次浏览 • 2015-09-20 16:59 • 来自相关话题

文件系统存储类型
    基于文件系统的存储是默认索引存储方式。有不同的实现或存储类型。最好的一个操作系统的自动选择是:mmapfs使用在Windows的64bit系统上,simplefs使用在windows的32bit系统上,除此之外默认是用(hybrid niofs 和 mmapfs)。
 
    你可以通过修改配置文件elasticsearch.yml来指定存储类型:index.store.type: niofs    当然你也可以在创建索引的时候指定:curl -XPUT localhost:9200/my_index -d '{
"settings": {
"index.store.type": "niofs"
}
}';    下面是所有支持的不同存储类型:

Simple FS(简单文件系统)

Simplefs类型是一个简单的实现随机访问文件的文件存储系统(映射到Lucene SimpleFsDirectory的)。该实现的并发性能较差(多线程是个瓶颈)。当你需要将索引持久化,最好使用niofs。

NIO FS(NIO文件系统)

niofs类型是通过NIO将分片索引文件写到文件系统上(映射到Lucene NIOFSDirectory)。它允许多线程同时读取文件。不建议在Windows系统上使用,由于SUN JAVA实现上的一个错误。

MMap FS(内存映射文件系统)

mmapfs类型存储分片索引到文件系统上(映射到Lucene MMapDirectory)通过映射文件到内存中(MMAP)。内存映射的过程中将划分出与被映射文件大小一样的虚拟内存空间。使用这个类之前,请确保您有足够的虚拟地址空间。Linux下虚拟内存设置:
# sysctl -w vm.max_map_count=262144
永久生效:
update the vm.max_map_count setting in /etc/sysctl.conf.
# echo "vm.max_map_count=262144" >> /etc/sysctl.conf && sysctl -p

Hybrid MMap / NIO FS

默认类型存储碎片索引在文件系统中根据不同的文件类型的文件映射到内存(mmap)或使用Java NIO。目前只Lucene术语字典和doc值文件内存映射到减少对操作系统的影响。所有其他文件都使用Lucene NIOFSDirectory打开。
内存
    内存类型索引存储在主内存,使用Lucene的RamIndexStore。
    
    也有节点级别的设置来控制高速缓存(重要的,当使用直接缓冲区):




参考:https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-store.html#store-memory
           https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration.html#file-descriptors 查看全部
eslogo.png


文件系统存储类型
    基于文件系统的存储是默认索引存储方式。有不同的实现或存储类型。最好的一个操作系统的自动选择是:mmapfs使用在Windows的64bit系统上,simplefs使用在windows的32bit系统上,除此之外默认是用(hybrid niofs 和 mmapfs)。
 
    你可以通过修改配置文件elasticsearch.yml来指定存储类型:
index.store.type: niofs
    当然你也可以在创建索引的时候指定:
curl -XPUT localhost:9200/my_index -d '{
"settings": {
"index.store.type": "niofs"
}
}';
    下面是所有支持的不同存储类型:


Simple FS(简单文件系统)


Simplefs类型是一个简单的实现随机访问文件的文件存储系统(映射到Lucene SimpleFsDirectory的)。该实现的并发性能较差(多线程是个瓶颈)。当你需要将索引持久化,最好使用niofs。


NIO FS(NIO文件系统)


niofs类型是通过NIO将分片索引文件写到文件系统上(映射到Lucene NIOFSDirectory)。它允许多线程同时读取文件。不建议在Windows系统上使用,由于SUN JAVA实现上的一个错误。


MMap FS(内存映射文件系统)


mmapfs类型存储分片索引到文件系统上(映射到Lucene MMapDirectory)通过映射文件到内存中(MMAP)。内存映射的过程中将划分出与被映射文件大小一样的虚拟内存空间。使用这个类之前,请确保您有足够的虚拟地址空间。
Linux下虚拟内存设置:
# sysctl -w vm.max_map_count=262144
永久生效:
update the vm.max_map_count setting in /etc/sysctl.conf.
# echo "vm.max_map_count=262144" >> /etc/sysctl.conf && sysctl -p


Hybrid MMap / NIO FS


默认类型存储碎片索引在文件系统中根据不同的文件类型的文件映射到内存(mmap)或使用Java NIO。目前只Lucene术语字典和doc值文件内存映射到减少对操作系统的影响。所有其他文件都使用Lucene NIOFSDirectory打开。

内存
    内存类型索引存储在主内存,使用Lucene的RamIndexStore。
    
    也有节点级别的设置来控制高速缓存(重要的,当使用直接缓冲区):
estore.png

参考:https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-store.html#store-memory
           https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration.html#file-descriptors

docker怎么让nginx访问我指定的目录

koyo 回复了问题 • 2 人关注 • 1 个回复 • 2098 次浏览 • 2015-09-19 20:26 • 来自相关话题

elasticsearch特点介绍

采菊篱下 发表了文章 • 0 个评论 • 1462 次浏览 • 2015-09-19 16:07 • 来自相关话题

    Elasticsearch是分布式,REST风格,搜索和分析系统。具有实时数据,实时分析,分布式,高可用性,多租户,全文搜索,面向文档,冲突管理,自由模式,rest风格API,每个操作的持久性,Apache 2的开源许可证,基于Apache Lucene之上的特点。

实时数据

数据流进入的系统后,数据怎么能够快速的可视化。用elasticsearch,所有数据立即可用被搜索和分析。




实时分析

结合搜索的速度与分析的力量,改变你的关系与你的数据。交互搜索,发现和分析,以获得改善你的产品或简化您的业务。




分布式

Elasticsearch允许你开始小规模使用,但是随着你使用数据的增长,它可以建立在横向扩展的开箱即用。当你需要更多的容量,只需添加更多的节点,并让集群重组,只需要增加额外的硬件,让集群自动利用额外的硬件。




高可用

Elasticsearch集群弹性-他们将发现新的或失败的节点,重组和重新平衡数据,确保您的数据是安全的和可访问的。




多租户

集群可以托管多个索引,可独立或作为一个组进行查询。索引别名允许你过滤视图时添加索引,可以透明地更新您的应用程序。




全文搜索

Elasticsearch在后台使用Lucene来提供最强大的全文检索,提供任何开源产品的能力。搜索自带的多语言支持,强大的查询语言,地理位置支持,上下文感知的建议,自动完成和搜索片段。




面向文档

存储复杂的真实世界的实体在Elasticsearch结构化JSON文件。所有的字段都被默认索引,所有的索引可以使用一个单一的查询,以方便快速的返回复杂的结果。




模式自由

Elasticsearch允许你快速上手。简单的指定一个JSON文档将自动检测数据的结构和类型,创建一个索引,并使你的数据检索。您还拥有完全控制,以自定义您的数据是如何被索引的。




友好的RESTful API

Elasticsearch是API驱动。几乎任何动作都可以用一个简单的RESTful API使用JSON基于HTTP请求。客户库可使用多种编程语言。




操作持久化

Elasticsearch把你的数据安全第一。文档改变被记录在群集上的多个节点上的事务日志(transaction logs)中记录,以减少任何数据丢失的机会。




Apache 2开源许可证

Elasticsearch可以下载,使用和免费修改。它是基于Apache 2的开源许可证,最灵活的开源许可证。




基于Apache Lucene之上

Apache Lucene是一个用Java编写的高性能,功能齐全信息检索库。elasticsearch内部利用lucene来构建的分布式和分析功能。




冲突管理

乐观的版本控制,可以使用在需要的地方,多个进程的冲突变化,开放式版本控制可以确保数据不会丢失。



英文地址:原文地址 查看全部
es1.jpeg

    Elasticsearch是分布式,REST风格,搜索和分析系统。具有实时数据,实时分析,分布式,高可用性,多租户,全文搜索,面向文档,冲突管理,自由模式,rest风格API,每个操作的持久性,Apache 2的开源许可证,基于Apache Lucene之上的特点。


实时数据


数据流进入的系统后,数据怎么能够快速的可视化。用elasticsearch,所有数据立即可用被搜索和分析。
elasticsearch1.png


实时分析


结合搜索的速度与分析的力量,改变你的关系与你的数据。交互搜索,发现和分析,以获得改善你的产品或简化您的业务。
elasticsearch2.png


分布式


Elasticsearch允许你开始小规模使用,但是随着你使用数据的增长,它可以建立在横向扩展的开箱即用。当你需要更多的容量,只需添加更多的节点,并让集群重组,只需要增加额外的硬件,让集群自动利用额外的硬件。
elasticsearch3.png


高可用


Elasticsearch集群弹性-他们将发现新的或失败的节点,重组和重新平衡数据,确保您的数据是安全的和可访问的。
elasticsearch4.png


多租户


集群可以托管多个索引,可独立或作为一个组进行查询。索引别名允许你过滤视图时添加索引,可以透明地更新您的应用程序。
elasticsearch5.png


全文搜索


Elasticsearch在后台使用Lucene来提供最强大的全文检索,提供任何开源产品的能力。搜索自带的多语言支持,强大的查询语言,地理位置支持,上下文感知的建议,自动完成和搜索片段。
elasticsearch6.png


面向文档


存储复杂的真实世界的实体在Elasticsearch结构化JSON文件。所有的字段都被默认索引,所有的索引可以使用一个单一的查询,以方便快速的返回复杂的结果。
elasticsearch7.png


模式自由


Elasticsearch允许你快速上手。简单的指定一个JSON文档将自动检测数据的结构和类型,创建一个索引,并使你的数据检索。您还拥有完全控制,以自定义您的数据是如何被索引的。
elasticsearch8.png


友好的RESTful API


Elasticsearch是API驱动。几乎任何动作都可以用一个简单的RESTful API使用JSON基于HTTP请求。客户库可使用多种编程语言。
elasticsearch9.png


操作持久化


Elasticsearch把你的数据安全第一。文档改变被记录在群集上的多个节点上的事务日志(transaction logs)中记录,以减少任何数据丢失的机会。
elasticsearch10.png


Apache 2开源许可证


Elasticsearch可以下载,使用和免费修改。它是基于Apache 2的开源许可证,最灵活的开源许可证。
elasticsearch11.png


基于Apache Lucene之上


Apache Lucene是一个用Java编写的高性能,功能齐全信息检索库。elasticsearch内部利用lucene来构建的分布式和分析功能。
elasticsearch12.png


冲突管理


乐观的版本控制,可以使用在需要的地方,多个进程的冲突变化,开放式版本控制可以确保数据不会丢失。
elasticsearch13.png

英文地址:原文地址

elasticsearch不能触碰的配置

采菊篱下 发表了文章 • 0 个评论 • 1086 次浏览 • 2015-09-19 14:17 • 来自相关话题

    有几个elasticsearch的热点配置,似乎没有办法避免调整。我们熟知的:配置按钮都希望被打开。然而把所有的配置项都打开,你觉得就可以息事宁人了吗。这些配置常常被滥用,将会导致糟糕的稳定性和糟糕的性能问题,乃至这两种问题。

垃圾收集器(Garbage Collector)

    在这里简单介绍了垃圾收集器基本认识,JVM使用垃圾收集器来释放回收内存。这个技巧确实是最后一个技巧的延伸,但是值得强调的是:
    不要更改默认的垃圾收集器配置!Elasticsearh默认的GC是CMS。让GC并发的运行应用程序,以便最大限度的减少暂停时间。然而它有两个stop-the-world阶段,在回收大量的heaps。

尽管有这些缺点,它是目前对于像Elasticsearch低延迟服务器软件的最佳的GC。 官方建议使用CMS。

有一个新的GC叫垃圾第一GC(g1gc)。这个新的GC的设计是为了尽量减少停顿比CMS更大的堆,和操作。它的工作原理是将堆分割成区域,预测区域包含最可回收的空间。通过收集这些区域(第一),它可以最大限度地减少暂停和操作非常大的堆。

听起来很棒!不幸的是,g1gc仍然是新的,和新的漏洞被发现的常规。这些错误通常会导致各种各样的段错误,硬盘崩溃。Lucene的测试套件是残酷的GC算法,似乎g1gc没有扭结的工作了。

我们想总有一天会推荐g1gc,但现在,它只是不够稳定满足Elasticsearch和Lucene的要求





线程池(Threadpoolsedit)

每个人都喜欢好的线程池。不管出于什么原因,人们似乎无法抗拒增加线程数。索引很多?更多线程!搜索很多?更多线程!节点空闲时间95%的时间?更多线程!

在Elasticsearch默认的线程池的设置是非常明智的。 对于所有的线程池(除了search )的经纬被设置为CPU核心的数量。 如果你有八个核心,你可以同时运行的只有八个线程。 它有道理仅分配八个线程在任何特定的线程池。

搜索得到一个较大的线程池,并且被配置为 # cores * 3

你可能会争辩说,一些线程可以阻止(如在一个磁盘上IO操作),这就是为什么你需要更多的线程。这不是一个问题:在Elasticsearch的磁盘I/O是由Lucene的线程处理,不是Elasticsearch。

此外,合作的线程池通过传递彼此之间的工作。 您不必再担心网络线程阻塞,因为它正在等待磁盘写入。 联网线程都有,因为另一个线程池转交给了工作单位长期得到回网络。

最后,你的程序的计算能力是有限的。 有更多的线程只是迫使处理器切换线程上下文。 处理器可以一次运行只有一个线程,因此当它需要切换到一个不同的线程,它存储了当前的状态(寄存器,等等),并装载另一个线程。 如果你是幸运的,交换机将发生在相同的核心。 如果你运气不好,开关可能会迁移到不同的核心,并要求运输核间通信总线上。

这个上下文切换吃掉周期只需做管理清洁; 估计能挂它高达对现代的CPU为30μs。 所以,除非该线程将被阻塞比为30μs长,极有可能是那个时候会被更好地用刚刚加工和提早完成。

人们通常设置线程池错误的值。 八核的机器,我们已经与60,100,甚至1000个线程运行在整个的configs。 这些设置将让CPU大于得到真正的工作要做。

所以。 下次你要调整一个线程池,请不要。 如果你绝对无法抗拒 ,请保持你的核心数量在心中,也许设置数量增加一倍。 更重要的是仅仅是一种浪费。
原文地址:https://www.elastic.co/guide/en/elasticsearch/guide/current/_don_8217_t_touch_these_settings.html 查看全部
eslogo.png

    有几个elasticsearch的热点配置,似乎没有办法避免调整。我们熟知的:配置按钮都希望被打开。然而把所有的配置项都打开,你觉得就可以息事宁人了吗。这些配置常常被滥用,将会导致糟糕的稳定性和糟糕的性能问题,乃至这两种问题。


垃圾收集器(Garbage Collector)


    在这里简单介绍了垃圾收集器基本认识,JVM使用垃圾收集器来释放回收内存。这个技巧确实是最后一个技巧的延伸,但是值得强调的是:
    不要更改默认的垃圾收集器配置!
Elasticsearh默认的GC是CMS。让GC并发的运行应用程序,以便最大限度的减少暂停时间。然而它有两个stop-the-world阶段,在回收大量的heaps。

尽管有这些缺点,它是目前对于像Elasticsearch低延迟服务器软件的最佳的GC。 官方建议使用CMS。

有一个新的GC叫垃圾第一GC(g1gc)。这个新的GC的设计是为了尽量减少停顿比CMS更大的堆,和操作。它的工作原理是将堆分割成区域,预测区域包含最可回收的空间。通过收集这些区域(第一),它可以最大限度地减少暂停和操作非常大的堆。

听起来很棒!不幸的是,g1gc仍然是新的,和新的漏洞被发现的常规。这些错误通常会导致各种各样的段错误,硬盘崩溃。Lucene的测试套件是残酷的GC算法,似乎g1gc没有扭结的工作了。

我们想总有一天会推荐g1gc,但现在,它只是不够稳定满足Elasticsearch和Lucene的要求





线程池(Threadpoolsedit)


每个人都喜欢好的线程池。不管出于什么原因,人们似乎无法抗拒增加线程数。索引很多?更多线程!搜索很多?更多线程!节点空闲时间95%的时间?更多线程!    

在Elasticsearch默认的线程池的设置是非常明智的。 对于所有的线程池(除了search )的经纬被设置为CPU核心的数量。 如果你有八个核心,你可以同时运行的只有八个线程。 它有道理仅分配八个线程在任何特定的线程池。

搜索得到一个较大的线程池,并且被配置为 # cores * 3

你可能会争辩说,一些线程可以阻止(如在一个磁盘上IO操作),这就是为什么你需要更多的线程。这不是一个问题:在Elasticsearch的磁盘I/O是由Lucene的线程处理,不是Elasticsearch。

此外,合作的线程池通过传递彼此之间的工作。 您不必再担心网络线程阻塞,因为它正在等待磁盘写入。 联网线程都有,因为另一个线程池转交给了工作单位长期得到回网络。

最后,你的程序的计算能力是有限的。 有更多的线程只是迫使处理器切换线程上下文。 处理器可以一次运行只有一个线程,因此当它需要切换到一个不同的线程,它存储了当前的状态(寄存器,等等),并装载另一个线程。 如果你是幸运的,交换机将发生在相同的核心。 如果你运气不好,开关可能会迁移到不同的核心,并要求运输核间通信总线上。

这个上下文切换吃掉周期只需做管理清洁; 估计能挂它高达对现代的CPU为30μs。 所以,除非该线程将被阻塞比为30μs长,极有可能是那个时候会被更好地用刚刚加工和提早完成。

人们通常设置线程池错误的值。 八核的机器,我们已经与60,100,甚至1000个线程运行在整个的configs。 这些设置将让CPU大于得到真正的工作要做。

所以。 下次你要调整一个线程池,请不要。 如果你绝对无法抗拒 ,请保持你的核心数量在心中,也许设置数量增加一倍。 更重要的是仅仅是一种浪费。
原文地址:https://www.elastic.co/guide/en/elasticsearch/guide/current/_don_8217_t_touch_these_settings.html

elasticsearch的索引如何才能做到平滑切换

采菊篱下 回复了问题 • 2 人关注 • 1 个回复 • 1725 次浏览 • 2015-09-18 23:22 • 来自相关话题

elasticsearch配置文件详解

OpenSkill 发表了文章 • 0 个评论 • 1004 次浏览 • 2015-09-18 11:26 • 来自相关话题

elasticsearch的config文件夹里面有两个配置文件:elasticsearch.yml和logging.yml,第一个是es的基本配置文件,第二个是日志配置文件,es也是使用log4j来记录日志的,所以logging.yml里的设置按普通log4j配置文件来设置就行了。下面主要讲解下elasticsearch.yml这个文件中可配置的东西:

cluster.name: elasticsearch
配置es的集群名称,默认是elasticsearch,es会自动发现在同一网段下的es,如果在同一网段下有多个集群,就可以用这个属性来区分不同的集群。

node.name: "Franz Kafka"
节点名,默认随机指定一个name列表中名字,该列表在es的jar包中config文件夹里name.txt文件中,其中有很多作者添加的有趣名字。

node.master: true
指定该节点是否有资格被选举成为node,默认是true,es是默认集群中的第一台机器为master,如果这台机挂了就会重新选举master。

node.data: true
指定该节点是否存储索引数据,默认为true。

index.number_of_shards: 5
设置默认索引分片个数,默认为5片。

index.number_of_replicas: 1
设置默认索引副本个数,默认为1个副本。

path.conf: /path/to/conf
设置配置文件的存储路径,默认是es根目录下的config文件夹。

path.data: /path/to/data
设置索引数据的存储路径,默认是es根目录下的data文件夹,可以设置多个存储路径,用逗号隔开,例:
path.data: /path/to/data1,/path/to/data2

path.work: /path/to/work
设置临时文件的存储路径,默认是es根目录下的work文件夹。

path.logs: /path/to/logs
设置日志文件的存储路径,默认是es根目录下的logs文件夹

path.plugins: /path/to/plugins
设置插件的存放路径,默认是es根目录下的plugins文件夹

bootstrap.mlockall: true
设置为true来锁住内存。因为当jvm开始swapping时es的效率会降低,所以要保证它不swap,可以把ES_MIN_MEM和ES_MAX_MEM两个环境变量设置成同一个值,并且保证机器有足够的内存分配给es。同时也要允许elasticsearch的进程可以锁住内存,linux下可以通过`ulimit -l unlimited`命令。

network.bind_host: 192.168.0.1
设置绑定的ip地址,可以是ipv4或ipv6的,默认为0.0.0.0。


network.publish_host: 192.168.0.1
设置其它节点和该节点交互的ip地址,如果不设置它会自动判断,值必须是个真实的ip地址。

network.host: 192.168.0.1
这个参数是用来同时设置bind_host和publish_host上面两个参数。

transport.tcp.port: 9300
设置节点间交互的tcp端口,默认是9300。

transport.tcp.compress: true
设置是否压缩tcp传输时的数据,默认为false,不压缩。

http.port: 9200
设置对外服务的http端口,默认为9200。

http.max_content_length: 100mb
设置内容的最大容量,默认100mb

http.enabled: false
是否使用http协议对外提供服务,默认为true,开启。

gateway.type: local
gateway的类型,默认为local即为本地文件系统,可以设置为本地文件系统,分布式文件系统,hadoop的HDFS,和amazon的s3服务器,其它文件系统的设置方法下次再详细说。

gateway.recover_after_nodes: 1
设置集群中N个节点启动时进行数据恢复,默认为1。

gateway.recover_after_time: 5m
设置初始化数据恢复进程的超时时间,默认是5分钟。

gateway.expected_nodes: 2
设置这个集群中节点的数量,默认为2,一旦这N个节点启动,就会立即进行数据恢复。

cluster.routing.allocation.node_initial_primaries_recoveries: 4
初始化数据恢复时,并发恢复线程的个数,默认为4。

cluster.routing.allocation.node_concurrent_recoveries: 2
添加删除节点或负载均衡时并发恢复线程的个数,默认为4。

indices.recovery.max_size_per_sec: 0
设置数据恢复时限制的带宽,如入100mb,默认为0,即无限制。

indices.recovery.concurrent_streams: 5
设置这个参数来限制从其它分片恢复数据时最大同时打开并发流的个数,默认为5。

discovery.zen.minimum_master_nodes: 1
设置这个参数来保证集群中的节点可以知道其它N个有master资格的节点。默认为1,对于大的集群来说,可以设置大一点的值(2-4)

discovery.zen.ping.timeout: 3s
设置集群中自动发现其它节点时ping连接超时时间,默认为3秒,对于比较差的网络环境可以高点的值来防止自动发现时出错。

discovery.zen.ping.multicast.enabled: false
设置是否打开多播发现节点,默认是true。

discovery.zen.ping.unicast.hosts: ["host1", "host2:port", "host3[portX-portY]"]
设置集群中master节点的初始列表,可以通过这些节点来自动发现新加入集群的节点。

下面是一些查询时的慢日志参数设置
index.search.slowlog.level: TRACE
index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.threshold.query.info: 5s
index.search.slowlog.threshold.query.debug: 2s
index.search.slowlog.threshold.query.trace: 500ms

index.search.slowlog.threshold.fetch.warn: 1s
index.search.slowlog.threshold.fetch.info: 800ms
index.search.slowlog.threshold.fetch.debug:500ms
index.search.slowlog.threshold.fetch.trace: 200ms 查看全部
es1.jpg
elasticsearch的config文件夹里面有两个配置文件:elasticsearch.yml和logging.yml,第一个是es的基本配置文件,第二个是日志配置文件,es也是使用log4j来记录日志的,所以logging.yml里的设置按普通log4j配置文件来设置就行了。
下面主要讲解下elasticsearch.yml这个文件中可配置的东西:

cluster.name: elasticsearch
配置es的集群名称,默认是elasticsearch,es会自动发现在同一网段下的es,如果在同一网段下有多个集群,就可以用这个属性来区分不同的集群。

node.name: "Franz Kafka"
节点名,默认随机指定一个name列表中名字,该列表在es的jar包中config文件夹里name.txt文件中,其中有很多作者添加的有趣名字。

node.master: true
指定该节点是否有资格被选举成为node,默认是true,es是默认集群中的第一台机器为master,如果这台机挂了就会重新选举master。

node.data: true
指定该节点是否存储索引数据,默认为true。

index.number_of_shards: 5
设置默认索引分片个数,默认为5片。

index.number_of_replicas: 1
设置默认索引副本个数,默认为1个副本。

path.conf: /path/to/conf
设置配置文件的存储路径,默认是es根目录下的config文件夹。

path.data: /path/to/data
设置索引数据的存储路径,默认是es根目录下的data文件夹,可以设置多个存储路径,用逗号隔开,例:
path.data: /path/to/data1,/path/to/data2

path.work: /path/to/work
设置临时文件的存储路径,默认是es根目录下的work文件夹。

path.logs: /path/to/logs
设置日志文件的存储路径,默认是es根目录下的logs文件夹

path.plugins: /path/to/plugins
设置插件的存放路径,默认是es根目录下的plugins文件夹

bootstrap.mlockall: true
设置为true来锁住内存。因为当jvm开始swapping时es的效率会降低,所以要保证它不swap,可以把ES_MIN_MEM和ES_MAX_MEM两个环境变量设置成同一个值,并且保证机器有足够的内存分配给es。同时也要允许elasticsearch的进程可以锁住内存,linux下可以通过`ulimit -l unlimited`命令。

network.bind_host: 192.168.0.1
设置绑定的ip地址,可以是ipv4或ipv6的,默认为0.0.0.0。


network.publish_host: 192.168.0.1
设置其它节点和该节点交互的ip地址,如果不设置它会自动判断,值必须是个真实的ip地址。

network.host: 192.168.0.1
这个参数是用来同时设置bind_host和publish_host上面两个参数。

transport.tcp.port: 9300
设置节点间交互的tcp端口,默认是9300。

transport.tcp.compress: true
设置是否压缩tcp传输时的数据,默认为false,不压缩。

http.port: 9200
设置对外服务的http端口,默认为9200。

http.max_content_length: 100mb
设置内容的最大容量,默认100mb

http.enabled: false
是否使用http协议对外提供服务,默认为true,开启。

gateway.type: local
gateway的类型,默认为local即为本地文件系统,可以设置为本地文件系统,分布式文件系统,hadoop的HDFS,和amazon的s3服务器,其它文件系统的设置方法下次再详细说。

gateway.recover_after_nodes: 1
设置集群中N个节点启动时进行数据恢复,默认为1。

gateway.recover_after_time: 5m
设置初始化数据恢复进程的超时时间,默认是5分钟。

gateway.expected_nodes: 2
设置这个集群中节点的数量,默认为2,一旦这N个节点启动,就会立即进行数据恢复。

cluster.routing.allocation.node_initial_primaries_recoveries: 4
初始化数据恢复时,并发恢复线程的个数,默认为4。

cluster.routing.allocation.node_concurrent_recoveries: 2
添加删除节点或负载均衡时并发恢复线程的个数,默认为4。

indices.recovery.max_size_per_sec: 0
设置数据恢复时限制的带宽,如入100mb,默认为0,即无限制。

indices.recovery.concurrent_streams: 5
设置这个参数来限制从其它分片恢复数据时最大同时打开并发流的个数,默认为5。

discovery.zen.minimum_master_nodes: 1
设置这个参数来保证集群中的节点可以知道其它N个有master资格的节点。默认为1,对于大的集群来说,可以设置大一点的值(2-4)

discovery.zen.ping.timeout: 3s
设置集群中自动发现其它节点时ping连接超时时间,默认为3秒,对于比较差的网络环境可以高点的值来防止自动发现时出错。

discovery.zen.ping.multicast.enabled: false
设置是否打开多播发现节点,默认是true。

discovery.zen.ping.unicast.hosts: ["host1", "host2:port", "host3[portX-portY]"]
设置集群中master节点的初始列表,可以通过这些节点来自动发现新加入集群的节点。

下面是一些查询时的慢日志参数设置
index.search.slowlog.level: TRACE
index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.threshold.query.info: 5s
index.search.slowlog.threshold.query.debug: 2s
index.search.slowlog.threshold.query.trace: 500ms

index.search.slowlog.threshold.fetch.warn: 1s
index.search.slowlog.threshold.fetch.info: 800ms
index.search.slowlog.threshold.fetch.debug:500ms
index.search.slowlog.threshold.fetch.trace: 200ms

docker run bash failed

采菊篱下 回复了问题 • 2 人关注 • 1 个回复 • 1681 次浏览 • 2015-09-17 00:18 • 来自相关话题