发博客系统繁忙怎么回事（发博客系统繁忙怎么回事儿）

我通常保持这个博客严格的技术性，将观察、尽量少提意见。但是，接下来的几篇文章将介绍新的系统管理/SRE/系统工程师/sysops/devops-ops（你想叫自己什么都行）角色的常见基础知识。

请跟我来！

Sh。meiYAn888.Com

我只是随机选取了这篇文章的题型，这也适用于任何与系统管理员相关的故障排除。我不是想炫耀能找到最多信息的最聪明的人“金句”。也不是详尽无遗的、逐步指导、在最后一个盒子里被引导“利润”一词的“流程图”。

我将通过一些例子来展示传统的方法。

这个示例场景只是为了本文的目的。有时他们会做出并不适用于所有情况的假设，肯定会有很多读者说“哦，但是我想你会发现……”。

但这可能会让我们忽略重点。

十多年来，我一直从事支持工作，或在支持机构工作，一件事让我一次次震惊，这促使我写了这篇文章。

有很多技术人员遇到问题的本能反应，就是不管三七二十一，尝试可能的解决方案。

“我的网站很慢，所以”，

“这个问题我以前见过，是某些原因造成的 —— 所以我猜是同样的原因，应该能解决这个问题。”

这浪费了很多时间，而且会让你在黑暗中瞎撞，鬼混。

你的 InnoDB 缓冲池可能达到 100％ 利用率，但这可能只是由某人已经运行了一段时间的大量一次性报告引起的。如果没有排除这种情况，你在浪费时间。

开始前

Sh。meiYAn888.Com

在这里，我应该解释一下，尽管这些建议同样适用于许多角色，但是我是从一般支持系统管理员的角度来写的。在成熟的内部组织中，或者具有更大的规模、标准化或管理“企业级”与客户合作时，你通常会测试所有东西、测量、绘制、整理（甚至不说话），并发出警报。那么你的方法也往往会有所不同。这里就忽略这种情况吧。

如果你没有这样的东西，那是可选的。

解决问题

首先，确定问题是什么。“慢”它可以采取多种形式。是时候接收第一个字节了吗？从坏 Javascript 和加载每一页来拉 15 MB 的静态内容，这是一个完全不同的问题。是慢，还是比平时慢？这是两种截然不同的解决方案！

在你着手做某事之前，一定要了解实际报道和遇到的问题。往往很难找到问题的根源，但即使找不到，也要找到问题本身。

否则，这相当于系统管理员拿刀去枪战。

唾手可得——轻而易举地得到某物

第一次登录可疑服务器时，可以找到一些共同的疑点。事实上，你应该这样做！每当我登录服务器时，我将发出一些命令来快速检查一些东西：我们交换页面了吗（free / vmstat），磁盘忙吗（top / iostat / iotop），有丢包吗（netstat / proc/net/dev），你是不是处于人脉太多的状态（netstat），有东西占据了它 CPU（top），谁在这台服务器上（w / who），syslog 和 dmesg 有什么引人注目的新闻吗？

如果你从 RAID 控制器获得 2000 抱怨直写缓存无效的消息，那就没有继续下去的意义了。

不会花半分钟的。如果没有引起你的注意 —— 那就继续。

重现问题

如果某个地方有问题，并且找不到唾手可得——轻而易举地得到某物的信息。

然后采取一切措施，尝试繁殖问题。当您可以重现问题时，可以观察一下。当你能观察到时，你可以解决它。如果问题在第一步中没有被发现或覆盖，询问报告问题的人需要采取哪些确切步骤来重现问题。

Sh。meiYAn888.Com

对于太阳耀斑还是只能磨合 OS/2 由客户端引起的问题，繁殖并不总是可行的。但是你的第一站至少应该试一试！开始的时候，你知道的是“有人认为他们的网站很慢”。对那些人来说，他们可能还在用他们的 GPRS 手机，它也可能正在安装 Windows 更新。不管你在这里挖多深，都是浪费时间。

尝试繁殖！

检查日志

我对需要包括这一点感到抱歉。但有一次我看到有人在跑 tail /var/log/... 几分钟后，我停止了观看。大多数 *NIX 工具特别喜欢伐木。任何明显的错误都会在大多数应用程序日志中凸显出来。仔细讨论。

缩小范围

如果没有明显的问题，但你可以重现所报告的问题，那也很棒。所以，现在你知道网站很慢。现在你已经把范围缩小到：浏览器的渲染/错误、应用代码、DNS 基础设施、路由器、防火墙、网卡（所有的）、以太网电缆、负载平衡器、数据库、缓存层、会话存储、Web 服务器软件、应用服务器、内存、CPU、RAID 卡、诸如此类。

