博客文章

单个文件，对其内容进行排序，使用sort命令： sort a.txt 去重加-u选项 sort -u a.txt 输出到一个文件 sort -o a.txt_sort -u a.txt 如果是100个1G大小的文件呢？如何进行排序去重呢？使用sort命令也是可以实现的。 第一步：先对单个文件进行排序去重 sort -o a1.txt -u a1.txt sort -o a2.txt -u a2.txt sort -o a3.txt -u a3.txt sort -o a4.txt -u a4.txt 。。。。 sort -o a100.txt -u a100.txt 第二步：使用sort的合并排序 sort -o a.txt -u -m a*.txt -m选项 表示merge已经有序的文件，如果文件事先没有排好序，这个可能会出错。 在执行merge的时候，你可能会遇到空间不足，无法写/tmp/sortXXXX的错误。 因为是多个大文件的合并操作，内存不够用，肯定是要写临时文件的。默认sort是写到/tmp目录下。 还好sort命令想的周到，你可以通过-T 选项指定一个较大空间的磁盘目录作为sort的临时文件目录。 sort -o a.txt -T /disk/temp -u -m a*.txt 最后等结果吧。

写博客，写的不好的时候，就想删除，目录结构设计的不合理，就想更改。但是有一些网页已经被百度等搜索引擎收录了。用户访问的时候就会显示404页面，表示页面不存在。 在过去，网站通常的做法是把404页面写上友好的提示语，或者随机显示一则笑话，甚至是直接跳转到主页。 现在有很多大型的网站，像百度、腾讯等都已经把404页面改为公益广告，特别是寻找丢失儿童的广告。例如腾讯公司内部员工志愿者就发起了这样一起互联网公益活动，建议站长博主在自己的404页面中嵌入一段简单的代码，就能通过互联网来迅速传播失踪儿童信息，从而提高找回失踪儿童的概率。 我认为这是个好主意，从今天开始，赵岩的博客正式加入公益404页面，打开不存在的页面都会跳转到公益寻人广告页面。 比如：http://zhaoyanblog.com/404.html

华为昨日公布了P8Max这款旗舰机的价格（3788元），同时也向媒体公布了其上半年手机出货量的情况。据华为介绍称，2015年上半年，华为手机出货量达到5000万部，5月单月出货量便达到1000万部，销量同比增长了40%，中国市场占比50%。 提到P8 Max这款新机时，华为终端中国区总裁朱平表示，中国中、高、低端手机都有一定的市场空间，而价格并非决定消费者需求的关键。P8 Max配置了6.8英寸的超大屏幕，主打高端商务人群，3788元的价格在中国手机市场中也属于高端水平。 华为CMO杨哲杨哲也表示，只要产品能够触及用户的真正需求，价格并不是问题。华为P8 Max国行版将于6月26日正式开售

cassandra是集群部署，多个节点，多个数据备份，一两个节点挂掉，一般不会有数据丢失。只要删除当掉的节点，对其它节点进行repair，数据都会自动均衡到完整的份数。 但是如果大面积节点掉电，或者机房着火那就肯定要丢失数据了，使用cassandra作为数据存储的业务，肯定是很大的业务，数据量超大的那种。机房容灾肯定是必不可少的。 cassandra提供多种多数据中心部署、机架敏感策略。这里介绍一种最普通的一种: GossipingPropertyFileSnitch GossipingPropertyFileSnitch策略支持简单的多个数据中心，和多机架。 第一步： 在cassandra.yaml配置文件中指定集群支持该策略： endpoint_snitch: GossipingPropertyFileSnitch 第二步： 在cassandra.yaml的seeds中把两个数据中心的种子节点都配上 seeds: “192.168.22.101,192.168.22.102,192.168.23.101,192.168.23.102” 第三步： 配置cassandra-rackdc.properties 每台机器都配置自己所属的数据中心名称和机架名称 dc=DC1 rack=RAC1 配置机架的目的是，防止整个机框掉电，数据丢失。cassandra可以尽量保证同一份数据的多个副本不存在于同一个机架上。 这就要求你的机架个数要大约等于你的数据副本个数，同时每个机架的节点个数尽量相同，否则会导致某些节点数据偏多，分布不均 第四步 创建keyspace使用NetworkTopologyStrategy策略，并且制定每个集群的份数。 CREATE KEYSPACE mykeyspace WITH replication = { ‘class’: ‘NetworkTopologyStrategy’, ‘DC1’: ‘3’, ‘DC2’: ‘3’ }; 第五步 客户端使用数据一致性策略，从QUORUM改为LOCAL_QUORUM。这样客户端会先从LOCAL数据中查询，LOCAL无法查询，再从REMOTE数据中心进行查询。 cassandra JAVA官方驱动，把默认首先连上的节点所属的数据中心视为LOCAL数据中心。所以你不要容灾数据中心节点IP配到了代码中。

