synqueue

　　TCP建立连接是要进行三次握手，但是否完成三次握手后，服务器就处理（accept）呢？ 　　backlog其实是一个连接队列，在Linux内核2.2之前，backlog大小包括半连接状态和全连接状态两种队列大小。 　　半连接状态为：服务器处于Listen状态时收到客户端SYN报文时放入半连接队列中，即SYN queue（服务器端口状态为：SYN_RCVD）。 　　全连接状态为：TCP的连接状态从服务器（SYN+ACK）响应客户端后，到客户端的ACK报文到达服务器之前，则一直保留在半连接状态中；当服务器接收到客户端的ACK报文后，该条目将从半连接队列搬到全连接队列尾部，即 accept queue （服务器端口状态为：ESTABLISHED）。 　　在Linux内核2.2之后，分离为两个backlog来分别限制半连接（SYN_RCVD状态）队列大小和全连接（ESTABLISHED状态）队列大小。 　　SYN queue 队列长度由 /proc/sys/net/ipv4/tcp_max_syn_backlog 指定，默认为2048。 　　Accept queue 队列长度由 /proc/sys/net/core/somaxconn 和使用listen函数时传入的参数，二者取最小值。默认为128。在Linux内核2.4.25之前，是写死在代码常量 SOMAXCONN

一、前言 这两天看tomcat，查阅 tomcat 怎么承载高并发时，看到了backlog参数。我们知道，服务器端一般使用mq来减轻高并发下的洪峰冲击，将暂时不能处理的请求放入队列，后续再慢慢处理。其实操作系统已经帮我们做了一些类似的东西了，这个东西就是backlog。服务端一般通过 accept 调用，去获取socket。但是假设我们的程序处理不过来（比如因为程序bug，或者设计问题，没能及时地去调用 accept），那么此时的网络请求难道就直接丢掉吗？ 当然不会！这时候，操作系统会帮我们放入 accept 队列，先暂存起来。等我们的程序缓过来了，直接调用 accept 去 队列取就行了，这就达到了类似mq的效果。 而 backlog，和另一个参数 /proc/sys/net/core/somaxconn 一起，决定了队列的容量，算法为：min(/proc/sys/net/core/somaxconn, backlog) 。 文章比较长，如果只需要结论，看第三章的总结即可，有时间的话，可以仔细看看正文、第四章的验证部分。 如果只想知道怎么设置这个值，直接跳到最后即可。 下面这篇文章，基础原理讲得很不错。但是是外国人写的，我这里简（tong）单（ku）翻译一下，我也会结合自己的理解，做一些补充。原文链接： http://veithen.io/2014/01/01/how-tcp

作者：田杰 在数据库的日常使用中，来自应用的高并发场景并不罕见，其标志性的表现为 高新连接创建速率（CPS，比如 PHP 短连接）、发送大量请求到 DB 数据库层。 如同 海啸 ，大量的新建连接和请求猛烈的冲击考验着 DB 层的处理能力，非常容易出现数据库被冲击 hang 住或响应极其缓慢的情况（想象下无预知无缓冲的短时间内突然工作量翻涨数倍，会不会立时被忙哭了 ^_^）。 而数据库通常作为架构最下端的数据存取汇聚单元，其性能表现和稳定性往往决定了应用的最终表现和使用体验，可谓业务生死之大事，不可不察。 由此，我们一起看一下 “海啸” 场景下可以用来 “保命” 的各种解决方案。 注： • 本文目标是总结高并发场景下的应对处理方法，而应对热点更新（秒杀）场景的“招数”会另文介绍。 • 本文的主旨在于方便数据库的使用者理解业务高并发请求场景下的保障 DB 可用性和稳定性的机制和方法，非机制的全面深度技术细节介绍。 1. 线程池 1.1 模型 我们举一个生活中的例子方便大家理解 线程池（Thread Pool）。 比如有个银行，有 10 个窗口（ 实例规格 CPU 数量 )，官方说可以容纳 10 人 （Client Thread） 。平时呢，人也不多，一直顺畅。稍微忙一点呢，大家挤挤。这个 10 人的地方，挤个 50 人也可以（不是每个人时刻都在窗口办业务）。效率也挺高。 年底发工资

转自：https://www.cnblogs.com/leezhxing/p/5329786.html ss 用来显示处于活动状态的套接字信息。 ss命令可以用来获取 socket统计信息，它可以显示和 netstat类似的内容。但 ss的优势在于它能够显示更多更详细的有关 TCP和连接状态的信息，而且比 netstat更快速更高效。 当服务器的 socket连接数量变得非常大时，无论是使用 netstat命令还是直接 cat /proc/net/tcp ，执行速度都会很慢。可能你不会有切身的感受，但请相信我，当服务器维持的连接达到上万个的时候，使用 netstat等于浪费 生命，而用 ss才是节省时间。 天下武功唯快不破。 ss快的秘诀在于，它利用到了 TCP协议栈中 tcp_diag。 tcp_diag是一个用于分析统计的模块，可以获得 Linux 内核中第一手的信息，这就确保了 ss的快捷高效。当然，如果你的系统中没有 tcp_diag， ss也可以正常运行，只是效率会变得稍慢。 选项 -h：显示帮助信息； -V：显示指令版本信息； -n：不解析服务名称，以数字方式显示； -a：显示所有的套接字； -l：显示处于监听状态的套接字； -o：显示计时器信息； -m：显示套接字的内存使用情况； -p：显示使用套接字的进程信息； -i：显示内部的TCP信息； -4

【今日推荐】：为什么一到面试就懵逼！>>> 在Linux系统下，有七类文件类型： 普通文件(-) 目录(d) 软链接(字符链接L) 套接字文件(S) 字符设备(S) 块设备(B) 管道文件(命名管道P) 普通文件、目录、软链接无需多解释。 管道文件 管道分为 匿名管道和命名管道 。管道都是一端写入、另一端读取，它们是单方向数据传输的，它们的数据都是直接在内存中传输的，管道是进程间通信的一种方式，例如父进程写，子进程读。 在shell中匿名管道就是一个管道符号"|"，例如 ls | grep xxx ，其中ls对应的进程是这个独立进程组中的父进程，grep对应的进程是子进程，父进程写子进程读。 在编程语言中，匿名管道是通过创建两个文件句柄或文件描述符(例如A、B)来实现的，一个文件句柄用于写数据(例如A写入端，数据写入A将自动推入B中)，另一个文件句柄用于读数据(即B)。 对于命名管道，即有名称的管道，命名管道将文件保留在文件系统中，它也称为FIFO，也就是first in first out。虽然命名管道文件保留在文件系统中，但是这个文件只是使用命名管道的一个入口，在使用命名管道传输数据的时候，仍然是在内存中进行的，也就是说并不会因为保留在文件系统上命名管道的效率就低了。 在shell中，可以使用 mknod 命令或 mkfifo 命令创建命名管道