GitHub发布代码搜索功能故障原因

标签: github 布代 搜索 | 发表时间:2013-02-07 16:06 | 作者:
出处:http://news.cnblogs.com/

1 月 24 日、25 日,GitHub 新上线的代码搜索功能出现故障。2 月 4 日,运维负责人 Will Farrington一篇博客帖子中,GitHub 团队分析了当时的经过,以及他们如何移除问题以防止再次发生故障。

文中首先介绍了发生故障的背景。

GitHub 此前的搜索使用 Solr 实现,新上线的搜索基于 elasticsearch,运行在多个集群上。由于代码搜索索引很大,GitHub 专门为其指定了一个集群。目前该集群包括 26 个存储节点和 8 个客户端节点。存储节点负责保存构成搜索索引的数据,而客户端节点负责协调查询活动。每个搜索节点中有 2TB 的 SSD 存储。

发生故障时,这个节点中保存了大概 17TB 代码。数据以分片方式跨越整个集群存储,每个分片(shard)在另一个节点上有一份复制作为冗余,整个用去大约 34TB 存储空间。整个存储容量占用了 67% 左右。代码搜索集群运行在 Java 6 和 elasticsearch 0.19.9 上。当时这个集群已经正常运行了好几个月。

在 1 月 17 日、星期四,我们准备上线这个代码搜索功能,以完成整个统一搜索的实现。在此之前,我们注意到 elasticsearch 已经发布了 0.20.2 版本,其中包括多个功能修复和性能改进。

他们决定推迟代码搜索上线,先升级 elasticsearch,希望这可以让新功能的上线更加顺畅。

我们在 1 月 17 日完成了升级,集群中所有节点都成功上线,而且恢复到正常的集群状态。

问题就此开始出现。

从这次升级开始,集群中出现两次故障。

elasticsearch 与其他使用大量单一索引存储数据的索引服务不同,它使用分片模式切分数据,这样可以很容易地将数据分布在整个集群中,而且易于管理。每个分片自己是一个 Lucene 索引,elasticsearch 使用 Lucene 合并索引来聚合所有的分片搜索查询。

在升级后两个小时,第一次故障出现了,恢复的过程中要重启整个集群。我们在索引日志中发现的错误信息指出:有些分片无法分配到特定节点上。进一步检查后,我我们发现:这些数据分片有些区段的缓存文件已经损坏,其他在磁盘上已经丢失,但 elasticsearch 仍然可以恢复有损坏区段缓存的分片,它也可以恢复丢失了一份复制的分片,但是总计 510 个分片中有 7 个分片,两份数据都已经完全丢失。

我们复核了发生故障的环境,当时的结论是:我们发现的问题,来源于集群恢复带来的高负载。对问题的进一步研究后,没有发现其他 elasticsearch 用户遇到过类似问题。在那个周末,集群没有问题,因此我们决定发布新功能。

下一次故障出现在 1 月 24 日、星期四。引起团队注意的,是他们的异常跟踪和监控系统,其中检测到大量的异常爆发。进一步调查指出:大部分异常来自代码查询的超时,以及加入新数据时更新代码搜索索引的后台作业。

这一次,我们开始同时检查集群中全部节点的整体状态和 elasticsearch 的日志。我们发现:看似随机性的多个存储节点出现高负载。大多数节点的 CPU 使用率都是个位数,有几个消耗量几乎 100% 可用的 CPU 核。我们可以消除系统和 IO 引起的负载,在这些服务器上唯一导致高负载的是运行 elasticsearch 的 Java 进程。现在搜索和索引还是会超市,我们也在日志中注意到:一些节点被很快选为 master,此后又很快被移除。为了消除这种快速切换 master 角色带来的潜在问题,我们决定:最好的方法,是让集群完全停机,然后将其启动到“维护模式”,禁止数据分片的分配和重新平衡。

这种方式让集群恢复上线,但是他们发现 elasticsearch 日志中有一些问题。集群重启后,他们发现有些节点无法重新加入到集群中,有些数据分片试图二次分配到同一个节点上。这次,他们求助于 elasticsearch 公司的技术人员,并确认:

这些无法分配的分片(主分片与复制合计 23 个)都有数据丢失。除数据丢失外,集群花费很多时间试图恢复剩余的分片。在这次恢复过程中,我们必须多次重启整个集群,因为我们加入了多次升级和配置变更,必须要验证和再次恢复分片。这是这次故障中最耗时的部分,因为多次从磁盘中加载 17TB 索引数据十分缓慢。

同 elasticsearch 的技术人员一起,他们发现集群中有些地方配置错误,或是需要调优配置,才能得到最佳性能。这次问题也让 elasticsearch 的技术人员也发现了 elasticsearch 的两个 bug。还有一个很重要的原因:

我们当时运行的 Java 6 是 2009 年早期的版本,其中包含多个严重 bug,影响 elasticsearch 和 Lucene,同时造成大量内存分配,导致高负载。

根据他们的建议,我们马上升级了 Java 和 elasticsearch,并按他们的推荐调整了配置。具体做法是:在我们的 Puppetmaster 上,针对这些特定变更,创建了一个新的话题分支,并在环境中的这些节点上运行了 Puppet。使用了新的配置、新版本 elasticsearch 和 Java7 之后,此前两次故障中遇到的负载不稳定和快速 master 选举问题再也没有出现了。