6月15日 @华为荣耀官方微博确定了荣耀7的发布时间和地点： 2015年6月30日 北京工业大学奥林匹克体育馆 海报是一个大大的指纹，确认荣耀7是带指纹识别无疑。 这是工信部网站注册型号为PLK-AL10的一款手机，想必就是荣耀7，从背面看，荣耀7的指纹识别是借用了Mate7的设计。 至于更多的细节和科技提升，我们要等发布会当天知晓了。

Elasticsearch 是默认延迟加载fielddata到内存里的。当elasticsearch第一次遇到一个查询需要一个指定field的fielddata的时候，就会把索引的每个段中整个field加载到内存。对于小段，这是个可以忽略不计的时间，但是如果你有一些5G大小的段并且需要加载10GB的fielddata到内存里，这个过程需要数十秒，习惯于秒内响应时间的用户会被网突如其来的迟钝所打击。 有三种方法应对这种延迟尖峰： Eagerly load fielddata（饿汉式（预）加载fielddata） Eagerly load global ordinals（饿汉式（预）加载全局序数） Prepopulate caches with warmers （使用warmer提前加载缓存）。 所有这些都是一个意思：预先加载fielddata到内存里，这样当用户需要执行一个搜索的时候就感受不到延迟了。 饿汉式（预）加载fielddata 首先是预先加载（而不是默认的延迟加载），当一个新的段形成时（无乱是刷新，写入或者是合并），可以预先加载的field会提前把段的fielddata加载到内存里，在这段可以用于搜索之前。 这意味着当你第一次查询的时候，如果碰到在这个段上，你不需要再触发加载fielddata的操作，它们已经在内存中了，这会防止你的用户遇到一些冷到缓存而发生延迟尖峰。 预先加载是基于每个field的，所以你可以控制哪些field进行预加载。 PUT /music/_mapping/_song { "price_usd": { "type": "integer", "fielddata": { "loading" : "eager" } } } 备注: 通过设置fielddata.loading: eager，告诉elasticsearch预先加载这个field的内容到内存里。 fielddata的加载可以设置成饿汉模式（预先加载）还是懒惰模式（延迟加载），使用update-mapping的api。 预先加载是简单对fielddata加载的开销的转移，从查询时间转义到刷新时刻。 大段的刷新时间会比小段的时间长，通常大段的产生都是由哪些已经可搜素的小段合并而来的，所以慢一点的刷新时间不是那么重要（译者注：意思是大段的刷新时间长不影响你的搜索，在大段合并成前的小段可以用于搜索）。 全局序数 其中一项用于减少string类型的fielddata占用内存的技术叫做序数。 假设我们有十亿条文档，每个文档都有一个status的field，只有三个值：status_pending, status_published, status_deleted，如果我们把所有的status加载到内存里，每个文档需要14-16byte，也就是说15GB 相反，我们可以确认这三个特殊的字符串，对他们排序，依次编号0,1,2 Ordinal | Term ------------------- 0 | status_deleted 1 | status_pending 2 | status_published 序号对应的字符串值要在序号列表中存储一次，每个文档只要使用他们的编号来表示他们所包含的值就可以了。 Doc | Ordinal ------------------------- 0 | 1 # pending 1 | 1 # pending 2 | 2 # published 3 | 0 # deleted 这个可以把15GB的内存占用减少到小于1GB ...

最近几日 @华为荣耀 官方微博已经连续发布微博海报，表示6月8日会有新产品发布。 无论是从小苹果的苹果把，还是汽水瓶的吸管，形状都预示这款产品很可能是荣耀旗舰机型荣耀7。 而且荣耀6是去年6月24日发布的，时隔一年，荣耀7也是时候横空出世了。 但是总觉得这个宣传还不到位，首先发布会在一周前才开始宣传，而且至今也没有曝光媒体邀请函，以及发布会地点，有点反常。 很希望这次发布的是荣耀7，但是也有可能是荣耀其它产品，期待6月8日发布会。 6月6日 有那么一点冰爽，#有点意思# 6月5日 有那么一点勇敢，#有点意思# 6月4日 有那么一点诱惑，#有点意思# 6月3日 有那么一点速度，#有点意思# #李娜产女# 荣耀也有新宝贝！@李娜#有点意思# 6月2日 有那么一点生活，#有点意思# 6月1日 想象力概括了世界的一切。——阿尔伯特·爱因斯坦

