引

本来想直接写理论、和实践分析的，但为了不 “赶客出門” 和不 TL;DR，还是以故事形式展开吧。语言要生动活泼。

故事的开始

话说，一次性能测试中，TPS 死活压不上，应用的响应时间增加。根据 Brendan Gregg 大神的最高指导精神，我开始用 USE(Utilization Saturation and Errors) 方法学去定位这个性能问题。

大背景

滾滾長江東逝水，浪花淘盡英雄。

作为一个一直在底层苦苦挣扎多年程序员，保持一分学习的好奇心，对技术时势的感知，由为重要。因为这最终决定了技术方向。如果你是个在组织中有话语权的人，那么这影响到你组织的技术方向。而在技术驱动型的公司中，这个直接影响到公司的前途。

图片来自：https://getboulder.com/boulder-artist-rocks-the-world/

引

话说，在很长一段时间，程序员依赖了摩尔定律。而在它到头之前，程序员找到了另一个救命稻草：并行/并发/最终一致。而到了今天，不是 Cloud Native / Micro Service 都不好意思打招呼了。多线程，更是 by default 的了。而在计算机性能工程界，也有一个词: Mechanical Sympathy，直译就是 机器同情心。而要“同情”的前提是，得了解。生活中，很多人了解和追求work life balance。但你的线程，是否 balance 你要不要同情一下？ 一条累到要过载线程，看到其它同伴在吃下午茶，又是什么一种同情呢？ 如何才能让多线程达到最大吞吐？

由来

时间回到 2017 年，老东家要上 Kubernetes 了，有幸参与和学习（主要是学习）。当时遇到的一了所有 Java 容器化者都遇到的坑：JDK8 不为容器化设计综合症。最简单的例子是Runtime.getRuntime().availableProcessors()返回了主机的 CPU 数，而非期望的容器自身的cpu share/quota，或说 k8s 的 cpu request/limit。

为何要调优

如果说，引入一个技术需要兴趣和冲劲，那么，让这个技术上线需要的是坚持和执着。 Cloud Native 如是， Istio 如是。
在上线前的性能测试中，Istio 的使用提供了可观察性、运维上的便利，同时也引入了痛苦：增加了服务响应延时。如何让痛苦减到最低，成了当下之急。

前言

话说，一年前项目响应时代的号召，引入了 Istio，从此如刘备得卧龙、凤雏，走上了 Service Mesh 的光辉大道。现到准备益州之战(上线)之时。上线前，还得评估一下性能变化。

程序员的平行宇宙

程序员有两个世界：

1. 一个是编码世界，我们很容易认为，我们考虑了一切，也完成了一切的代码。
2. 然后是运行世界，我们发现，无论我们多么的严谨和考虑一切，世界总是有异常。异常就好像电磁波，一开始，我们只能通过它引发的结果而发现它，而不能直接观察。因为它总出现在那些黑暗的角落，如果我们手中没有电简和电磁波示波器，一切只能依靠猜测和迷信。最后，我们进入了一个用猜测驱动的世界。有时候，我们运气好，猜中了。有时候，我们只能在 release 前多上香。

It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.

2月4日 - IT当年今日

1943年2月4日 Ken Thompson 出生

简介

Unix 来源于一个程序员想玩游戏

肯尼斯·汤普森（Kenneth Thompson）与丹尼斯·里奇（Dennis Ritchie）一起在AT＆T贝尔实验室开发了UNIX。 UNIX操作系统结合了Multics提供的许多分时和文件管理功能，并由此得名。 （Multics是1960年代中期的一个项目，代表了创建多用户，多任务操作系统的第一项努力。）UNIX操作系统迅速赢得了广泛的关注，尤其是在工程师和科学家中。