根据设置添加一些其他可能的罪犯。它们也可能是 SAN，别忘了硬件 WAF！以及…… 你知道我的意思。

如果问题是接收第一个字节的时间，你当然会开始。是 Web 在服务器上应用已知的修复程序，就是它响应缓慢，你也觉得差不多了，对吧？但是你错了！

你要回去尝试繁殖这个问题。只是这次，你应该尽可能地消除潜在的问题来源。

你可以很容易地排除大多数可能的罪犯：你能从服务器本地重现这个问题吗？恭喜，你刚刚救了你自己，必须试着去弥补 BGP 路由时间。

不然的话，尝试使用同一网络上的另一台电脑。如有可能，至少你可以把防火墙移到你的嫌疑名单里，（但是注意那个开关！）

所有连接都很慢吗？虽然服务器是 Web 服务器，但这并不意味着您不应该尝试使用其他类型的服务来重现该问题。 netcat 在这些情况下非常有用（但是你的 SSH 连接可能总是有延迟，这可以是一个线索）！ 如果这也很慢，至少你知道你可能有网络问题，你可以忽略整个 Web 软件及其所有组件的问题。有了这些知识（我不收 200 美元）从头再来，从里到外按你的方式去做！

即使你能在本地复制它 —— 还有很多“因素”留下。先排除一些变量。能用普通文件重现吗？ 如果 i_am_a_1kb_file.html 很慢，你知道这不是数据库、缓存层或 OS 除了和以外的任何内容 Web 服务器本身的问题。

可以用一个需要解释或者执行的 hello_world.(py|php|js|rb..) 文件复制问题？如有可能，你已经缩小了范围，你可以专注于几件事。如果 hello_world 你可以马上工作，你还是学到了很多！你知道，没有明显的资源限制、任何完整的队列或卡在任何地方 IPC 调用，这就是应用程序正在做的事情或正在与之通信的内容。

Sh。meiYAn888.Com

所有页面都很慢吗？或者只是从第三方加载的“实时得分数据”这一页很慢？

归结起来就是：你仍然可以重现这个问题所涉及的最小值“因素”是什么？

我们的例子是一个缓慢的网站，但这同样适用于几乎所有的问题。邮件传递？你能在本地送货吗？可以发给自己吗？能发给<公共服务提供商>吗？用小的、纯文本消息。试着直到你遇见 2MB 拥堵时。使用 STARTTLS 而且没用过 STARTTLS 呢？从里到外按你的方式去做！

每个步骤只需要几秒钟，远远快于大多数“可能的”修复方案。

隔离观察

迄今为止，当您移除特定组件后无法重现问题时，你可能偶然发现了这个问题。

但是如果你还没有，或者你还不知道为什么：一旦你找到了重现问题的方法，在你和问题之间“东西”（一个技术术语）最少，然后就该开始隔离观察了。

请记住，许多服务可以在前台运行/或者启用调试。对于某些类型的问题，这样做通常很有帮助。

这也是你的传统武器发挥作用的地方。strace、lsof、netstat、GDB、iotop、valgrind、语言分析器（cProfile、xdebug、ruby-prof ……）什么样的工具。

Sh。meiYAn888.Com

一旦你到了这一步，您很难摆脱分析器或调试器。

strace 通常是一个很好的起点。

您可能会注意到应用程序停留在某个连接端口 3306 特定于套接字文件描述符 read() 调用上。你会知道该怎么做。

转到 MySQL 并从头再来。明显地：“等待锁定”、死锁、max_connections ……进而：是，所有查询？还是直接写个请求？只有一些桌子？或者只是一些存储引擎？等等……

您可能会注意到，拨打外线 API 资源的 connect() 完成需要五秒钟，甚至超时。你会知道该怎么做。

你可能会注意到，在同一对文件中有 1000 个调用 fstat() 和 open() 作为循环依赖的一部分。你会知道该怎么做。

可能不是什么特别的东西，但我保证，你会有所发现的。

如果你只从这部分学到一点点，那还不错；学习使用 strace 吧！真的学习它，阅读整个手册页。连历史部分都不要跳过。man 每个你还不知道它做了什么的系统调用。98％ 的故障排除进程从开始 strace 而终结。

via: http://northernmost.org/blog/troubleshooting-101/index.html

作者： Erik Ljungstrom 译者： wxy 校对： wxy

本文由 LCTT 原始编译， Linux中国 荣誉推出

点击“了解更多信息”可访问的文本内链接