但是,1 月 28 日,又出现一次故障。不过这次与之前没有关系,完全是人为错误。

一名工程师要把包含有 Java 和 elasticsearch 更新的特性分支合并到我们的生产环境中。过程中,工程师将代码搜索节点上的 Puppet 环境回滚到了生产环境中,这是在部署合并代码之前。这导致 elasticsearch 在节点上重启,因为 Puppet 运行在上面。

我们马上就发现了问题根源,并停下集群,防止在一个集群中运行多个版本 Java 和 elasticsearch 导致任何问题。当合并代码部署后,我们在所有代码搜索节点上再次运行 Puppet,启动集群。我们没有选择在集群处于降级状态时建立索引和查询,而是等它完全恢复。当集群完成恢复后,我们将代码搜索功能打开。

总结这几次故障,Will 指出:

在将代码搜索集群中的 elasticsearch 升级到 0.20.2 版本之前,我们没有在我们的基础设施中对其进行足够测试,也没在其他集群中测试。还有一个原因是:对于代码搜索集群,我们没有足够的上线前(staging)环境。

现在运行的 Java 版本已经经过 elasticsearch 团队测试,而且代码集群配置也经过他们审核,未来的审核过程也已经安排确定。

对于周一的故障,我们正在开发自动化过程,保证这样的效果:如果 GitHub 上的分支比 Puppetmaster 上分支更超前,确保这个环境中的 Puppet 不会运行。

最后,Will 给出了 elasticsearch 团队提供的几点优化建议:

  • 设置 ES_HEAP_SIZE 环境变量,保证 JVM 使用的最大和最小内存用量相同。
  • 缩短 recover_after_time 超时配置,这样恢复可以马上进行,而不是还要再等一段时间。
  • 配置 minimum_master_nodes,避免多个节点长期暂停时,有些节点的子集合试图自行组织集群,从而导致整个集群不稳定。

本文链接

相关 [github 布代 搜索] 推荐:

GitHub发布代码搜索功能故障原因

- - 博客园_新闻
1 月 24 日、25 日,GitHub 新上线的代码搜索功能出现故障. 2 月 4 日,运维负责人 Will Farrington 在 一篇博客帖子中,GitHub 团队分析了当时的经过,以及他们如何移除问题以防止再次发生故障. 文中首先介绍了发生故障的背景. GitHub 此前的搜索使用 Solr 实现,新上线的搜索基于 elasticsearch,运行在多个集群上.

掌握 3 个搜索技巧,在 GitHub 快速上找到实用软件资源

- - 少数派
GitHub 作为目前广大程序猿最大的游乐场,在今年 6 月被  微软 以 75 亿美元价值的微软股票收购,GitHub 再次成为业界讨论的焦点. GitHub 以自由开放的定位吸引了相当多的个人开发者和企业,不断发布和更新相当好用的软件和工具. 之前少数派曾经为大家整理和推荐了 GitHub 上免费好用的 Windows、macOS 平台的软件:.

Home · JohnLangford/vowpal_wabbit Wiki · GitHub

- -
There are two ways to have a fast learning algorithm: (a) start with a slow algorithm and speed it up, or (b) build an intrinsically fast learning algorithm.

GitHub - jgraph/drawio: Source to www.draw.io

- -
draw.io supports IE 11, Chrome 32+, Firefox 38+, Safari 9.1.x, 10.1.x and 11.0.x, Opera 20+, Native Android browser 5.1.x+, the default browser in the current and previous major iOS versions (e.g.

git和github简介(上)

- linyehui - 没做完,没准备好
在此贴上本人在Web标准化交流会6月25日北京站的主题分享. 在线PPT:http://jinjiang.github.com/slides/learning-git/. PPT源码:https://github.com/Jinjiang/slides/tree/gh-pages/learning-git.

Github使用指南(转)

- - CSDN博客推荐文章
来自:https://github.com/neuola/neuola-legacy/wiki/github%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97. 如果你只是想了解 github 的使用,请跳到 Github 简介一节. 作为程序员大军之一,想必大家有这样的经历吧.

github 上的好东西

- - 收集分享互联网资源
基于HTML5的专业级图像处理开源引擎.

Windows 下 使用TortoiseGit GitHub

- - CSDN博客研发管理推荐文章
TortoiseGit依赖msysgit,首先下载: http://code.google.com/p/msysgit/downloads/detail?name=msysGit-fullinstall-1.8.1.2-preview20130201.exe&can=2&q=. 再下载TortoiseGit: http://code.google.com/p/tortoisegit/wiki/Download?tm=2.

一个 GitHub Trending 小工具

- - IT瘾-dev
Github Trending基本上是我每天都会浏览的网页,上面会及时发布一些GIthub上比较有潜力的项目,或者说每日Star数增量排行榜. 不过由于Github Trending经常会实时更新,即使你访问得再勤,难免还是会错过一些你感兴趣的项目,为此不少人都想出了自己的解决办法,例如. josephyzhou,他的 github-trending项目得到了众多人的青睐,我仔细阅读了他的源码 (Go),发现实现也较为简单, 就用Python 重写了一下,发现代码少了好多,详见 我的 github-trending.

blong/clickhouse .md at master · xingxing9688/blong · GitHub

- -
https://clickhouse.yandex/tutorial.html快速搭建集群参考. https://clickhouse.yandex/reference_en.html官网文档. https://habrahabr.ru/company/smi2/blog/317682/关于集群配置参考.