apache prefork 和worker 模式对比

简介:

 apache 常用的两种工作模式:prefork 和worker 的对比

一 prefork 模式
      prefork 为多路出来模块MPM 实现了一个非线程型的,预派生的web服务器。prefork 适用于没有线程安全库,需要避免线程兼容性问题的系统。他是要求将每个请求相互独立的情况下最好的MPM,这样一个请求出现问题,不至于影响其他的请求。
      prefork模式使用多个子进程,每个子进程只会有一个线程。每个线程在某个确定的时间只能维持一个连接。在大多数平台上,Prefork MPM在效率上要比Worker MPM 要高,但是内存使用大的多。prefork的无线程序设计在某些情况下将比worker更有优势:它可以使用那些没有处理好线程安全的第三方模块,并且对于那些线程调试困难的平台而言,它也更容易调优 一些
   prefork 配置详解
   <IfModule mpm_prefork_module>
   ServerLimit   20000
   StartServers   5
   MinSpareServers   5
   MaxSpareServers   10
   MaxClients   1000
   MaxRequestsPerChild 0
   ServerLimit     2000 
   </ifModule>
 
   ServerLimit 2000
   默认的MaxClient最大是256个线程,假如想胚子更大的值,就需要加上ServerLimit这个参数。 200000是ServerLimit这个参数的最大值。假如需要更大,则必须编译apache,此前都是无需重新编译apache。生肖前提是,必须放在其他指令的前面
   StartServer 5
   指定服务器启动是建立的子进程的数量,prefork 默认为5。为了满足MinSpareServers设置的需要创建一个进程, 等待一秒钟,继续创建两个,再等待一秒钟,继续创建四个……如此按指数级增加创建的进程数,最多达到每秒32个,直到满足 MinSpareServers设置的值为止。这就是预派生 (prefork)的由来。这种模式可以不必在请求到来时再产生新的进程,从而减小了系统开销以增加性能。
   MinSpareServers 5 
     指定空闲子进程的最小数量,默认为5。假如当前空闲子进程数少于MinSpareServers,那么apache 将以每秒一个的速度产生新的子进程。此参数不要设置的太大
   MaxSpareServers
      设置空闲进程的最大数量,默认为10。如果当前有超过MaxSpareServers数量的空闲子进程,那么父进程将杀死多余的子进程。此参数不要设置过大。如果该参数设置比MinSpareServers小,apache将会自动将其修改成"MinSpareServers+1”。如果站点负载较大,可考虑同时加大MinSpareServers和MaxSpareServers。
   MaxClients
       限定同一时间客户端最大接入的数量(单个进程并发线程数)。默认为256,任何超过MaxClients限制的请求都会进入等候队列,一旦一个链接被释放,队列中的请求将得到服务。如果要增大这个值,必须同时增加ServerLimit
   MaxRequestsPerChild
       每个子进程在其生存期内允许伺服的最大请求数量。默认为10000到达MaxRequestsPerChild的限制后,子进程将会结束。
       如果MaxRequestsPerChild 为0,子进程将永远不会结束。将MaxRequestsPerChild 设置成非零值有两个好处:
       1 可以防止内存泄漏
       2 给进程一个有限寿命,从而有助于当服务器负载减轻的时候减少活动进程的数量
   prefork 工作方式:
        一个单独的控制进程(父进程)负责生产子进程,这些子进程用于监听请求并作出应答。apache 总是试图保持一个备用的(spare)
     或是空闲的子进程用于迎接即将到来的请求。这样客户端就无需在得到服务前等候子进程的产生。在unix系统中,父进程通常是以
     root 身份运行以便绑定80端口,而apache生产的子进程通常一个低特权的用户运行。User和Group指令用于配置
    配置子进程的低特权用户。运行子进程的用户必须要对他所服务的内容用读取的权限,但是对服务内容之外的其他资源必须拥有尽可能少的权限
 
  二  worker 模式
     worker MPM 使用多个子进程,每个子进程有多个线程。每个线程在摸个确定的时间只能维持一个连接。通常来说,在一个高流量的HTTP服务器上,Worker MPM 是个比较好的选择,因为Worker MPM 的内存使用比Prefork MPM 要低的多。但是worker MPM 也有缺陷。如果一个线程崩溃,整个进程就会连同其任何线程一起“死掉”,由于线程共享内存空间,所以一个程序在运行时必须被系统识别为 “每个线程都是安全的”。
      例如
       ServerLimit   50
       ThreadLimit   200
       StartServers   5
       MaxClients   5000
       MinSpareThreads   25
       MaxSpareThreads   500
       ThreadsPerChild   100
       MaxRequestsPerChild 0
 
       ServerLimit 50
       服务器允许配置的进程数上限。这个指令和ThreadLimit 结合使用配置了MaxClients 最大允许配置的数值。任何在重启期间对这个指令的改变都将被忽略,但对MaxClients 的修改却会生效
       ThreadLimit 200
       每个进程可配置的线程上限。这个指令配置了每个子进程可配置的线程ThreadsPerChild上限。任何在重启期间对这个指令的修改都将被忽略,但对ThreadsPerChild的修改会生效。默认值是64 
       StartServer 5
       服务器启动时建立的子进程数,默认值是3
       MinSpareThreads 75
       最小空闲线程数,默认值是75 .这个MPM 将基于整个服务器监控空闲线程数。假如服务器中总的空闲进程数太少,子进程将产生新的空闲线程
       MaxSpareThreads  500
       配置最大空闲线程数。默认值为 250.这个MPM将基于整个服务器监控空闲线程数。假如服务器中总的空闲线程数太多,子进程将杀死多余的空闲线程。MaxSpareThreads 的取值范围是有限制的。apache 将按照乳腺限制自动修正您的配置值:worker 需要其大于等于MinSpareThreads 加上ThreadsPerChild的 和
        MaxClients 5000
        允许同时伺服的最大接入请求数量(最大线程数量)。任何超过MaxClients限制的请求都将进入等候队列。默认值是“400”,16(ServerLimit)乘以25(ThreadsPerChild)的结果。
        因此要增加MaxClients 的时候,您必须同时增加ServerLimit的值。
       ThreadsPerChild 100
       每个子进程建立的常住的执行线程,默认值为25,子进程在启动是建立这些线程后就不再建立新的线程了。
       MaxRequestsPerChild 0
       配置每个子进程在其生存期内允许伺服的最大请求数量。到达MaxRequestsPerChild的限制后,子进程将会结束。假如MaxRequestsPerChild 为"0"
       子进程将永远不会结束。
        将MaxRequestPerChild配置成非零值后两个好处:
         1 能够防止内存泄漏。
         2 给进程一个有限的寿命,从而有助于当服务器负载减轻的时候减少活动进程的数量。
       注意 对于keepalive链接,只有第一个请求会被计数。事实上,他改变了每个进程限制最大链接数量的行为
       工作方式:
         每个进程能够拥有的线程数量是固定的。服务器会根据负载情况增加或减少进程数量。一个单独的控制进程(父进程)负责子进程的建立。每个子进程能够建立ThreadsPerChild数量的服务器线程和一个监听线程。该监听线程监听接入请求并将其传递给服务线程处理和应答。Apache总是试图维持一个备用(Spare)或是空闲的服务线程池。这样,客户端无须等待新线程或新进程的建立即可得到处理。在unix中,为了能够绑定80端口父进程一般都是以root身份启动,随后,apache以较低权限的用户建立子进程和线程。User和Group指令用于配置Apache子进程的权限。虽然子进程必须对其提供的内容拥有读权限,但还应该尽可能给予他较少的特权。另外,除非使用了suexec,否则。这些指令配置的权限将被CGI 脚本所继承
     公式:
         ThreadLimit >= ThreadsPerChild
         MaxClients   =  MinSpareThreads + ThreadsPerChild
     硬限制
          ServerLimit和ThreadLimit 这两个指令决定了活动子进程数量和每个子进程中线程数量的硬限制。如果 想改变这个硬限制必须完全定制服务器
          然后在重启服务器(直接重启是不行的)
          apache 在编译ServerLimit时内部有一个硬性的限制,你不能超越这个限制
           prefork MPM 最大为ServerLimit 200000
           其他MPM(包括work MPM)最大为”ServerLimit 20000
           Apache在编译ThreadLimit时内部有一个硬性的限制,您不能超越这个限制
            mpm_winnt是”ThreadLimit 15000″
            其他MPM(包括work prefork)为”ThreadLimit 20000
         如果想修改ServerLimit 和ThreadLimit,请在编译前修改如下文件
            #cd  httpd-version/server/mpm/worker/
            #vim  worker.c
            把
             define DEFAULT_SERVER_LIMIT 16
             define MAX_SERVER_LIMIT 20000
             define DEFAULT_THREAD_LIMIT 64
             define MAX_THREAD_LIMIT 20000
 
             改为
            define DEFAULT_SERVER_LIMIT 256
            define MAX_SERVER_LIMIT 40000
            define DEFAULT_THREAD_LIMIT 256
            define MAX_THREAD_LIMIT 40000 
      注意:
   使用ServerLimit和ThreadLimit时要特别当心。假如将ServerLimit和ThreadLimit配置成一个高出实际需要许多的值,将会有过多的共享内存被分配。当配置成超过系统的处理能力,Apache可能无法启动,或系统将变得不稳定。









