处理高并发、高访问之Apache优化

前言:

项目100人同时访问,导致访问速度变慢,作为一个没有遇到过这种情况下的辕,在各种查阅资料后,先用删除日志更改日志输出的方法处理后(处理方法:修改Apache日志输出相关配置方法),暂时好缓,后来又出现变慢,在查阅各种博客后,发现一个处理并发的方法,小试身手,发现有所好转。总结一下,加深记忆。

多路处理模块MPM(Multi-Processing Module)介绍

作为Apache的核心模块它针对不同的操作系统提供了多个不同的MPM模块,例如:mpm_beosmpm_eventmpm_netwarempmt_os2mpm_preforkmpm_winntmpm_worker。 如果条件允许,我们可以根据实际需求将指定的MPM模块编译进我们自己的Apache中(Apache的源码是开放的,允许用户自行编译)。不过,如果在编译时我们没有选择,Apache将按照如下表格根据不同的操作系统自行选择对应的MPM模块,这也是Apache针对不同平台推荐使用的MPM模块。

不同操作系统上默认的MPM模块
操作系统MPM模块描述
Windowsmpm_winntWindows系统
Unix/Linuxmpm_winntUnix/Linux系统
BeOSmpm_beos由Be公司开发的一种多媒体操作系统,官方版已停止更新。
Netwarempm_netware由NOVELL公司推出的一种网络操作系统
OS/2mpmt_os2一种最初由微软和IBM共同开发的操作系统,现由IBM单独开发(微软放弃OS/2,转而开发Windows)

mpm_event模块可以看作是mpm_worker模块的一个变种,不过其具有实验性质,一般不推荐使用。 
当然,Apache在其官方网站上也提供了根据不同操作系统已经编译好对应MPM模块的成品Apache。你可以点击此处进入Apache官方网站下载。

此外,如果我们想要知道某个Apache内部使用的是何种MPM模块,我们可以以命令行的方式进入Apache安装目录\bin,然后键入命令httpd -l,即可查看到当前Apache内部使用的何种MPM模块。

由于在平常的开发工作中,BeOS、NetWare、OS/2等操作系统并不常见,这里我们主要针对Windows和Unix/Linux操作系统上的MPM模块进行讲解。在Windows和Unix/Linux操作系统上,MPM模块主要有mpm_winntmpm_preforkmpm_worker三种。

mpm_prefork模块

mpm_prefork模块主要应用于Unix/Linux平台的Apache服务器,其主要工作方式是:当Apache服务器启动后,mpm_prefork模块会预先创建多个子进程(默认为5个),当接收到客户端的请求后,mpm_prefork模块再将请求转交给子进程处理,并且每个子进程同时只能用于处理单个请求。如果当前的请求数将超过预先创建的子进程数时,mpm_prefork模块就会创建新的子进程来处理额外的请求。Apache总是试图保持一些备用的或者是空闲的子进程用于迎接即将到来的请求。这样客户端的请求就不需要在接收后等候子进程的产生。

由于在mpm_prefork模块中,每个请求对应一个子进程,因此其占用的系统资源相对其他两种模块而言较多。不过mpm_prefork模块的优点在于它的每个子进程都会独立处理对应的单个请求,这样,如果其中一个请求出现问题就不会影响到其他请求。同时,mpm_prefork模块可以应用于不具备线程安全的第三方模块(比如PHP的非线程安全版本),且在不支持线程调试的平台上易于调试。此外,mpm_prefork模块还具有比mpm_worker模块更高的稳定性。

mpm_worker模块

mpm_worker模块也主要应用于Unix/Linux平台的Apache服务器,它可以看作是mpm_prefork模块的改进版。mpm_worker模块的工作方式与mpm_prefork模块类似。不过,由于处理相同请求的情况下,基于进程(例如mpm_prefork)比基于线程的处理方式占用的系统资源要多。因此,与mpm_prefork模块不同的是,mpm_worker模块会让每个子进程创建固定数量的服务线程和一个监听线程,并让每个服务线程来处理客户端的请求,监听线程用于监听接入请求并将其传递给服务线程处理和应答。Apache总是试图维持一个备用或是空闲的服务线程池。这样,客户端无须等待新线程或新进程的建立即可得到处理。

