[[hardware]] === Hardware 如果你已经遵循了正常的开发路径, 你可能已经在自己的笔记本电脑或周边的机器集群上使用了Elasticsearch ((("deployment", "hardware")))((("hardware"))). 但当要部署到生产环境时, 有一些建议是你需要考虑的. 这里没有什么必须要遵守的准则;Elasticsearch被用于在众多的机器上处理各种任务. 但基于我们的生产集群经验，可以提供一个好的起点. ==== 内存 如果有一种资源是最先被耗尽的, 它可能是内存.((("hardware", "memory")))((("memory"))) 排序和聚合都是很耗内存的, 所以使用足够的堆空间来应付它们是很重要的.((("heap"))) 尽管当堆空间是比较小的时候, 也能为操作系统文件缓存提供额外的内存. 因为Lucene使用的很多数据结构格式是基于硬盘的, Elasticsearch 使得操作系统缓存能产生很大效果. 64 GB内存的机器是非常理想的, 但32 GB 和 16 GB 机器也是很常见的. 少于8 GB 会适得其反 (你最终需要很多很多的小机器), 大于64 GB的机器也会有问题，我们将在<<heap-sizing>>中讨论. ==== CPUs 大多数Elasticsearch部署对CPU要求很小. 例如,((("CPUs (central processing units)")))((("hardware", "CPUs"))) 额外的处理器安装问题比其它资源要少. 你应该选择多核的现代处理器. 常规的集群利用2到8核机器. 如果你要在更快的CUPs和更多的核心之间选择，选择更多的核心更好. 多核心提供的额外并发将远远超出稍微快点的时钟速度(注：CPU速度). ==== 硬盘 硬盘对所有的集群都很重要,((("disks")))((("hardware", "disks"))) 对高度索引的集群更是加倍重要 (例如那些存储日志数据的). 硬盘是服务器上最慢的子系统,这意味着那些写多的集群很容易让硬盘饱和, 使得它成为集群的瓶颈. 如果你负担得起SSD, 它将远远超出任何旋转媒介(注：机械硬盘，磁带等). 基于SSD 的节点的查询和索引性能都有提升. 如果你负担得起,SSD是一个好的选择. .检查你的 I/O 调度程序 **** 如果你正在使用SSDs, 确保你的系统 I/O 调度程序是((("I/O scheduler"))) 配置正确的. 当你向硬盘写数据, I/O 调度程序决定何时把数据 _实际_ 发送到硬盘. 大多数 *nix 发行版下的调度程序都叫做 `cfq` (Completely Fair Queuing). 调度程序分配 _时间片_ 到每个进程, 并且优化这些到硬盘的众多队列的传递. 但它是为旋转媒介优化的: 旋转盘片的固有特性意味着它写入数据到基于物理布局的硬盘会更高效. 这对SSD来说是低效的, 然而, 尽管这里没有涉及到旋转盘片. 但是, `deadline` 或 `noop` 应该被使用. deadline 调度程序基于写入等待时间进行优化, `noop` 只是一个简单的FIFO队列. 这个简单的更改可以带来显著的影响. 仅仅是使用正确的调度程序，我们看到了500倍的写入能力提升. **** 如果你使用旋转媒介, 尝试获取尽可能快的硬盘 (高性能服务器硬盘, 15k RPM 驱动器). 使用RAID 0是提高硬盘速度的有效途径, 对旋转硬盘和SSD来说都是如此. 没有必要使用镜像或其它RAID变体, 因为高可用已经通过replicas内建于Elasticsearch之中. 最后, 避免使用网络附加存储 (NAS). 人们常声称他们的NAS解决方案比本地驱动器更快更可靠. 除却这些声称, 我们从没看到NAS能配得上它的大肆宣传. NAS常常很慢, 显露出更大的延时和更宽的平均延时方差, 而且它是单点故障的. ==== 网络 快速可靠的网络显然对分布式系统的性能是很重要的((("hardware", "network")))((("network"))). 低延时能帮助确保节点间能容易的通讯, 大带宽能帮助分片移动和恢复. 现代数据中心网络 (1 GbE, 10 GbE) 对绝大多数集群都是足够的. 即使数据中心们近在咫尺,也要避免集群跨越多个数据中心. 绝对要避免集群跨越大的地理距离. Elasticsearch假定所有节点都是平等的--并不会因为有一半的节点在150ms外的另一数据中心而有所不同. 更大的延时会加重分布式系统中的问题而且使得调试和排错更困难. 和NAS的争论类似, 每个人都声称他们的数据中心间的线路都是健壮和低延时的. 这是真的--直到它不是时 (网络失败终究是会发生的; 你可以相信它). 从我们的经验来看, 处理跨数据中心集群的麻烦事 &#x2013;是根本不值得的. ==== 一般注意事项 获取真正的巨型机器在今天是可能的:((("hardware", "general considerations"))) 成百GB的RAM 和 几十个 CPU 核心. 反之, 在云平台上串联起成千的小虚拟机也是可能的,例如 EC2(注：Amazon Elastic Compute Cloud). 哪条道路是最好的? 通常, 选择中到大型机器更好. 避免使用小型机器,因为你不会希望去管理拥有上千个节点的集群, 而且在这些小型机器上 运行Elasticsearch的开销也是显著的. 与此同时, 避免使用真正的巨型机器. 它们通常会导致资源使用不均衡 (例如, 所有的内存都被使用, 但CPU没有) 而且在单机上运行多个节点时，会增加逻辑复杂度.