Mark4z's blog

前言搞清楚linux进程调度后，下一步就是网络。从最常见的http开始，考虑到java源码的冗长以及jvm的naive不透明，不如从golang入手。本次解读基于golang 1.20。 Http 1.1Http1.1应该是web协议中最简单的一个。一句话概括，给每个连接分配一个goroutine，goroutine负责读取请求-处理-发送响应，然后关闭连接或者在这个连接上循环做读取请求-处理-发送响应。这整个过程都是同步且阻塞的。如图： 可以看到，Http1.1对于TCP链接的利用率很低，因为每个连接都是阻塞的，这就导致在Http1时代对于浏览器场景，为了加快速度，浏览器会开多个连接，而对于分布式应用，为了保证并发甚至需要维护一个连接池。而这也直接导致了各种基于TCP的RPC框架的出现，比如dubbo，thrift等等。在这个阶段，RPC最核心的还是自定义协议以支持连接级别的多路服用，Stub反而只是锦上添花。 更糟糕的是每个连接都需要一个线程/协程，对于JAVA这种语言来说是不可接受的。当然，对于Golang来说由于goroutine足够cheap，并且结合epoll和 ...

最近在读《深入理解JVM虚拟机》，发现其中的一些概念有些不理解，大抵是对于底层知识不了解。 于是转头去读《OSTEP》这本书，发现是一本很好的入门书，看完有了一些更深的理解，但是，疑问没有变少，反而变多了。 OSTEP中提到了一个叫xv6的小型unix-like os，于是机缘巧合，发现了MIT的6.828课程，在此留存一下xv6的讲义和一些随想。 一些有用的link：MIT6.S081中文视频课程课程文字版xv6中文讲义原版risc-v pri isa注：以下讲义内容来自于上述文档xv6中文讲义原版，侵联删。 第一章：操作系统接口操作系统的工作是将计算机的资源在多个程序间共享，并且给程序提供一系列比硬件本身支持的更有用的服务。操作系统管理并抽象底层硬件，因此，举例来说，一个文字处理程序不需要去关心自己使用的是何种硬盘。操作系统还对硬件进行多路复用，使多个程序可以同时运行的(或者看起来是同时运行)。最后，操作系统为程序提供了一种可控的交互方式，使得多个程序可以共享数据，共同工作。 操作系统通过接口向用户程序提供服务。设计一个好的接口实际上是很困难的。一方面，我们希望接口简单和精准，这样 ...

不知不觉毕业已经四年有余。一直在做Java，做的再好终归是Spring上浅浅的一层苔藓，一刮就没了。 偶尔心血来潮看一眼《深入理解JVM虚拟机》也如过眼云烟，也始终不得要领，书籍繁多，却也没有一本是为门外汉准备的。 国内的书籍有种不鼓励自学的傲慢，喜欢假定读者已经有了一定的基础，可惜我是没有的，如果有的话我也不会再去看那本书了。 转而去读《OSTEP》，似进入桃花源的一小口，打开了[MIT6.S081]的大门。 听课的这段时间简直是工作后最快乐的时光，两位教授带领你把CPU/MM/FS层层剖开，边学边觉得知识从一个个孤岛融汇起来，知识在经脉里流淌。 终归，告别XV6之后还是要来Linux朝圣。 前言本文并不是一篇Linux进程入门教程，建议按照顺序掌握以下知识后参考本文理解Linux源码。 Clang基础 OSTEP 操作系统导论 - 这绝对是一本好书，能让你低成本的思考操作系统的本质 MIT6.S081 - MIT的本科操作系统课程，难度颇高，笔者花了两三个月的时间但很值得。 （可选）Linux内核设计与实现 - 本书是Linux内核的入门书籍，但是并算不上入门，对笔者来说 ...

Journaling the Linux ext2fs FilesystemNotice:It’s a copy from https://github.com/duguosheng/6.S081-All-in-one/blob/main/tranlate_books/Journaling%20the%20Linux%20ext2fs%20Filesystem.mdIt’s translate from https://pdos.csail.mit.edu/6.S081/2022/readings/journal-design.pdf 摘要本文描述了为Linux ext2fs文件系统设计和实现事务元数据日志的工作进展。我们回顾了崩溃后恢复文件系统的问题，并描述了一种旨在通过向文件系统添加事务日志来提高ext2fs崩溃恢复速度和可靠性的设计。 介绍文件系统是任何现代操作系统的核心部分，人们期望它既快速又非常可靠。但是，由于硬件、软件或电源故障，问题仍然存在，机器可能会意外停机。 在一次意料之外的重启后，系统可能需要一些时间才能恢复文件系统的一致性状态。随着磁盘大小的增长，这一时间可能会成 ...

背景本篇文章的灵感来源于不久前的一次压测，接口的TPS在100并发下不足500，且延时超过500MS，这个接口的性能远远低于我们的预期。对应的接口是一个极为简单的接口，只做了两件事情： 从数据库中读取一条数据，做了一些简单的处理 进行一次HTTP调用 那么话不多说，开始从内到外几个排查： DB的CPU、内存、磁盘IO、网络IO等指标一切正常：排除慢sql相关问题 POD，即容器的CPU、内存、网络IO等指标一切正常：排除容器资源不足问题 JVM的Heap Size即堆内存、GC、线程数等指标一切正常：排除内存泄漏、GC问题 利用Arshas或其他监测工具生成火焰图或接口耗时分析图，发现接口耗时主要集中第二步 Stream Reset Exception上文提到发现接口的主要耗时集中在第二步，那么我们就从第二步开始分析： 排查发现，该Http调用使用的是Okhttp3, 且使用的是默认的连接池，最多复用5个连接，看起来有点太少了，但后续调整到100后发现性能并没有提升，所以这个问题基本可以排除。（当然连接池确实过小，但是与此次的性能问题并无关系） 12345678@C ...