与mpm_prefork模块相比,mpm_worker模块可以进一步减少系统资源的开销。再加上它也使用了多进程,每个进程又有多个线程,因此它与完全基于线程的处理方式相比,又增加了一定的稳定性。

mpm_winnt模块

mpm_winnt模块是专门针对Windows操作系统而优化设计的MPM模块。它只创建一个单独的子进程,并在这个子进程中轮流产生多个线程来处理请求。

修改MPM模块配置

在对Apache的MPM模块具备一定了解后,我们就可以针对不同的MPM模块来修改Apache的最大并发连接数配置了。

  1. 启用MPM模块配置文件

    在Apace安装目录/conf/extra目录中有一个名为httpd-mpm.conf的配置文件。该文件主要用于进行MPM模块的相关配置。不过,在默认情况下,Apache的MPM模块配置文件并没有启用。因此,我们需要在httpd.conf文件中启用该配置文件,如下所示:

    
    # Server-pool management (MPM specific)
    
    
    # Include conf/extra/httpd-mpm.conf (去掉该行前面的注释符号"#")
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
  2. 修改MPM模块配置文件中的相关配置

    在启动MPM模块配置文件后,我们就可以使用文本编辑器打开该配置文件,我们可以看到,在该配置文件中有许多<IfModule>配置节点,如下图所示: 
    httpd-mpm.conf文件截图

此时,我们就需要根据当前Apache服务器所使用的MPM模块,来修改对应节点下的参数配置。首先,我们来看看mpm_winnt模块下的默认配置:

mpm_winnt模块

#由于mpm_winnt模块只会创建1个子进程,因此这里对单个子进程的参数设置就相当于对整个Apache的参数设置。

<IfModule mpm_winnt_module>
ThreadsPerChild      150 #推荐设置:小型网站=1000 中型网站=1000~2000 大型网站=2000~3500
MaxRequestsPerChild    0 #推荐设置:小=10000 中或大=20000~100000
</IfModule>
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

对应的配置参数作用如下:

ThreadsPerChild:每个子进程的最大并发线程数。 
MaxRequestsPerChild:每个子进程允许处理的请求总数。如果累计处理的请求数超过该值,该子进程将会结束(然后根据需要确定是否创建新的子进程),该值设为0表示不限制请求总数(子进程永不结束)。 
该参数建议设为非零的值,可以带来以下两个好处: 
1. 可以防止程序中可能存在的内存泄漏无限进行下去,从而耗尽内存。 
2. 给进程一个有限寿命,从而有助于当服务器负载减轻的时候减少活动进程的数量。

注意:在以上涉及到统计请求数量的参数中,对于KeepAlive的连接,只有第一个请求会被计数。

接着,我们再来看看mpm_perfork模块和mpm_worker模块下的默认配置:

mpm_perfork模块

<IfModule mpm_prefork_module>
StartServers          5 #推荐设置:小=默认 中=20~50 大=50~100
MinSpareServers       5 #推荐设置:与StartServers保持一致
MaxSpareServers      10 #推荐设置:小=20 中=30~80 大=80~120 
MaxClients          150 #推荐设置:小=500 中=500~1500 大型=1500~3000
MaxRequestsPerChild   0 #推荐设置:小=10000 中或大=10000~500000
</IfModule>
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

此外,还需额外设置ServerLimit参数,该参数最好与MaxClients的值保持一致。


# StartServers:  数量的服务器进程开始

# MinSpareServers:  最小数量的服务器进程,保存备用

# MaxSpareServers:  最大数量的服务器进程,保存备用

# MaxRequestWorkers:  最大数量的服务器进程允许开始

# MaxConnectionsPerChild:  最大连接数的一个服务器进程服务
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

  prefork 控制进程在最初建立 “StartServers”个子进程后,为了满足MinSpareServers设置的需要创建一个进程,等待一秒钟,继续创建两 个,再等待一秒钟, 继续创建四个……如此按指数级增加创建的进程数,最多达到每秒32个,直到满足MinSpareServers设置的值为止。这种模式 可以不必在请求到 来时再产生新的进程,从而减小了系统开销以增加性能。MaxSpareServers设置了最大的空闲进程数,如果空闲进程数大于这个 值,Apache 会自动kill掉一些多余进程。这个值不要设得过大,但如果设的值比MinSpareServers小,Apache会自动把其调整 为 MinSpareServers+1。如果站点负载较大,可考虑同时加大MinSpareServers和MaxSpareServers。

  MaxRequestsPerChild设置的是每个 子进程可处理的请求数。每个子进程在处理了“MaxRequestsPerChild”个请求后将自 动销毁。0意味着无限,即子进程永不销毁。虽然缺省 设为0可以使每个子进程处理更多的请求,但如果设成非零值也有两点重要的好处:

  1. 可防止意外的内存泄 漏。
  2. 在服务器负载下降的时侯会自动减少子进程数。

