Category Archives: Tech Forge

Linux Web服务器性能调优 – Apache的工作模式及配置

一般来说Apache有两种常用工作模式prefork和worker;

要查看当前服务器的工作模式,请用命令 apache2 -l

$ apache2 -l
Compiled in modules:
core.c
mod_log_config.c
mod_logio.c
prefork.c
http_core.c
mod_so.c

可以看到prefork.c 说明现在在用prefork模式。

关于两种模式的区别,根据官方文档:

  • The workerMPM uses multiple child processes with many threads each. Each thread handles one connection at a time. Worker generally is a good choice for high-traffic servers because it has a smaller memory footprint than the prefork MPM.
  • The prefork MPM uses multiple child processes with one thread each. Each process handles one connection at a time. On many systems, prefork is comparable in speed to worker, but it uses more memory. Prefork’s threadless design has advantages over worker in some situations: it can be used with non-thread-safe third-party modules, and it is easier to debug on platforms with poor thread debugging support.

可以看到,这些主要和进程和线程有关,对于内存有限逻辑简单,不太考虑线程安全的网站,worker模式显然更加适合。

复习下进程和线程的主要区别和联系:

进程与线程区别与联系

  1. 划分尺度:线程更小,所以多线程程序并发性更高;
  2. 资源分配:进程是资源分配的基本单位,同一进程内多个线程共享其资源;
  3. 地址空间:进程拥有独立的地址空间,同一进程内多个线程共享其资源;
  4. 处理器调度:线程是处理器调度的基本单位;
  5. 执行:每个线程都有一个程序运行的入口,顺序执行序列和程序的出口,但线程不能单独执行,必须组成进程,一个进程至少有一个主线程。简而言之,一个程序至少有一个进程,一个进程至少有一个线程.

worker模式是介于纯进程的prefork和纯线程的event模式直接的方式,在稳定性和资源上有一个取舍。

prefork配置解释

一个典型的prefork配置和解释如下

<IfModule prefork.c>
StartServers 20 # 启动服务数,对应启动进程数
MinSpareServers 50 # 最小空闲服务(提高响应能力),当前进程数 > 最小空闲服务 + 工作进程
MaxSpareServers 100 # 最大空闲服务(合理释放资源),当前进程数 < 最大空闲服务 + 工作进程
MaxClients 200 # 最大客户端,对应最大进程数
MaxRequestsPerChild 20000 # 每个服务最多处理的请求数量,设定一个有限值可以避免内存泄漏,但会消耗进程创建和销毁的资源
</IfModule>

prefork是用起来最方便的设置,apache的默认设置也是如此。
但该模式最内存资源消耗巨大。举例来说:
一般情况下,一个PHP网站中,每个server需要30M左右内存。
按照前文的配置,最多将占用6G左右的内存。
如果资源不足,就会引发频繁的page fault,大量的SWAP,系统产生大量IO,导致宕机。

所以合理的调整参数,满足网站并发要求和资源限制,在小内存(1G),prefork模式几乎是不可能做到的。

worker配置解释

<IfModule worker.c>

StartServers 15 # 启动的服务,对应进程

ServerLimit 15 # 最大服务限制 应满足 ServerLimit > MaxClients / ThreadsPerChild

MaxClients 256 # 最大客户端数量
ThreadLimit 256 # 最大线程数量
MinSpareThreads 30 # 最小空闲线程(提高响应能力),当前线程数 > 最小空闲服务 + 工作线程
MaxSpareThreads 305 # 最大空闲线程(合理释放资源),当前线程数 < 最大空闲服务 + 工作线程
ThreadsPerChild 255 # 每个子进程对应对线程数
MaxRequestsPerChild 0 # 每个进程处理的最大请求数量,达到即销毁新建进程
</IfModule>

类似的,我们也主要关注其并发响应能力和资源占用情况。

上面的配置可以支持256的并发,内存占用约大于 15 * 30M = 450M 左右,算上线程的开销,大致小于500M。

其他建议

并发和性能与很多东西相关,不是简单计算能够解决的。

这里的配置主要是避免系统瓶颈,同时保护服务器不要超过应用能力。

实际情况中,和磁盘性能,网络,CPU等都有关系,建议在对硬件的充分理解上,结合性能测试工具不断调优。Linux WEB Perfomance Tunning Toolbox

Linux WEB服务器性能调优 – 工具箱

以下是这两天调优的小笔记。第一部分 – 工具

