• 張近東代表建議,用AI、區塊鏈技術打造數據安全“護城河” 2018-08-18
  • 清明忆先烈 习近平这样传承“红色基因” 2018-08-18
  • 第二届福建省大学生文化创新创意大赛落幕 2018-08-18
  • 乘客突发脑梗 611路司机忙送医一直等到家属到 2018-08-18
  • 中国新一代百亿亿次超级计算机“天河三号”原型机首次亮相[组图] 2018-08-17
  • “动静”结合丨带你感受不一样的实爆训练场 2018-08-17
  • 侠客岛:拿什么拯救你,不学普通话的香港年轻人 2018-08-17
  • 机构改革是一场政治考验 2018-08-17
  • 简讯:韩国前总统朴槿惠一审被判24年有期徒刑 2018-08-16
  • 人民网评:走向大洋,呼唤现代化的中国海军 2018-08-16
  • 北京成立学生申诉处理委员会-地方新闻-时政频道-中工网 2018-08-16
  • 虽胜不足喜!鲁能一隐忧不治愈,恐高开低走 2018-08-16
  • 小鱼儿戴胡可帽子似贵妇 临睡之前表白妈妈嘴超甜 2018-08-16
  • “北京8分钟”融入人工智能 通过互联网与国人互动 2018-08-16
  • 四部门调整完善新能源汽车推广应用财政补贴政策 2018-08-15
  • Python 中的进程、线程、协程、同步、异步、回调(一)

    栏目: IT技术资讯 发布于: 2017-07-22 02:49:28





    进程和线程究竟是什么东西?传统网络服务模型是如何工作的?协程和线程的关系和区别有哪些?IO过程在什么时间发生?



    一、上下文切换技术

    简述

    在进一步之前,让我们先回顾一下各种上下文切换技术。

    不过首先说明一点术语。当我们说“上下文”的时候,指的是程序在执行中的一个状态。通常我们会用调用栈来表示这个状态——栈记载了每个调用层级执行到哪里,还有执行时的环境情况等所有有关的信息。

    当我们说“上下文切换”的时候,表达的是一种从一个上下文切换到另一个上下文执行的技术。而“调度”指的是决定哪个上下文可以获得接下去的CPU时间的方法。

    进程

    进程是一种古老而典型的上下文系统,每个进程有独立的地址空间,资源句柄,他们互相之间不发生干扰。

    每个进程在内核中会有一个数据结构进行描述,我们称其为进程描述符。这些描述符包含了系统管理进程所需的信息,并且放在一个叫做任务队列的队列里面。

    很显然,当新建进程时,我们需要分配新的进程描述符,并且分配新的地址空间(和父地址空间的映射保持一致,但是两者同时进入COW状态)。这些过程需要一定的开销。

    进程状态

    忽略去linux内核复杂的状态转移表,我们实际上可以把进程状态归结为三个最主要的状态:就绪态,运行态,睡眠态。这就是任何一本系统书上都有的三态转换图。

    就绪和执行可以互相转换,基本这就是调度的过程。而当执行态程序需要等待某些条件(最典型就是IO)时,就会陷入睡眠态。而条件达成后,一般会自动进入就绪。

    阻塞

    当进程需要在某个文件句柄上做IO,这个fd又没有数据给他的时候,就会发生阻塞。具体来说,就是记录XX进程阻塞在了XX fd上,然后将进程标记为睡眠态,并调度出去。当fd上有数据时(例如对端发送的数据到达),就会唤醒阻塞在fd上的进程。进程会随后进入就绪队列,等待合适的时间被调度。

    阻塞后的唤醒也是一个很有意思的话题。当多个上下文阻塞在一个fd上(虽然不多见,但是后面可以看到一个例子),而且fd就绪时,应该唤醒多少个上下文呢?传统上应当唤醒所有上下文,因为如果仅唤醒一个,而这个上下文又不能消费所有数据时,就会使得其他上下文处于无谓的死锁中。

    但是有个著名的例子——accept,也是使用读就绪来表示收到的。如果试图用多个线程来accept会发生什么?当有新连接时,所有上下文都会就绪,但是只有第一个可以实际获得fd,其他的被调度后又立刻阻塞。这就是惊群问题thundering herd problem。

    现代linux内核已经解决了这个问题,方法惊人的简单——accept方法加锁。

    (inet_connection_sock.c:inet_csk_wait_for_connect)

    线程

    线程是一种轻量进程,实际上在linux内核中,两者几乎没有差别,除了一点——线程并不产生新的地址空间和资源描述符表,而是复用父进程的。
    但是无论如何,线程的调度和进程一样,必须陷入内核态。

    二、传统网络服务模型

    进程模型

    为每个客户分配一个进程。优点是业务隔离,在一个进程中出现的错误不至于影响整个系统,甚至其他进程。Oracle传统上就是进程模型。缺点是进程的分配和释放有非常高的成本。因此Oracle需要连接池来保持连接减少新建和释放,同时尽量复用连接而不是随意的新建连接。

    线程模型

    为每客户分配一个线程。优点是更轻量,建立和释放速度更快,而且多个上下文间的通讯速度非???。缺点是一个线程出现问题容易将整个系统搞崩溃。

    一个例子

    py_http_fork_thread.py

    在这个例子中,线程模式和进程模式可以轻易的互换。

    如何工作的:

    1. 父进程监听服务端口

    2. 在有新连接建立的时候,父进程执行fork,产生一个子进程副本

    3. 如果子进程需要的话,可以exec(例如CGI)

    4. 父进程执行(理论上应当先执行子进程,因为exec执行的快可以避免COW)到accept后,发生阻塞

    5. 上下文调度,内核调度器选择下一个上下文,如无意外,应当就是刚刚派生的子进程

    6. 子进程进程进入读取处理状态,阻塞在read调用上,所有上下文均进入睡眠态

    7. 随着SYN或者数据报文到来,CPU会唤醒对应fd上阻塞的上下文(wait_queue),切换到就绪态,并加入调度队列

    8. 上下文继续执行到下一个阻塞调用,或者因为时间片耗尽被挂起

    评价


    • 同步模型,编写自然,每个上下文可以当作其他上下文不存在一样的操作,每次读取数据可以当作必然能读取到。

    • 进程模型自然的隔离了连接。即使程序复杂且易崩溃,也只影响一个连接而不是在整个系统。

    • 生成和释放开销很大(效率测试的进程fork和线程模式开销测试),需要考虑复用。

    • 进程模式的多客户通讯比较麻烦,尤其在共享大量数据的时候。

    性能

    thread模式,虚拟机:

    1: 909.27 2: 3778.38 3: 4815.37 4: 5000.04 10: 4998.16 50: 4881.93 100: 4603.24 200: 3445.12 500: 1778.26 (出现错误)

    fork模式,虚拟机:

    1: 384.14 2: 435.67 3: 435.17 4: 437.54 10: 383.11 50: 364.03 100: 320.51 (出现错误)

    thread模式,物理机:

    1: 6942.78 2: 6891.23 3: 6584.38 4: 6517.23 10: 6178.50 50: 4926.91 100: 2377.77

    注意在python中,虽然有GIL,但是一个线程陷入到网络IO的时候,GIL是解锁的。因此从调用开始到调用结束,减去CPU切换到其他上下文的时间,是可以多线程的。现象是,在此种状况下可以观测到短暂的python CPU用量超过100%。

    如果执行多个上下文,可以充分利用这段时间。所观测到的结果就是,只能单核的python,在小范围内,其随着并发数上升,性能居然会跟着上升。如果将这个过程转移到一台物理机上执行,那么基本不能得出这样的结论。这主要是因为虚拟机上内核陷入的开销更高。

    三、C10K 问题

    描述

    当同时连接数在10K左右时,传统模型就不再适用。实际上在效率测试报告的线程切换开销一节可以看到,超过1K后性能就差的一塌糊涂了。

    进程模型的问题:

    在C10K的时候,启动和关闭这么多进程是不可接受的开销。事实上单纯的进程fork模型在C1K时就应当抛弃了。

    Apache的prefork模型,是使用预先分配(pre)的进程池。这些进程是被复用的。但即便是复用,本文所描述的很多问题仍不可避免。

    线程模式的问题

    从任何测试都可以表明,线程模式比进程模式更耐久一些,性能更好。但是在面对C10K还是力不从心的。问题是,线程模式的问题出在哪里呢?

    内存?

    有些人可能认为线程模型的失败首先在于内存。如果你这么认为,一定是因为你查阅了非常老的资料,并且没仔细思考过。

    你可能看到资料说,一个线程栈会消耗8M内存(linux默认值,ulimit可以看到),512个线程栈就会消耗4G内存,而10K个线程就是80G。所以首先要考虑调整栈深度,并考虑爆栈问题。

    听起来很有道理,问题是——linux的栈是通过缺页来分配内存的(How does stack allocation work in Linux?),不是所有栈地址空间都分配了内存。因此,8M是最大消耗,实际的内存消耗只会略大于实际需要的内存(内部损耗,每个在4k以内)。但是内存一旦被分配,就很难回收(除非线程结束),这是线程模式的缺陷。

    这个问题提出的前提是,32位下地址空间有限。虽然10K个线程不一定会耗尽内存,但是512个线程一定会耗尽地址空间。然而这个问题对于目前已经成为主流的64位系统来说根本不存在。

    内核陷入开销?

    所谓内核陷入开销,就是指CPU从非特权转向特权,并且做输入检查的一些开销。这些开销在不同的系统上差异很大。

    线程模型主要通过陷入切换上下文,因此陷入开销大听起来有点道理。实际上,这也是不成立的。线程在什么时候发生陷入切换?正常情况下,应当是IO阻塞的时候。同样的IO量,难道其他模型就不需要陷入了么?只是非阻塞模型有很大可能直接返回,并不发生上下文切换而已。

    效率测试报告的基础调用开销一节,证实了当代操作系统上内核陷入开销是非常惊人的小的(10个时钟周期这个量级)。

    线程模型的问题在于切换成本高

    熟悉linux内核的应该知道,近代linux调度器经过几个阶段的发展。

    1. linux2.4的调度器

    2. O(1)调度器

    3. CFS

    实际上直到O(1),调度器的调度复杂度才和队列长度无关。在此之前,过多的线程会使得开销随着线程数增长(不保证线性)。

    O(1)调度器看起来似乎是完全不随着线程的影响。但是这个调度器有显著的缺点——难于理解和维护,并且在一些情况下会导致交互式程序响应缓慢。
    CFS使用红黑树管理就绪队列。每次调度,上下文状态转换,都会查询或者变更红黑树。红黑树的开销大约是O(logm),其中m大约为活跃上下文数(准确的说是同优先级上下文数),大约和活跃的客户数相当。

    因此,每当线程试图读写网络,并遇到阻塞时,都会发生O(logm)级别的开销。而且每次收到报文,唤醒阻塞在fd上的上下文时,同样要付出O(logm)级别的开销。

    分析

    O(logm)的开销看似并不大,但是却是一个无法接受的开销。因为IO阻塞是一个经常发生的事情。每次IO阻塞,都会发生开销。而且决定活跃线程数的是用户,这不是我们可控制的。更糟糕的是,当性能下降,响应速度下降时。同样的用户数下,活跃上下文会上升(因为响应变慢了)。这会进一步拉低性能。

    问题的关键在于,http服务并不需要对每个用户完全公平,偶尔某个用户的响应时间大大的延长了是可以接受的。在这种情况下,使用红黑树去组织待处理fd列表(其实是上下文列表),并且反复计算和调度,是无谓的开销。


    开班喜讯

    ? ?运维自动化第5期报名进行中

    ? ?时间:7月23日

    ? ?方式:网络班 ?面授班

    ? ?联系:QQ(1):979950755? ? 小夏

    ? ? ? ? ? ? ? ?QQ(2):279312229 ? ?ada

    ? ?课程大纲:http://www.rocksun.cn/course/devops/


    点击阅读原文,查看更多 运维自动化知识。

    本站文章除注明转载外,均为本站原创或编译?;队魏涡问降淖?,但请务必注明出处。
    转载请注明:文章转载自 七星彩票平台
    本文标题:Python 中的进程、线程、协程、同步、异步、回调(一)
    IT技术书籍推荐:
    疯狂Java讲义(第3版)
    疯狂Java讲义(第3版)
    李刚 (作者)
    《疯狂Java讲义(第3版)》内容简介:《疯狂Java讲义(第3版)》是《疯狂Java讲义》的第3版,第3版保持了前两版系统、全面、讲解浅显、细致的特性,全面新增介绍了Java 8的新特性,《疯狂Java讲义(第3版)》大部分示例程序都采用Lambda表达式、流式API进行了改写,因此务必使用Java 8的JDK来编译、运行。 《疯狂Java讲义(第3版)》深入介绍了Java编程的相关方面,全书内容覆盖了Java的基本语法结构、Java的面向对象特征、Java集合框架体系、Java泛型、异常处理、Java GUI编程、JDBC数据库编程、Java注释、Java的IO流体系、Java多线程编程、Java网络通信编程和Java反射机制。覆盖了java.lang、java.util、java.text、java.io和java.nio、java.sql、java.awt、javax.swing包下绝大部分类和接口?!斗杩馢ava讲义(第3版)》全面介绍了Java 8的新的接口语法、Lambda表达式、方法引用、构造器引用、函数式编程、流式编程、新的日期、时间API、并行支持、改进的类型推断、重复注解、JDBC 4.2新特性等新特性。