因此,可根据服务器的负载来调整这个值。

  MaxRequestWorkers指令集同时将服务请求的数量上的限制。任何连接尝试在MaxRequestWorkerslimit将通常被排队,最多若干基于上ListenBacklog指令。

在apache2.3.13以前的版本MaxRequestWorkers被称为MaxClients 。

MaxClients是这些指令中最为重要的一个,设定的是 Apache可以同 时处理的请求,是对Apache性能影响最大的参数。其缺省值150是远远不够的,如果请求总数已达到这个值(可通过 ps -ef|grep http|wc -l来确认),那么后面的请求就要排队,直到某个已处理请求完毕。这就是系统资源还剩下很多而HTTP访问却很 慢的主要原因。虽然理论上这个值越大,可以 处理的请求就越多,但Apache默认的限制不能大于256。

mpm_worker模块

<IfModule mpm_worker_module>
StartServers          2 #推荐设置:小=默认 中=3~5 大=5~10
MaxClients          150 #推荐设置:小=500 中=500~1500 大型=1500~3000
MinSpareThreads      25 #推荐设置:小=默认 中=50~100 大=100~200
MaxSpareThreads      75 #推荐设置:小=默认 中=80~160 大=200~400 
ThreadsPerChild      25 #推荐设置:小=默认 中=50~100 大型=100~200
MaxRequestsPerChild   0 #推荐设置:小=10000 中或大=10000~50000
(此外,如果MaxClients/ThreadsPerChild大于16,还需额外设置ServerLimit参数,ServerLimit必须大于等于 MaxClients/ThreadsPerChild 的值。)
</IfModule>
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

对应的配置参数作用如下:

StartServers 启动Apache时创建的子进程数。

MinSpareServers 处于空闲状态的最小子进程数。 
所谓空闲子进程是指没有正在处理请求的子进程。如果当前空闲子进程数少于MinSpareServers,那么Apache将以最大每秒一个的速度产生新的子进程。只有在非常繁忙机器上才需要调整这个参数。此值不宜过大。

MaxSpareServers 处于空闲状态的最大子进程数。 
只有在非常繁忙机器上才需要调整这个参数。此值不宜过大。如果你将该指令的值设置为比MinSpareServers小,Apache将会自动将其修改成MinSpareServers+1。

MaxClients 允许同时连接的最大请求数量。 
任何超过MaxClients限制的请求都将进入等待队列,直到达到ListenBacklog指令限制的最大值为止。

mpm_prefork

MaxClients表示可以用于处理客户端请求的最大子进程数量,默认值是256。要增大这个值,你必须同时增大ServerLimit。

对于线程型或者混合型的MPM(也就是mpm_beosmpm_worker),MaxClients表示可以用于处理客户端请求的最大线程数量。线程型的mpm_beos的默认值是50。对于混合型的MPM默认值是16(ServerLimit)乘以25(ThreadsPerChild)的结果。因此要将MaxClients增加到超过16个进程才能提供的时候,你必须同时增加ServerLimit的值。

MinSpareThreads 处于空闲状态的最小线程数。 不同的MPM对这个指令的处理是不一样的:

mpm_worker的默认值是75。这个MPM将基于整个服务器监视空闲线程数。如果服务器中总的空闲线程数太少,子进程将产生新的空闲线程。mpm_netware的默认值是10。既然这个MPM只运行单独一个子进程,此MPM当然亦基于整个服务器监视空闲线程数。mpm_beos和mpmt_os2的工作方式与mpm_netware差不多,mpm_beos的默认值是1;mpmt_os2的默认值是5。

MaxSpareThreads 处于空闲状态的最大线程数。 不同的MPM对这个指令的处理是不一样的:


注: mpm_worker的默认值是250。这个MPM将基于整个服务器监视空闲线程数。如果服务器中总的空闲线程数太多,子进程将杀死多余的空闲线程。mpm_netware的默认值是100。既然这个MPM只运行单独一个子进程,此MPM当然亦基于整个服务器监视空闲线程数。mpm_beos和mpmt_os2的工作方式与mpm_netware差不多,mpm_beos的默认值是50;mpmt_os2的默认值是10。

备注:ServerLimit表示Apache允许创建的最大进程数。 值得注意的是,Apache在编译时内部有一个硬限制ServerLimit 20000(对于mpm_prefork模块为ServerLimit 200000)。你不能超越这个限制。 
使用这个指令时要特别当心。如果将ServerLimit设置成一个高出实际需要许多的值,将会有过多的共享内存被分配。如果将ServerLimit和MaxClients设置成超过系统的处理能力,Apache可能无法启动,或者系统将变得不稳定。

注意:在配置相关参数时,请先保证服务器具备足够的硬件性能(例如:CPU、内存等)。 如果发现自启动后,随着服务器的运行时间增加,服务器的内存占用也随之增加,可能是程序中出现内存泄露,请向下调整参数MaxRequestsPerChild的值以降低内存泄露带来的影响,然后尽快找出程序中的问题之所在。


本文转载:

处理高并发、高访问之Apache优化_念旧丶的博客-CSDN博客_apache 并发