本文转自 freehat08 51CTO博客,原文链接:http://blog.51cto.com/freehat/1186019,如需转载请自行联系原作者
目录
相关文章
|
2月前
|
存储 分布式计算 druid
大数据-152 Apache Druid 集群模式 配置启动【下篇】 超详细!(一)
大数据-152 Apache Druid 集群模式 配置启动【下篇】 超详细!(一)
45 1
大数据-152 Apache Druid 集群模式 配置启动【下篇】 超详细!(一)
|
2月前
|
分布式计算 大数据 分布式数据库
大数据-158 Apache Kylin 安装配置详解 集群模式启动(一)
大数据-158 Apache Kylin 安装配置详解 集群模式启动(一)
57 5
|
2月前
|
资源调度 大数据 分布式数据库
大数据-158 Apache Kylin 安装配置详解 集群模式启动(二)
大数据-158 Apache Kylin 安装配置详解 集群模式启动(二)
53 2
|
2月前
|
消息中间件 分布式计算 druid
大数据-152 Apache Druid 集群模式 配置启动【下篇】 超详细!(二)
大数据-152 Apache Druid 集群模式 配置启动【下篇】 超详细!(二)
47 2
|
2月前
|
存储 消息中间件 druid
大数据-151 Apache Druid 集群模式 配置启动【上篇】 超详细!
大数据-151 Apache Druid 集群模式 配置启动【上篇】 超详细!
98 1
|
3月前
|
Apache
多应用模式下,忽略项目的入口文件,重写Apache规则
本文介绍了在多应用模式下,如何通过编辑Apache的.htaccess文件来重写URL规则,从而实现忽略项目入口文件index.php进行访问的方法。
|
4月前
|
Linux Apache
在Linux中,apache有几种工作模式,分别介绍下其特点,并说明什么情况下采用不同的工作模式?
在Linux中,apache有几种工作模式,分别介绍下其特点,并说明什么情况下采用不同的工作模式?
|
17天前
|
存储 人工智能 大数据
The Past, Present and Future of Apache Flink
本文整理自阿里云开源大数据负责人王峰(莫问)在 Flink Forward Asia 2024 上海站主论坛开场的分享,今年正值 Flink 开源项目诞生的第 10 周年,借此时机,王峰回顾了 Flink 在过去 10 年的发展历程以及 Flink社区当前最新的技术成果,最后展望下一个十年 Flink 路向何方。
306 33
The Past, Present and Future of Apache Flink
|
2月前
|
SQL Java API
Apache Flink 2.0-preview released
Apache Flink 社区正积极筹备 Flink 2.0 的发布,这是自 Flink 1.0 发布以来的首个重大更新。Flink 2.0 将引入多项激动人心的功能和改进,包括存算分离状态管理、物化表、批作业自适应执行等,同时也包含了一些不兼容的变更。目前提供的预览版旨在让用户提前尝试新功能并收集反馈,但不建议在生产环境中使用。
864 13
Apache Flink 2.0-preview released
|
2月前
|
存储 缓存 算法
分布式锁服务深度解析:以Apache Flink的Checkpointing机制为例
【10月更文挑战第7天】在分布式系统中,多个进程或节点可能需要同时访问和操作共享资源。为了确保数据的一致性和系统的稳定性,我们需要一种机制来协调这些进程或节点的访问,避免并发冲突和竞态条件。分布式锁服务正是为此而生的一种解决方案。它通过在网络环境中实现锁机制,确保同一时间只有一个进程或节点能够访问和操作共享资源。
102 3

推荐镜像

更多