alchemystar的专栏

笔者在了解清楚 Bug 现场之后，大概花了 20 分钟就定位到了是 TCP 内存瓶颈的问题，然后借助 GPT 非常快速的找到了相关解决方案。不得不说 GPT 能够大幅加速我们搜索的过程，笔者个人感觉可以在很大程度上替代搜索引擎。但喂给 GPT 的 Prompt 还是需要通过 Bug 现场以及一定的经验来构造，它代替不了你的思考，但能大幅加速信息的检索。

从Linux源码看Socket(TCP)的listen及连接队列前言笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码，是一件Exciting的事情。 今天笔者就来从Linux源码的角度看下Server端的Socket在进行listen的时候到底做了哪些事情(基于Linux 3.10内核)，当然由于listen的backlog参数和半连接hash表以及全连接队列都相关，在这一篇博客里也一块讲了。Server端Socket需要Listen众所周知，一个Server端Socket的建立，需要so

从Linux源码看Socket(TCP)的bind前言笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码，是一件Exciting的事情。 今天笔者就来从Linux源码的角度看下Server端的Socket在进行bind的时候到底做了哪些事情(基于Linux 3.10内核)。一个最简单的Server端例子众所周知，一个Server端Socket的建立，需要socket、bind、listen、accept四个步骤。代码如下:void start_server(){ // serv

解Bug之路-Nginx 502 Bad Gateway前言事实证明，读过Linux内核源码确实有很大的好处，尤其在处理问题的时刻。当你看到报错的那一瞬间，就能把现象/原因/以及解决方案一股脑的在脑中闪现。甚至一些边边角角的现象都能很快的反应过来是为何。笔者读过一些Linux TCP协议栈的源码，就在解决下面这个问题的时候有一种非常流畅的感觉。Bug现场首先，这个问题其实并不难解决，但是这个问题引发的现象倒是挺有意思。先描述一下现象吧，笔者要对自研的dubbo协议隧道网关进行压测(这个网关

解Bug之路-串包Bug笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分，所以经常被唤去解决一些网络IO方面的Bug。现在就挑一个案例出来，写出分析思路，以飨读者，希望读者在以后的工作中能够少踩点坑。串包Bug现场前置故障Redis超时由于某个系统大量的hget、hset操作将Redis拖垮，通过监控发现Redis的CPU和IO有大量的尖刺,CPU示意图下图所示:CPU达到了100%,导致很多Redis请求处理不及时，其它业务系统都频繁爆出readTimeOut。此时，紧急将这个做大

#include #include #include /* Dijkstra算法 */#define MAX_VERTICES 10 /* maximum number of vertices */#define FALSE 0#define TRUE 1#define INT_MAX 10000 //定义无穷大为1000#define MAX_POINTS