Apache优化:修改最大并发连接数

  • 0
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
整理的性能高并发服务器架构文章,内容预览:  初创网站与开源软件 6  谈谈大型负载网站服务器的优化心得! 8  Lighttpd+Squid+Apache搭建效率Web服务器 9  浏览量比较大的网站应该从哪几个方面入手? 17  用负载均衡技术建设负载站点 20  大型网站的架构设计问题 25  开源平台的高并发集群思考 26  大型、负载网站架构和应用初探 时间:30-45分钟 27  说说大型高并发负载网站的系统架构 28  mixi技术架构 51 mixi.jp:使用开源软件搭建的可扩展SNS网站 51 总概关键点: 51 1,Mysql 切分,采用Innodb运行 52 2,动态Cache 服务器 -- 52 美国Facebok.com,中国Yeejee.com,日本mixi.jp均采用开源分布式缓存服务器Memcache 52 3,图片缓存和加 52  memcached+squid+apache deflate解决网站大访问量问题 52  FeedBurner:基于MySQL和JAVA的可扩展Web应用 53  YouTube 的架构扩展 55  了解一下 Technorati 的后台数据库架构 57  Myspace架构历程 58  eBay 的数据量 64  eBay 的应用服务器规模 67  eBay 的数据库分布扩展架构 68  从LiveJournal后台发展看大规模网站性能优化方法 70 一、LiveJournal发展历程 70 二、LiveJournal架构现状概况 70 三、从LiveJournal发展中学习 71 1、一台服务器 71 2、两台服务器 72 3、四台服务器 73 4、五台服务器 73 5、更多服务器 74 6、现在我们在哪里: 75 7、现在我们在哪里 78 8、现在我们在哪里 79 9、缓存 80 10、Web访问负载均衡 80 11、MogileFS 81  Craigslist 的数据库架构 81  Second Life 的数据拾零 82  eBay架构的思想金矿 84  一天十亿次的访问-eBay架构(一) 85  七种缓存使用武器 为网站应用和访问加速发布时间: 92  可缓存的CMS系统设计 93  开发大型负载类网站应用的几个要点 105  Memcached和Lucene笔记 110  使用开源软件,设计性能可扩展网站 110  面向负载的架构Lighttpd+PHP(FastCGI)+Memcached+Squid 113  思考高并发负载网站的系统架构 113  "我在SOHU这几年做的一些门户级别的程序系统(C/C++开发)" 115  中国顶级门户网站架构分析1 116  中国顶级门户网站架构分析 2 118  服务器的大用户量的承载方案 120  YouTube Scalability Talk 121  High Performance Web Sites by Nate Koechley 123 One dozen rules for faster pages 123 Why talk about performance? 123 Case Studies 124 Conclusion 124  Rules for High Performance Web Sites 124  对于应用高并发,DB千万级数量该如何设计系统哪? 125  性能服务器设计 130  优势与应用:再谈CDN镜像加速技术 131  除了程序设计优化,zend+ eacc(memcached)外,有什么办法能提服务器的负载能力呢? 135  如何规划您的大型JAVA多并发服务器程序 139  如何架构一个“Just so so”的网站? 148  最便宜的负载网站架构 152  负载均衡技术全攻略 154  海量数据处理分析 164  一个很有意义的SQL的优化过程(一个电子化支局中的大数据量的统计SQL) 166  如何优化大数据量模糊查询(架构,数据库设置,SQL..) 168  求助:海量数据处理方法 169 # re: 求助:海量数据处理方法 回复 更多评论 169  海量数据库查询方略 169  SQL Server 2005对海量数据处理 170  分表处理设计思想和实现 174  Linux系统负载 MySQL数据库彻底优化(1) 179  大型数据库的设计与编程技巧 本人最近开发一个访问统计系统,日志非常的大,都保存在数据库里面。 我现在按照常规的设计方法对表进行设计,已经出现了查询非常缓慢地情形。 大家对于这种情况如何来设计数据库呢?把一个表分成多个表么?那么查询和插入数据库又有什么技巧呢? 谢谢,村里面的兄弟们! 183  方案探讨,关于工程中数据库的问题. 184  web软件设计时考虑你的性能解决方案 190  大型Java Web系统服务器选型问题探讨 193  高并发流量网站架构 210 1.1 互联网的发展 210 1.2 互联网网站建设的新趋势 210 1.3 新浪播客的简介 211 2.1 镜像网站技术 211 2.2 CDN内容分发网络 213 2.3 应用层分布式设计 214 2.4 网络层架构小结 214 3.1 第四层交换简介 214 3.2 硬件实现 215 3.3 软件实现 215  网站架构的性能和可扩展性 233  资料收集:高并发 性能 扩展性 Web 2.0 站点架构设计及优化策略 243  CommunityServer性能问题浅析 250 鸡肋式的多站点支持 250 内容数据的集中式存储 250 过于依赖缓存 250 CCS的雪上加霜 250 如何解决? 251  Digg PHP's Scalability and Performance 251  YouTube Architecture 253 Information Sources 254 Platform 254 What's Inside? 254 The Stats 254 Recipe for handling rapid growth 255 Web Servers 255 Video Serving 256 Serving Video Key Points 257 Serving Thumbnails 257 Databases 258 Data Center Strategy 259 Lessons Learned 260 1. Jesse • Comments (78) • April 10th 261 Library 266 Friendster Architecture 273 Information Sources 274 Platform 274 What's Inside? 274 Lessons Learned 274  Feedblendr Architecture - Using EC2 to Scale 275 The Platform 276 The Stats 276 The Architecture 276 Lesson Learned 277 Related Articles 278 Comments 279 Re: Feedblendr Architecture - Using EC2 to Scale 279 Re: Feedblendr Architecture - Using EC2 to Scale 279 Re: Feedblendr Architecture - Using EC2 to Scale 280  PlentyOfFish Architecture 281 Information Sources 282 The Platform 282 The Stats 282 What's Inside 283 Lessons Learned 286  Wikimedia architecture 288 Information Sources 288 Platform 288 The Stats 289 The Architecture 289 Lessons Learned 291  Scaling Early Stage Startups 292 Information Sources 293 The Platform 293 The Architecture 293 Lessons Learned 294  Database parallelism choices greatly impact scalability 295  Introduction to Distributed System Design 297 Table of Contents 297 Audience and Pre-Requisites 298 The Basics 298 So How Is It Done? 301 Remote Procedure Calls 305 Some Distributed Design Principles 307 Exercises 308 References 309  Flickr Architecture 309 Information Sources 309 Platform 310 The Stats 310 The Architecture 311 Lessons Learned 316 Comments 318 How to store images? 318 RE: How to store images? 318  Amazon Architecture 319 Information Sources 319 Platform 320 The Stats 320 The Architecture 320 Lessons Learned 324 Comments 329 Jeff.. Bazos? 329 Werner Vogels, the CTO of 329 Re: Amazon Architecture 330 Re: Amazon Architecture 330 Re: Amazon Architecture 330 It's WSDL 330 Re: It's WSDL 331 Re: Amazon Architecture 331  Scaling Twitter: Making Twitter 10000 Percent Faster 331 Information Sources 332 The Platform 332 The Stats 333 The Architecture 333 L

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值