文章

寫點文章吧.

从性能问题定位，扯到性能模型，再到 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 你要不要同情一下？ 一条累到要过载线程，看到其它同伴在吃下午茶，又是什么一种同情呢？ 如何才能让多线程达到最大吞吐？

Java 容器化的历史坑（史坑） - 资源限制篇
· ☕ 5 分钟

由来

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

记一次 Istio 冲刺调优
· ☕ 5 分钟

为何要调优

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

你的 Istio Mesh 性能及格吗？
· ☕ 4 分钟

image-20210601224250230

前言

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