工具

top

top 命令用于互动查看系统情况,相信linux用户都用过。

备注:H 可以显示线程 u 可以指定用户

ps

ps可以列出进程状态,最经典的用法就是 ps aux

不过我更喜欢加上 ps aux -H 可显示进程层次

另外 ps aux -T 可以显示线程

pstree

以树形方式简单直接显示进程,常用 pstree –ph (带线程)

lsof

使用它既可以知道进程打开了哪些文件,也可以了解一个文件被哪个进程打开。

一般需配合 grep 使用,对于前面几个工具,发现状态经常为D IOWait较高的情况,最适合用lsof分析原因。

举例:

lsof /etc/passwd 查看谁打开了passwd文件

lsof -p 9995 查看进程9995打开的文件

lsof -i -n -p 显示网络连接状态也非常好用

ab

压力测试工具

常用 ab -c 20 -n 1000 http://example.org/

用20并发请求1000次 http://example.org/ 并汇总统计

sar

系统状态统计

vmstat

系统状态统计

短命令

TCP网络连接状态

netstat -n | awk ‘/^tcp/ {++state[$NF]} END {for(key in state) print key,”\t”,state[key]}’
会得到类似下面的结果,具体数字会有所不同:
LAST_ACK         1
SYN_RECV         14
ESTABLISHED      79
FIN_WAIT1        28
FIN_WAIT2        3
CLOSING          5
TIME_WAIT        1669

SYN_RECV表示等待响应,如果数值较高,需要提高服务器的吞吐量

ESTABLISHED是成功建立连接的,如果占主导是好事情

其他意义不大,有兴趣可以查看TCP相关资料

Ruby on Rails 安装错误一例

Ruby on Rails 安装 Rails报错:

File not found: lib
ERROR:  While generating documentation for rails-3.0.7
... MESSAGE:   exit
... RDOC args: --ri --op /usr/local/rvm/gems/ruby-1.8.7-p334/doc/rails-3.0.7/ri lib --title rails-3.0.7 Documentation –quiet
翻墙搜索得到这篇文章,转载如下:

The issue is that the new Rails version you are installing uses a more recent version of Rdoc/ri and thus when the installation process gets to Rdoc/ri installation, it fails. I don’t know why the ROR developers didn’t think of checking for this and updating Rdoc/ri for you. Anyway, the correct way to solve this issue is to first uninstall the Rails version you just installed with no Rdoc/ri data:

sudo gem uninstall rails

Install the latest version of the rdoc-data gem. This will install ri data for core and stdlib:

sudo gem install rdoc-data

Then run:

sudo rdoc-data –install

In case you want rdoc-data for all your gems run (not necessary.. takes a while if you have as many gems as i do):

gem rdoc –all –overwrite

Now you can install your Rails version and it will successfully install all the rdoc-data too.

sudo gem install rails

Output:

Successfully installed rails-3.0.7
1 gem installed
Installing ri documentation for rails-3.0.7...
Installing RDoc documentation for rails-3.0.7...

Project is On Risk

Acutely,  failed already!

如果单纯以按时交付作为衡量的指标,那这次版本迭代几乎是失败了。

事实上,目前的两次版本都失败了,平均超时60%左右。

事到如今,我不得不反思,项目做到如此地步的原因。

I1和I2:最主要的原因,恐怕是来自于苹果方面审核的未曾预料。

开发账户验证用了一个月,软件上架审核也将近三周,大量的时间和精力用在各种临时方案的救火之上,因此产品的细节关注降低。也未曾达到预期效果。

深层原因:两个关键外部风险在已经识别的情况下,关注度不够,责任不明确,同时由于流程方面的不熟悉,提前量做得也不够,最终没有留下适当的缓冲时间,非常被动。

软件质量:项目和产品是完全不一样的要求!

至少在项目管控上,对业务部门太弱势了。放弃了一些原则性的东西;

更主要是,上层的压力和某些同事好大喜功的个性严重压缩项目时间;

在具体执行上,又缺乏足够明确的计划,没有一以贯中的掌握;

过于关注技术和功能性,对商务和其他沟通没有纳入计划考虑。

救火:

继续坚持RFP的完整性与可行性;

项目计划中列入商务部分,同时加强内部沟通协调工作。

转移部分细节工作,重点控制关键指标达成情况。

随着项目成熟,尽快建立长效机制,避免商务问题造成过多的成本,延长项目周期,加快版本迭代。