文章

寫點文章吧.

从性能问题定位，扯到性能模型，再到 TCP - 都微服务云原生了，还学 TCP 干嘛系列 Part 1
· ☕ 9 分钟

img

引

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

故事的开始

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

玩火的容器内存控制 CGroup - 容器基础拾遗 Part 1
· ☕ 20 分钟
容器内存限制是个矛盾而重要的选择，给多了浪费资源，给少了服务随机崩溃。CGroup 内存控制是容器资源控制的核心。她是个规律严明的看守者，在应用超限时狠心地 OOM Klll。她同时也有宽容的一面，在应用资源不足时，调配和释放 Cache 给应用使用。而其内心的记账算法却耐人寻味。要观察和监控她的状态和行为，更是千条万绪。本文尝试用作分析和梳理。
重新思考云原生时代的开发环境——从 Dev-to-Cloud 到 Dev@Cloud
· ☕ 7 分钟

大背景

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

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

记一次 Istio 调优 Part 2 —— 饥饿的线程与 SO_REUSEPORT
· ☕ 7 分钟


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

引

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