ThreadPool部分 Elasticsearch 内部使用了线程池，通过这些线程池之间的合作完成工作，在需要时传递工作。一般来说你不需要调整和优化线程池。但是有时候你看着这些线程池的状态，对你掌握你的集群行为是很有帮助的。 这有十几个线程池，他们的格式都是类似的： "index": { "threads": 1, "queue": 0, "active": 0, "rejected": 0, "largest": 1, "completed": 1 } 每个线程都列出了配置的线程数，其中有多少个线程是正在处理事务的，也就是活动的，还有多少等待处理的事务在队列里。 如果队列满了，超出了限制，新的事务就会开始被拒绝，你可以看到拒绝的事务的统计，这通常表示你的集群正处在一个资源瓶颈，因为一个满的队列表示你的集群或者节点正在以最大的速度处理事务，但是依然赶不上新事务增加的速度。 关于bulk的拒绝 如果你的线程队列出现拒绝请求的事情，那么醉有可能发生的就是bulk批量索引的请求，通过采用并发导入线程，很容易发给elasticsearch很多的bulk请求，并发请求越多越好吗？ 现实中，任何集群都有一定的线程，造成入不敷出。一旦这个阈值达到了，你的队列就会被迅速的填满，新的bulk请求就会被拒绝。 这是一个好事，队列的拒绝是对压力的一个有效措施，他们告诉你你的集群正在处于最大的容量，这要好过把数据全部塞到内存队列里。增大队列大小不会提升性能，它只会隐藏问题，如果你的集群每秒只能处理1万个文档，这和你的队列大小是100还是一千万没有任何关系，你的集群每秒的处理能力仍然是1万个文档。 队列只会隐藏性能问题，并且带来数据丢失的风险，在队列里的表示还没有被处理的，如果你的节点挂了，那么这些请求就会永远的丢失了，此外队列会消耗很大的内存，这不是个好主意。 最好我们通过优雅的解决队列满了的问题来清理队列。当你遇到bulk拒绝请求时候，你应该采取如下措施： 1、停止插入线程3-5秒 2、从bluk请求里提取被拒绝的操作，可能大部分请求都成功了。bulk的响应里会告诉你哪些操作成功了，哪些操作被拒绝了。 3、把拒绝的操作重新生成一个新的bulk请求。 4、如果再有拒绝请求发生，就重复上面的步骤。 通过这种方式，你的代码会自然的适应你的集群的负载，自然的减压。 请求拒绝不是错误，它们只是表示你需要过会重试。 有十几个线程池，大部分你可以忽视，但是有少部分需要你特别注意： indexing 正常的索引文档的请求 bulk 批量请求，这有区别于非批量的请求 get 根据id获取文档的操作 search 索引的检索和查询请求 merging 专门管理lucene合并的线程池 FS和Network部分（剩余空间和网络） 继续看node stats api返回的信息，你会看到一个关于文件系统的统计信息，剩余空间，数据存放目录，磁盘io等待。如果你没有监控剩余磁盘空间大小，你可以从这里得到。磁盘io也是很容易得到，但是一些更专业的命令行工具（例如iostat）可能更有用。 很显然，如果你的磁盘空间不足了，elasticsearch肯定完蛋了，所以一定要保证充足的磁盘空间。 下面是关于network统计的两个部分： "transport": { "server_open": 13, "rx_count": 11696, "rx_size_in_bytes": 1525774, "tx_count": 10282, "tx_size_in_bytes": 1440101928 }, "http": { "current_open": 4, "total_opened": 23 }, transport: 显示了网络传输的基本信息，这涉及到节点之间的通信（通常是9300端口）和一些客户端和节点之间的链接。如果你看到很多链接在这里，不要担心，elasticsearch会保持大量的节点之间的链接。 ...

