epoll

第十一章：Python高级编程-协程和异步IO Python3高级核心技术97讲 笔记 目录 第十一章：Python高级编程-协程和异步IO 11.1 并发、并行、同步、异步、阻塞、非阻塞 11.2 C10K问题和IO多路复用(select、poll、epoll) 11.2.1 C10K问题 11.2.2 Unix下五种I/O模型 11.3 select+回调+事件循环 11.4 回调之痛 11.5 什么是协程 11.5.1 C10M问题 11.5.2 协程 11.6 生成器进阶-send、close和throw方法 11.7生成器进阶-yield from 11.8 yield from how 11.9 async和await 11.10 生成器实现协程 11.1 并发、并行、同步、异步、阻塞、非阻塞 并发 并发是指一个时间段内，有几个程序在同一个CPU上运行，但是任意时刻只有一个程序在CPU上运行。 并行 并行是指任意时刻点上，有多个程序同时运行在多个CPU上。 同步 同步是指代码调用IO操作是，必须等待IO操作完成才返回的调用方式。 异步 异步是指代码调用IO操作是，不必等IO操作完成就返回的调用方式。 阻塞 阻塞是指调用函数时候当前线程被挂起。 非阻塞 阻塞是指调用函数时候当前线程不会被挂起，而是立即返回。 11.2 C10K问题和IO多路复用(select、poll

Nginx 的进程模型 HTTP 连接建立和请求处理过程 HTTP 连接建立和请求处理过程如下： Nginx 高性能、高并发 Nginx 的事件处理模型 模块化体系结构 常见问题剖析 Nginx 的并发处理能力 Nginx 以其高性能，稳定性，丰富的功能，简单的配置和低资源消耗而闻名。本文从底层原理分析 Nginx 为什么这么快！ Nginx 的进程模型 Nginx 服务器，正常运行过程中： 多进程： 一个 Master 进程、多个 Worker 进程。 Master 进程： 管理 Worker 进程。对外接口：接收外部的操作（信号）；对内转发：根据外部的操作的不同，通过信号管理 Worker；监控： 监控 Worker 进程的运行状态，Worker 进程异常终止后，自动重启 Worker 进程。 Worker 进程： 所有 Worker 进程都是平等的。实际处理：网络请求，由 Worker 进程处理。Worker 进程数量：在 nginx.conf 中配置，一般设置为核心数，充分利用 CPU 资源，同时，避免进程数量过多，避免进程竞争 CPU 资源，增加上下文切换的损耗。 思考： 请求是连接到 Nginx，Master 进程负责处理和转发？ 如何选定哪个 Worker 进程处理请求？请求的处理结果，是否还要经过 Master 进程 HTTP 连接建立和请求处理过程 HTTP

【 Java架构师面试网 】收集整理了几乎整个架构师学习途中会遇到的面试题，希望大家都能早日圆自己的架构师梦~ 公众号： Java架构师面试网 ，关注回复“ 资料 ”即可领取精美整理的面试资料一份哦~ 1.BIO、 NIO 和 AIO 的区别？ BIO ：一个连接一个线程，客户端有连接请求时服务器端就需要启动一个线程进行处理。线程开销大。 伪异步 IO ：将请求连接放入线程池，一对多，但线程还是很宝贵的资源。 NIO ：一个请求一个线程，但客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有 I/O 请求时才启动一个线程进行处理。 AIO ：一个有效请求一个线程，客户端的 I/O 请求都是由 OS 先完成了再通知服务器应用去启动线程进行处理， BIO是面向流的，NIO 是面向缓冲区的；BIO 的各种流是阻塞的。而NIO是非阻塞的;BIO的 Stream 是单向的，而NIO的channel 是双向的。 NIO 的特点：事件驱动模型、单线程处理多任务、非阻塞 I/O， I/O 读写不再阻塞，而是返回 0、基于 block 的传输比基于流的传输更高效、更高级的 IO 函数 zero-copy、 IO 多路复用大大提高了 Java 网络应用的可伸缩性和实用性。基于 Reactor 线程模型。 在 Reactor 模式中，事件分发器等待某个事件或者可应用或个操作的状态发生

一次服务器CPU占用率高的定位分析 推荐 背景 ：通过性能监控发现上线服务器cpu某核占用率已经达到了100%，而且是由我们的某个核心服务导致的。幸亏由于我们的服务进程由多个相同worker（线程）调度承担的，所以除了CPU占用率高之外，并没有对服务造成影响。随着 上次我们找到那个吃IO的罪犯 ，这次我们要追捕的是潜伏在团体中的特务，更加惊险刺激哟！ 系统环境 用 top 命令很容易定位到是谁占用CPU最高。 以我们的这个业务进程（imDevServer）举例，为什么说这货是个潜伏者呢？因为这是个多线程的进程，我们要知道实际上占用cpu的最小单位是线程，所以肯定是众线程中的某一个或几个占用CPU过高导致的。 top -H -p pid 命令查看进程内各个线程占用的CPU百分比 如上图所示我们可以看出id为8863的线程cpu占用率最高。好，我们现在只要能找到他偷走的cpu就好了，虽然这小子嘴巴严，但是我们有一套完善的审问流程，不怕他不招。首先出马的是 strace -T -r -c -p pid 命令 它的作用是查看系统调用和花费的时间，epoll_wait虽然占用的调用时间多，但是他本身是个正常的阻塞调用。 我们接着让 pstack pid 出马 可以看到每个线程的调用堆栈，找到已经找出的占用CPU最高的那个线程，然后看他的调用堆栈，很容易看出在哪一步逻辑上导致了busy

Nginx 的进程模型 Nginx 服务器，正常运行过程中： 多进程：一个 Master 进程、多个 Worker 进程 Master 进程：管理 Worker 进程 对外接口：接收外部的操作（信号） 对内转发：根据外部的操作的不同，通过信号管理 Worker 监控：监控 worker 进程的运行状态，worker 进程异常终止后，自动重启 worker 进程 Worker 进程：所有 Worker 进程都是平等的 实际处理：网络请求，由 Worker 进程处理； Worker 进程数量：在 nginx.conf 中配置，一般设置为核心数，充分利用 CPU 资源，同时，避免进程数量过多，避免进程竞争 CPU 资源，增加上下文切换的损耗。 思考： 请求是连接到 Nginx，Master 进程负责处理和转发？ 如何选定哪个 Worker 进程处理请求？请求的处理结果，是否还要经过 Master 进程？ HTTP 连接建立和请求处理过程： Nginx 启动时，Master 进程，加载配置文件 Master 进程，初始化监听的 socket Master 进程，fork 出多个 Worker 进程 Worker 进程，竞争新的连接，获胜方通过三次握手，建立 Socket 连接，并处理请求 Nginx 高性能、高并发： Nginx 采用：多进程 + 异步非阻塞方式（IO 多路复用 epoll

【翻译】.NET 5中的性能改进 在.NET Core之前的版本中，其实已经在博客中介绍了在该版本中发现的重大性能改进。 从.NET Core 2.0到.NET Core 2.1到.NET Core 3.0的每一篇文章，发现 谈论越来越多的东西。 然而有趣的是，每次都想知道下一次是否有足够的意义的改进以保证再发表一篇文章。 .NET 5已经实现了许多性能改进，尽管直到今年秋天才计划发布最终版本，并且到那时很有可能会有更多的改进，但是还要强调一下，现在已提供的改进。 在这篇文章中，重点介绍约250个PR，这些请求为整个.NET 5的性能提升做出了巨大贡献。 安装 Benchmark.NET现在是衡量.NET代码性能的规范工具，可轻松分析代码段的吞吐量和分配。 因此，本文中大部分示例都是使用使用该工具编写的微基准来衡量的。首先创建了一个目录，然后使用dotnet工具对其进行了扩展： mkdir Benchmarks cd Benchmarks dotnet new console 生成的Benchmarks.csproj的内容扩展为如下所示： <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <AllowUnsafeBlocks>true</AllowUnsafeBlocks>

命令介绍 strace是Linux环境下的一款程序调试工具，用来输出一个应用程序所使用的系统调用。 strace底层使用内核的ptrace特性来实现其功能。 什么是系统调用？ 系统调用是通向操作系统本身的接口，是面向底层硬件的。通过系统调用，可以使得用户态运行的进程与硬件设备(如CPU、磁盘、打印机等)进行交互，是操作系统留给应用程序的一个接口。 常用选项 -t 在每行输出的前面显示时间(精确到秒) -tt 在每行输出的前面显示时间(精确到毫秒) -T 显示每次系统调用所花费的时间 -v 对于某些相关调用，显示详细信息(把完整的环境变量，文件stat结构等打出来) -f 跟踪目标进程，以及目标进程创建的所有子进程 -e 指定要跟踪的系统调用 -o 把strace的输出写到文件中 -s 当系统调用的某个参数是字符串时，最多输出指定长度的内容，默认是32个字节 -p 指定要跟踪的进程pid, 要同时跟踪多个pid, 重复多次-p选项即可。 -c 统计每种系统调用所执行的时间，调用次数，出错次数。 使用 1.追踪打开文件的系统调用 [ root@localhost ~ ] # strace cat /etc/hosts execve ( "/usr/bin/cat" , [ "cat" , "/etc/hosts" ] , 0x7fff79f5beb8 /* 26 vars */ ) =

前言 博客园（cnblogs.com）中有很多关于 .NET async / await 的介绍，但是很遗憾，很少有正确的，甚至说大多都是“从现象编原理”都不过分。 最典型的比如通过前后线程 ID 来推断其工作方式、在 async 方法中用 Thread.Sleep 来解释 Task 机制而导出多线程模型的结论、在 Task.Run 中包含 IO bound 任务来推出这是开了一个多线程在执行任务的结论等等。 看上去似乎可以解释的通，可是很遗憾，无论是从原理还是结论上看都是错误的。 要了解 .NET 中的 async / await 机制，首先需要有操作系统原理的基础，否则的话是很难理解清楚的，如果没有这些基础而试图向他人解释，大多也只是基于现象得到的错误猜想。 初看异步 说到异步大家应该都很熟悉了，2012 年 C# 5 引入了新的异步机制： Task ，并且还有两个新的关键字 await 和 async ，这已经不是什么新鲜事了，而且如今这个异步机制已经被各大语言借鉴，如 JavaScript、TypeScript、Rust、C++ 等等。 下面给出一个简单的对照： 语言 调度单位 关键字/方法 C# Task<> 、 ValueTask<> async 、 await C++ std::future<> co_await Rust std::future::Future<>

前言 博客园中有很多关于 .NET async / await 的介绍，但是很遗憾，很少有正确的，甚至说大多都是“从现象编原理”都不过分。 最典型的比如通过前后线程 ID 来推断其工作方式、在 async 方法中用 Thread.Sleep 来解释 Task 机制而导出多线程模型的结论、在 Task.Run 中包含 IO bound 任务来推出这是开了一个多线程在执行任务的结论等等。 看上去似乎可以解释的通，可是很遗憾，无论是从原理还是结论上看都是错误的。 要了解 .NET 中的 async / await 机制，首先需要有操作系统原理的基础，否则的话是很难理解清楚的，如果没有这些基础而试图向他人解释，大多也只是基于现象得到的错误猜想。 初看异步 说到异步大家应该都很熟悉了，2012 年 C# 5 引入了新的异步机制： Task ，并且还有两个新的关键字 await 和 async ，这已经不是什么新鲜事了，而且如今这个异步机制已经被各大语言借鉴，如 JavaScript、TypeScript、Rust、C++ 等等。 下面给出一个简单的对照： 语言 调度单位 关键字/方法 C# Task<> 、 ValueTask<> async 、 await C++ std::future<> co_await Rust std::future::Future<> .await

【翻译】.NET 5中的性能改进 在.NET Core之前的版本中，其实已经在博客中介绍了在该版本中发现的重大性能改进。 从.NET Core 2.0到.NET Core 2.1到.NET Core 3.0的每一篇文章，发现 谈论越来越多的东西。 然而有趣的是，每次都想知道下一次是否有足够的意义的改进以保证再发表一篇文章。 .NET 5已经实现了许多性能改进，尽管直到今年秋天才计划发布最终版本，并且到那时很有可能会有更多的改进，但是还要强调一下，现在已提供的改进。 在这篇文章中，重点介绍约250个PR，这些请求为整个.NET 5的性能提升做出了巨大贡献。 安装 Benchmark.NET现在是衡量.NET代码性能的规范工具，可轻松分析代码段的吞吐量和分配。 因此，本文中大部分示例都是使用使用该工具编写的微基准来衡量的。首先创建了一个目录，然后使用dotnet工具对其进行了扩展： mkdir Benchmarks cd Benchmarks dotnet new console 生成的Benchmarks.csproj的内容扩展为如下所示： <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <AllowUnsafeBlocks>true</AllowUnsafeBlocks>