操作系统和进程部分 操作系统和进程部分的含义是很清楚的，这里不会描述的很详细。他们列出了基本的资源统计，例如CPU和负载。操作系统部分描述了整个操作系统的情况，进程部分只是描述了Elasticsearch的JVM进程的使用情况。 这显然是很有用的统计， 但是往往会被忽视，一些统计包括如下部分： CPU 负载 内存使用情况 swap使用情况 打开文件句柄数 JVM部分 jvm部分包含一些有关于运行elasticsearch的jvm进程的关键信息。最重要的是，它包含了垃圾回收方面的细节，这对你的elasticsearch的集群的稳定性有很大影响。 垃圾收集（GC）入门 在我们描述这个之前，很有必要先介绍下GC以及它对elasticsearch的影响。如果你对jvm中的GC很熟悉，可以跳过这一章。 java是一个自己进行垃圾回收的语言，也就是说程序员不需要主动管理内存的分配和释放。程序员只要专心写自己的代码，java虚拟机会管理根据需要分配内存的过程，然后当内存不再使用的时候，它自己会去释放。 当内存被分配给JVM进程，它会被分配成一个叫堆的大块区域。JVM会把这个堆分成两组，叫做“代”： 年轻代（或者伊甸园） 新实例化的对象就在这里分配空间，年轻代的空间通常很小，大约100MB-500MB。年轻代包含两个幸存者区域 老年代 存储那些老的对象的区域。这些对象是长期存在，并且持续很长时间。老年代通常比年轻代大很多。你可以看到elasticsearch节点的老年代可能大到30GB 当一个对象被实例化后，它会被放置到年轻代，当年轻代的空间满了，一个年轻代的垃圾回收就启动了。那些仍然存活的对象就会被移动到其中一个幸存者区域。而死了的对象就会被清除了。如果一个对象在年轻代中经历了多次GC仍然幸存，那它将被晋升到老年代。 类似的过程也发生在老年代，当老年代的空间越来越满了，一个垃圾回收就启动了，同时死了对象会被清除。 天下没有免费的午餐，年轻代和老年代的垃圾回收都包含一个“stop-the-world”的阶段。在这个时间内，JVM会停止程序的执行，进行对象的标记和收集，在这个stop-the-world的阶段，没有任何事情发生，请求不会被处理，ping不会被会回应。shards不会再进行迁移。整个世界真的停止了。 对于年轻代这不是一个问题，因为它很小，GC执行的很快。但是对于大一点的老年代，缓慢的GC意味着1s甚至15s的停顿，这对于一个服务器软件来说是不可接受的。 垃圾回收在JVM是很复杂的算法，为了减少停顿做了很多的工作。同时Elasticsearch很努力适应GC，比如通过内部对象的重用，利用网络缓冲区，并挺贵一些特征值例如文档的数量。但是GC的频率和长短是需要你特别留意的信息，因为它是集群不稳定的头号元凶。 如果一个集群经常性的发生长时间GC，那么你的集群一定内存不足并且负载特别高。这些长时间GC会导致节点周期性的脱离集群。这种不稳定会导致分片数据不断的重新生成，以保证集群内的平衡以及足够的分片数量。这会增加网络贷款和磁盘IO，同时你的集群还要承担进行正常的索引数据和查询。 简而言之，长时间的GC是很糟糕的，需要尽可能的减少。 因为GC对Elasticsearch如此重要，你必须对node stats的API显示的这个部分特别熟悉才行。 "jvm": { "timestamp": 1408556438203, "uptime_in_millis": 14457, "mem": { "heap_used_in_bytes": 457252160, "heap_used_percent": 44, "heap_committed_in_bytes": 1038876672, "heap_max_in_bytes": 1038876672, "non_heap_used_in_bytes": 38680680, "non_heap_committed_in_bytes": 38993920, jvm部分首先列出的是有关堆内存使用情况的一般情况，你可以看到多少heap被用到，有多少可以被使用（已经分配了线程），还有堆内存最大可以长到多少。理想情况下heap_committed_in_bytes应该和heap_max_in_bytes相同，如果被分配的堆较小，那JVM将会不得不调整堆的大小，这个过程代价是很高的。如果你的这两个值是不同的，请看《Heap: Sizing and Swapping》章节，确认你配置的是否正确。 heap_used_percent 是你必须盯着看的一个有用的参数。Elasticsearch配置的是当堆使用到75%的时候进行GC，如果你的节点总是大约75%，那你节点正在承受内存方面的压力，这是一个告警，预示着你不久就会出现慢GC。 如果你的heap使用率一直在85%以上，那你有麻烦了，90-95%的概率会因为10-30s的GC 发生性能问题，这还是好的，最坏的就是发生内存溢出。 "pools": { "young": { "used_in_bytes": 138467752, "max_in_bytes": 279183360, "peak_used_in_bytes": 279183360, "peak_max_in_bytes": 279183360 }, "survivor": { "used_in_bytes": 34865152, "max_in_bytes": 34865152, "peak_used_in_bytes": 34865152, "peak_max_in_bytes": 34865152 }, "old": { "used_in_bytes": 283919256, "max_in_bytes": 724828160, "peak_used_in_bytes": 283919256, "peak_max_in_bytes": 724828160 } } }, young, survivor, and old sections 显示了每个代在GC中的使用情况，供你分析。这些数据方便你看到他们的相对大小，但是对于你调查问题往往不是很重要。 ...

第一：去掉一些不用的html head内容，让页面更小 在function.php中加入： remove_action( ‘wp_head’, ‘wp_generator’); remove_action( ‘wp_head’, ‘wlwmanifest_link’); remove_action( ‘wp_head’, ‘rsd_link’); remove_action( ‘wp_head’, ‘index_rel_link’ ); remove_action( ‘wp_head’, ‘parent_post_rel_link’, 10, 0 ); remove_action( ‘wp_head’, ‘start_post_rel_link’, 10, 0 ); remove_action( ‘wp_head’, ‘adjacent_posts_rel_link_wp_head’, 10, 0 ); remove_action( ‘wp_head’, ‘feed_links’, 2 ); remove_action( ‘wp_head’, ‘feed_links_extra’, 3 ); remove_action( ‘wp_head’, ‘wp_print_head_scripts’, 9 ); remove_action( ‘wp_head’, ‘rel_canonical’ ); remove_action( ‘wp_head’, ‘wp_shortlink_wp_head’, 10, 0 ); 第二：去掉一些定时任务，这些定时任务会频繁访问数据库和网络 在function.php中加入： remove_action( ‘init’, ‘wp_schedule_update_checks’ ); remove_action( ’load-plugins.php’, ‘wp_update_plugins’ ); remove_action( ’load-themes.php’, ‘wp_update_themes’ ); remove_action( ’load-update-core.php’, ‘wp_update_plugins’ ); remove_action( ’load-update-core.php’, ‘wp_update_themes’ ); remove_action( ’load-update.php’, ‘wp_update_plugins’ ); remove_action( ’load-update.php’, ‘wp_update_themes’ ); remove_action( ‘upgrader_process_complete’, ‘wp_update_plugins’ ); remove_action( ‘upgrader_process_complete’, ‘wp_update_themes’ ); remove_action( ‘upgrader_process_complete’, ‘wp_version_check’ ); remove_action( ‘wp_maybe_auto_update’, ‘wp_maybe_auto_update’ ); remove_action( ‘wp_update_plugins’, ‘wp_update_plugins’ ); remove_action( ‘wp_update_themes’, ‘wp_update_themes’ ); remove_action( ‘wp_version_check’, ‘wp_version_check’ ); ...

集群的健康只是一个方面，它是对整个集群所有方面的一个很高的概括。节点状态的api是另外一个方面，它提供了关于你的集群中每个节点令你眼花缭乱的统计数据。 节点的状态提供了那么多的统计数据，在你很熟悉它们执勤，你可能不确定哪些指标是至关重要。我们会把需要监控的最重要的几个指标跳出来（我们建议你把所有的统计指标记录下来，例如使用Marvel插件，因为你不知道你哪天可能就需要）。 节点状态的API可以通过下面的方式执行 GET _nodes/stats 在输出内容的开头，我们可以看到集群的名字和我们第一个node的信息： { "cluster_name": "elasticsearch_zach", "nodes": { "UNr6ZMf5Qk-YCPA_L18BOQ": { "timestamp": 1408474151742, "name": "Zach", "transport_address": "inet[zacharys-air/192.168.1.131:9300]", "host": "zacharys-air", "ip": [ "inet[zacharys-air/192.168.1.131:9300]", "NONE" ], ... 节点会根据一个hash值的顺序来显示，也就是node的uuid值。还有一些关于node的网络属性会显示（例如传输地址和HOST）。这些信息有助于调试发现问题，比如那些节点没有加入集群。通常你可能会发现端口用错了，或者节点绑错了IP地址等等。 Indices部分 indices部分列出的是对于所有的索引在该节点上的汇总信息。 "indices": { "docs": { "count": 6163666, "deleted": 0 }, "store": { "size_in_bytes": 2301398179, "throttle_time_in_millis": 122850 }, 它返回的统计信息可以分成这样几个部分： docs: 显示有多少文档在该节点，以及有多少删除的文档还没有从数据段中清除出去。 store: 显示该节点消耗了多少物理存储，这个数据包含主分片和副分片，如果throttle_time_in_millis太大，说明你设置的磁盘流量太低（参考段的合并一章节） "indexing": { "index_total": 803441, "index_time_in_millis": 367654, "index_current": 99, "delete_total": 0, "delete_time_in_millis": 0, "delete_current": 0 }, "get": { "total": 6, "time_in_millis": 2, "exists_total": 5, "exists_time_in_millis": 2, "missing_total": 1, "missing_time_in_millis": 0, "current": 0 }, "search": { "open_contexts": 0, "query_total": 123, "query_time_in_millis": 531, "query_current": 0, "fetch_total": 3, "fetch_time_in_millis": 55, "fetch_current": 0 }, "merges": { "current": 0, "current_docs": 0, "current_size_in_bytes": 0, "total": 1128, "total_time_in_millis": 21338523, "total_docs": 7241313, "total_size_in_bytes": 5724869463 }, indexing： 表示索引文档的次数，这个是通过一个计数器累加计数的。当文档被删除时，它不会减少。注意这个值永远是递增的，发生在内部索引数据的时候，包括那些更新操作。 ...

Elasticsearch已经有很好的默认值，特别是涉及到性能相关的配置或者选项。如果你有什么拿不准的，最好就不要动它。我们已经目睹了数十个因为错误的设置而导致集群毁灭，因为它的管理者总认为他改动一个配置或者选项就可以带来100倍的提升。 注意：请阅读全文，所有的配置项都同等重要，和描述顺序无关，请阅读所有的配置选项，并应用到你的集群中。 其它数据库可能需要调优，但总得来说，Elasticsearch不需要。如果你遇到了性能问题，最好的解决方法通常是更好的数据布局或者更多的节点。在Elasticsearch中有很少的"神奇的配置项"，如果存在，我们也已经帮你优化了。 指定名字 Elasticsearch默认启动的集群名字叫elasticsearch，你最好给你的生产环境的集群改个名字，改名字的目的很简单，就是防止某个人的笔记本加入到了集群，造成意外。简单修改成elasticsearch_production ，会省掉多次心痛~。 你可以在你的elasticsearch.yml中修改： cluster.name: elasticsearch_production 同样，修改节点的名字也是明智的，就像你现在可能发现的那样，Elasticsearch会在你的节点启动的时候随机给它指定一个名字。这在你开发的时候可能觉得很萌，但是当凌晨3点钟，你还在尝试会议哪台物理机是Tagak the Leopard Lord.的时候，你就不觉得萌了。 更重要的是，这些名师是在启动的时候产生的，每次启动节点，它都会得到一个新的名字，这可以使日志混淆，因为所有节点的名称都是不断变化的。 这些可能性都是很无聊的，我们建议你给每个及诶点一个有意义的名字-一个清楚的，描述性的名字，同样你可以在elasticsearch.yml中配置： node.name: elasticsearch_005_data 路径 默认情况下，Eleasticsearch会把插件、日志以及你最重要的数据放在安装目录下。这会带来不幸的事故。即如果你重新安装Elasticsearch的时候就可能不小心把安装目录覆盖了，如果你不小心，你就可能把你的全部数据删掉了。 不要笑，这种情况，我们见过很多次了。 最好的选择就是把你的数据目录配置到安装目录以外的地方，同样你也可以选择转移你的插件和日志目录。 可以更改如下： path.data: /path/to/data1,/path/to/data2 Path to log files: path.logs: /path/to/logs Path to where plugins are installed: path.plugins: /path/to/plugins 注意：你可以通过逗号分隔指定多个目录。 数据可以保存到多个不同的目录，每个目录如果是挂载在不同的硬盘，做一个人RAID 0是一个简单而有效的方式。Elasticsearch会自动把数据分隔到不同的目录，以便提高性能。 最小主节点数 minimum_master_nodes的设定对你的集群的稳定及其重要，当你的集群中有两个masters的时候，这个配置有助于防止集群分裂。 如果你发生了一个集群分裂，你集群就会处在丢失数据的危险中，因为master节点是被认为是这个集群的最高统治者，它决定了什么时候新的索引可以创建，多少分片要移动等等。如果你有两个master节点，你的数据的完整性将得不到保证，因为你有两个master节点认为他们有集群的控制权。 这个配置就是告诉Elasticsearch当没有足够master候选节点的时候，就不要进行master选举，等master候选节点足够了才进行选举。 该配置必须应该配置成master候选节点的法定个数(大多数个),法定个数就是（master候选节点个数/2)+1. 这里有几个例子： *如果你有10个节点（能保存数据，同时能成为master） 法定数就是6 *如果你有3个候选master，和100个数据节点，法定数就是2，你只要数数那些可以做master的节点数就可以了。 *如果你有两个节点，你遇到难题了，法定数当然是2，但是这意味着如果有一个节点挂掉，你整个集群就不可用了。设置成1可以保证集群的功能，但是就无法保证集群分裂了，像这样的情况，你最好至少保证有3个节点。 elasticsearch.yml中这样配置： discovery.zen.minimum_master_nodes: 2 但是由于ELasticsearch是动态的，你可以很容易的添加和删除节点，这会改变这个法定个数，如果你不得不修改索引的节点的配置并且重启你的整个集群为了让配置生效，这将是非常痛苦的一件事情。 基于这个原因，minimum_master_nodes （还有一些其它配置），允许通过API调用的方式动态进行配置，当你的集群在线运行的时候，你可以这样修改配置： PUT /_cluster/settings { “persistent” : { “discovery.zen.minimum_master_nodes” : 2 } } 这将成为一个永久的配置，并且无论你配置项里配置的如何，这个将优先生效。当你添加和删除master节点的时候，你需要更改这个配置。 集群恢复方面的配置项 当你集群重启时，几个配置项影响你的分片恢复的表现。首先，我们必须明白，如果什么也没配置将会发生什么。 想象一下假设你有10个节点，每个节点保存一个分片，主分片或者副分片，也就是有一个有5个主分片/1个副本 的索引。你需要停止整个集群进行休整（举个例子，为了安装一个新的驱动程序）。当你重启你的集群，很自然会出现5个节点已经起动了，还有5个还没启动的场景。 ...

Elasticsearch默认安装后设置的内存是1GB，对于任何一个业务部署来说，这个都太小了。如果你正在使用这些默认堆内存配置，你的集群配置可能有点问题。 这里有两种方式修改Elasticsearch的堆内存（下面就说内存好了），最简单的一个方法就是指定ES_HEAP_SIZE环境变量。服务进程在启动时候会读取这个变量，并相应的设置堆的大小。举例，你可以用下面的命令设置它 export ES_HEAP_SIZE=10g 此外，你也可以通过命令行参数的形式，在程序启动的时候把内存大小传递给它： ./bin/elasticsearch -Xmx10g -Xms10g 备注:确保Xmx和Xms的大小是相同的，防止程序在运行时改变大小，这个是很废的。 一般来说设置ES_HEAP_SIZE环境变量，比直接写-Xmx10g -Xms10g更好一点。 把你的内存的一半给Lucene 一个常见的问题是配置一个大内存，假设你有一个64G内存的机器，我的天，你想把64G内存给Elasticsearch吗？ 越大越好！ 当然，内存对于Elasticsearch来说绝对是重要的，用于更多的内存数据提供更快的操作。而且还有一个内存消耗大户-Lucene Lucene的设计目的是把底层OS里的数据缓存到内存中。Lucene的段是分别存储到单个文件中的，这些文件都是不会变化的，所以很利于缓存，同时操作系统也会把这些段文件缓存起来，以便更快的访问。 Lucene的性能取决于和OS的交互，如果你把所有的内存都分配给Elasticsearch，不留一点给Lucene，那你的全文检索性能会很差的。 最后标准的建议是把50%的内存给elasticsearch，剩下的50%也不会没有用处的，Lucene会很快吞噬剩下的这部分内存。 不要超过32G 这里有另外一个原因不分配大内存给Elasticsearch，事实上jvm在内存小于32G的时候会采用一个内存对象指针压缩技术。 在java中，所有的对象都分配在堆上，然后有一个指针引用它。指向这些对象的指针大小通常是CPU的字长的大小，不是32bit就是64bit，这取决于你的处理器，指针指向了你的值的精确位置。 对于32位系统，你的内存最大可使用4G。对于64系统可以使用更大的内存。但是64位的指针意味着更大的浪费，因为你的指针本身大了。浪费内存不算，更糟糕的是，更大的指针在主内存和缓存器（例如LLC, L1等）之间移动数据的时候，会占用更多的带宽。 java 使用一个叫内存指针压缩的技术来解决这个问题。它的指针不再表示对象在内存中的精确位置，而是表示偏移量。这意味着32位的指针可以引用40亿个对象，而不是40亿个字节。最终，也就是说堆内存长到32G的物理内存，也可以用32bit的指针表示。 一旦你越过那个神奇的30-32G的边界，指针就会切回普通对象的指针，每个对象的指针都变长了，就会使用更多的CPU内存带宽，也就是说你实际上失去了更多的内存。事实上当内存到达40-50GB的时候，有效内存才相当于使用内存对象指针压缩技术时候的32G内存。 这段描述的意思就是说：即便你有足够的内存，也尽量不要超过32G，因为它浪费了内存，降低了CPU的性能，还要让GC应对大内存。 *我有一个1TB内存的机器 这个32GB的线是很很重要的，那如果你的机器有很大的内存怎么办呢？现在的机器内存普遍增长，你现在都可以看到有300-500GB内存的机器。 首先，我们建议编码使用这样的大型机 其次，如果你已经有了这样的机器，你有两个可选项： >你主要做全文检索吗？考虑给Elasticsearch 32G内存，剩下的交给Lucene用作操作系统的文件系统缓存，所有的segment都缓存起来，会加快全文检索。 >你需要更多的排序和聚合？你希望更大的堆内存。你可以考虑一台机器上创建两个或者更多ES节点，而不要部署一个使用32+GB内存的节点。仍然要坚持50%原则，假设 你有个机器有128G内存，你可以创建两个node，使用32G内存。也就是说64G内存给ES的堆内存，剩下的64G给Lucene。 如果你选择第二种，你需要配置cluster.routing.allocation.same_shard.host:true。这会防止同一个shard的主副本存在同一个物理机上（因为如果存在一个机器上，副本的高可用性就没有了）。 swapping是性能的坟墓 这是显而易见的，但是还是有必要说的更清楚一点，内存交换到磁盘对服务器性能来说是致命的。想想看一个内存的操作必须是快速的。 如果内存交换到磁盘上，一个100微秒的操作可能变成10毫秒，再想想那么多10微秒的操作时延累加起来。不难看出swapping对于性能是多么可怕。 最好的办法就是在你的操作系统中完全禁用swapping。这样可以暂时禁用： sudo swapoff -a 为了永久禁用它，你可能需要修改/etc/fstab文件，这要参考你的操作系统相关文档。 如果完全禁用swap，对你来说是不可行的。你可以降低swappiness 的值，这个值决定操作系统交换内存的频率。这可以预防正常情况下发生交换。但仍允许os在紧急情况下发生交换。 对于大部分Linux操作系统，可以在sysctl 中这样配置： vm.swappiness = 1 备注：swappiness设置为1比设置为0要好，因为在一些内核版本，swappness=0会引发OOM（内存溢出） 最后，如果上面的方法都不能做到，你需要打开配置文件中的mlockall开关，它的作用就是运行JVM锁住内存，禁止OS交换出去。在elasticsearch.yml配置如下： bootstrap.mlockall: true 原文地址：https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html.

从今日起，我的博客正式迁入阿里云ECS服务器了。之前是用的西部数码west263的虚拟机。图的就是便宜。便宜没好货，服务器三天两头的出故障。 这是dnspod的部分监控信息： zhaoyanblog.com johnyannj.gotoip2.com. 01-29 17:21 01-29 17:39 17分钟 53秒 zhaoyanblog.com johnyannj.gotoip2.com. 01-23 23:41 01-23 23:51 10分钟 27秒 zhaoyanblog.com johnyannj.gotoip2.com. 01-21 01:01 01-21 01:05 4分钟 30秒 zhaoyanblog.com johnyannj.gotoip2.com. 01-16 18:25 01-16 18:54 28分钟 29秒 zhaoyanblog.com johnyannj.gotoip2.com. 01-12 11:05 01-12 11:24 19分钟 19秒 zhaoyanblog.com johnyannj.gotoip2.com. 01-12 02:57 01-12 07:40 4小时 43分钟 52秒 zhaoyanblog.com johnyannj.gotoip2.com. 01-11 20:50 01-11 21:14 24分钟 3秒 zhaoyanblog.com johnyannj.gotoip2.com. 01-11 15:52 01-11 16:13 21分钟 5秒 zhaoyanblog.com johnyannj.gotoip2.com. 01-11 11:51 01-11 12:08 16分钟 31秒 zhaoyanblog.com johnyannj.gotoip2.com. 01-11 05:55 01-11 07:49 1小时 54分钟 6秒 ...

在Elasticsearch中有一些热点，人们可能不可避免的会碰到。我们所理解的，所有的调整就是为了优化，但是这些调整，你真的不需要理会它。因为它们经常会被乱用，从而造成系统的不稳定或者糟糕的性能，甚至两者都有可能。 垃圾收集器 在章节已经有一个简短的介绍，JVM使用一个垃圾收集器来释放不再使用的内存，这篇内容的确是上一篇的一个延续，但是因为重要，所以值得单独拿出来作为一节。 不要更换默认的垃圾收集器！ Elasticsearch默认的垃圾收集器是CMS垃圾收集器。这个垃圾收集器因为可以和应用并行处理，所以有很小的暂停，当然它有两个stop-the-world阶段，处理大内存也有点吃力。 尽管这些缺点，它也是目前像Elasticsearch这样低延迟需求的软件的最佳垃圾收集器。官方建议使用CMS。 现在有一款新的垃圾收集器，叫G1垃圾收集器，这款GC设计目的是比CMS更小的暂停时间，以及对大内存的处理能力。它的原理是把内存分成许多区域，并且预测哪些区域最有可能需要回收内存。G1 GC通过首先收集这些区域，产生更小的暂停时间，从而能应对更大的内存。 听起来不错，很遗憾的是G1 GC还是太新，经常有bug爆出，这些bug大都是段错误那种，会导致硬盘崩溃。Lucene的测试套件对GC是很严格残酷的，好像G1 GC一直都无法完全胜任。 我们很希望在将来某一天推荐使用G1 GC，但是对于现在，它还不能足够稳定以满足Elasticsearch和luncene的要求。 线程池 许多人喜欢调整线程池，无论什么原因，人们好像都无法抵挡的想增加线程数。索引太多了？增加线程！搜索太多了，增加线程！节点空闲率低于95%？ 增加线程！ Elasticsearch默认的线程设置已经是很合理的了。对于所有的线程池（除了搜索的），线程个数是根据CPU核心数设置的。如果你有8个核，你可以同时运行8个线程，那么对于一些线程池，你设置8个线程是合适的。 搜索线程池设置的大一点，是核心数的3倍。 你可能争辩说，一些线程会堵塞在IO处，所以你才想加大线程的。对于elasticsearch来说，这不是问题，因为大多数IO的操作是由Lucene线程管理的，而不是Elasticsearch。 此外，线程池通过彼此之间的合作工作。你不需要担心网络相关的线程因为它在等待磁盘写入而堵塞。因为网络线程早已把这个工作交给另外的线程池，并且网络进行了响应。 最后，你的处理器的计算容量是有限的，拥有更多的线程会导致你的处理器频繁切换线程上下文。一个处理器同时只能运行一个线程，所以当它需要切换到其它不同的线程的时候，它会存储当前的状态（寄存器等等），然后加载另外一个线程。如果幸运的话，这个切换发生在同一个cpu核心，如果不幸的话，这个切换可能发生在不同的核心，这就需要在内核间总线上进行传输。 这个上下文的切换，会循环的带来管理调度开销，在现代的CPU上，估计高达30us，也就是说线程会被堵塞30us，如果这个时间用于线程的运行，估计早就结束了。 人们经常稀里糊涂的设置线程池的值，8个核的CUP，我们见过有人配了60,100甚至1000个线程，这些设置只会让CPU实际工作效率更低。 所以下次请不要调整线程池的线程数，如果真想调整，一定要关注你的CPU核心数，最多设置成核心数的两倍，再多了都是浪费。 原文地址：http://www.elastic.co/guide/en/elasticsearch/guide/current/_don_8217_t_touch_these_settings.html