linux运维趋势 第13期 服务器优化

28

Upload: 51cto

Post on 05-Jul-2015

1.716 views

Category:

Technology


0 download

DESCRIPTION

本期主题:服务器优化 本期目录: 003 Limoncelli的系统管理员团队管理32问 005 Quora使用到的技术 007 红帽收购Gluster Nginx走向商业化 009 Linux 性能及调优指南:了解Linux性能指标 011 小规模低性能低流量网站优化实践 013 详解服务器内存带宽计算和使用情况测量 015 http长连接200万尝试及调优 017 MySQL数据库的优化:单机优化 019 MySQL写入优化 021 应用SELinux中的目标策略限制进程运行 023 MySQL从库集群方案之HAProxy篇 025 Linux上获取本机ip的各种perl写法 027 拼装的艺术:vim之IDE进化实录 《Linux 运维趋势》是由 51CTO 系统频道策划、针对 Linux/Unix 系统运维人员的一份电子杂志,内容从基础的技巧心得、实际操作案例到中、高端的运维技术趋势与理念等均有覆盖。 微博讨论群:http://q.weibo.com/121303 邮件订阅入口:http://os.51cto.com/art/201011/233915.htm 投稿信箱:[email protected] 发布周期:每个月的第二个星期五 往期《Linux运维趋势》下载汇总页:http://down.51cto.com/zt/71

TRANSCRIPT

Page 1: Linux运维趋势 第13期 服务器优化
Page 2: Linux运维趋势 第13期 服务器优化

002

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

目录Index

002

目录

人物·People

003 Limoncelli的系统管理员团队管理32问

交流·Interact

005 Quora使用到的技术

八卦·News

007 红帽收购Gluster Nginx走向商业化

专题·Special

009 Linux 性能及调优指南:了解Linux性能指标

011 小规模低性能低流量网站优化实践

013 详解服务器内存带宽计算和使用情况测量

015 http长连接200万尝试及调优

017 MySQL数据库的优化:单机优化

019 MySQL写入优化

技巧·工具·脚本·DBA

021 应用SELinux中的目标策略限制进程运行

023 MySQL从库集群方案之HAProxy篇

025 Linux上获取本机ip的各种perl写法

027 拼装的艺术:vim之IDE进化实录

出版方 :51CTO 系统频道(北京无忧创想信息技术有限公司)

杂志主编 :杨赛

联系方法 :[email protected] 010-68476606(分机 8035)

出版日期 :2011 年 10 月 14 日

每月第 2 个星期五出版

订阅 :http://os.51cto.com/art/201011/233915.htm

Page 3: Linux运维趋势 第13期 服务器优化

003

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

人物People

003

自测宝典:Limoncelli的系统管理员团队管理32问

的风险 :忽略重要请求方面的问题、来自用户的的每个请求都可能打断正

常处理流程的问题、对技术团队的工作内容不了解而无法实施管理的问题、

总体业务趋势无从把握的问题、团队内部成员间不能高效承接任务的问题。

从根本上解决问题乍看起来似乎涉及大量工作内容,但置之不理会必然

会带来更多的麻烦。

Joel Spolsky 所创立的“Joel 测试 :改进编码的十二步法”堪称杰作,其

以十二个问题为引,用看似漫不经心、草率粗略的测试精确评估出了软件团

队的实际工作能力。而我则希望在本文中向大家展示自己为系统管理员所

打造的另一套测试。这里共有 32 个只需以是或否作答问题。与十二步法

类似,我的测试也相当漫不经心、草率粗略。

这套测试应该会简化对团队进行基本

评价的实施流程。这对团队管理者、企业

领导及团队成员都非常实用。这同样是

一套对于求职者极有帮助的方法 :千万别

误上了贼船,通过这一系列问题事先考量

好新雇主的业务水平。最终得分并不重要,真正重要的是应对的态度 :不愿

或表示无力改变现状的心态才最最危险、最最需要警惕。

以星号(*)标记的项目是最根本性的内容,它们是我书中不可或缺的基

础思想所在。其它项目当然也不能说不重要,只是对于某些规模较小的企

业来说也许不太适用。

以下就是 Limoncelli 的测试 :有助于提高系统管理员团队工作效率的 32

个问题。你准备好答题了吗?

文/Tom Limoncelli译/核子可乐

“部署一套请求跟踪系统是比较常见、没啥技

术含量的基本做法。”

Tom Limoncelli 是就职 Google 的一位系统管理员,运维界知名的系统管

理员,作者与演讲者。他从 1987年开始从事系统运维与网络工程师的工作,

在全世界多个有关系统运维与网络安全的大会上进行演讲。2000 年之前,

Tom 一直在 AT&T 贝尔实验室(后来的 Lucent 贝尔实验室)工作,从系统 /

网络管理员逐步升职为高级网络架构师 ;之后的几年间,他参与过创业团

队,为佛蒙特州州长的竞选者担任过 IT 技术支持,也做过咨询顾问。在今

年的系统管理员日前后,他专门撰写了一个清单,列举了提高系统管理员团

队工作效率的 32 个问题。32 个问题共分 7 大类,从不同的方面强调了系

统管理员需要加强的工作流程。

这 32 个问题的解决过程并非一蹴而就,对这些问题仔细思考,相信会对

您未来的工作规划带来启发。51CTO

现在将全文翻译完毕,以下为全文。

人们常常向我问及,应该如何提高

自己系统管理员团队的工作效率。要

找到根本性的症结只需一番简短的讨

论,根源得到解决,整个团队的生产力及服务质量将自然而然得到大幅度提

升。

所谓症结并不只是制造麻烦,重点在于它会分门别类、有组织有计划地

制造麻烦。

举例来说 :部署一套请求跟踪系统(或者“项目管理系统”)是比较常见、

没啥技术含量的基本做法。但该系统事实上一直在以许多明显或不甚明显

的方式支持着我们的团队。如果没有这套系统,我们可能面临着以下类型

Page 4: Linux运维趋势 第13期 服务器优化

004

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

人物People

004

A.面向公众的处理方式:

*1. 有没有通过项目管理系统对用

户请求进行跟踪?

*2. “三大授权策略”是否经过具体

定义并加以发布?

3. 整个团队的运行状态每月是否依各细则指标加以衡量并备案?

B. 现代化团队处理方式:

*4. 你在维基词条中是否具备独特的“策略及流程”类说明?

5. 日常所采用的密码安全性有保障吗?

6. 技术团队的代码是否处于源码控制系统的监管之下?

7. 你的团队有没有使用 bug 跟踪系统?

8. 在你的 bug/ 项目管理方面,稳定性问题的优先级是否高于新功能?

9. 你的团队有坚持记录“设计文档”的习惯吗?

10. 一旦发生问题,有没有一套机制专门用于记录故障信息?

C. 业务操作方式:

*11. 每项具体服务都具备操作文档吗?

*12. 每项服务是否都得到了适当的监管?

13. 你有没有部署过寻呼轮换机制?

14. 业务流程中是否具备彼此独立的开发、质量保证以及生产系统?

15. 在某套方案进行大范围推广前,有没有事先进行过必要的试点?

D. 自动化处理方式:

16. 有没有在业务中使用到类似 cfengine、puppet 以及 chef 之类的配置

管理工具?

17. 任务自动管理机制是否在身份账户的制约下进行?

18. 电子邮件的自动化生成处理是不是只在必要时启动,而非靠满纸荒

唐言来拼凑使用率?

E. 团队管理方式:

*19. 有没有一套专门的数据库用来

管理所有计算机设备?

20. 操作系统安装是否达到了完全自动化?

*21. 整个团队中的软件升级及补丁更新是否做到了自动化处理?

22. 有没有一套完整的硬件更新规章?

F. 硬件发生故障时的处理方式:

*23. 当某块硬盘发生问题时,你的整套服务器体系能否继续运作?

24. 网络核心有没有做到 N+1 ?

*25. 你的备份工作是自动完成的吗?

*26. 有没有定期测试灾难恢复方案的制度或计划?

27. 你数据中心内的设备具备远程电源 / 控制台访问功能吗?

G. 安全性处理方式:

*28. 业务中所用到的台式机、笔记本电脑以及服务器是否运行着自动更

新且无需确认提示的反恶意软件?

*29. 企业中是否向员工下发了书面的安全性规章制度?

30. 你有没有对所有相关领域进行周期性的安全审查?

31. 是否有相关机制允许管理者在一小时内关闭所有用户账户?

32. 是否有相关机制允许管理者在一小时内改变所有特权密码?

这 32 道问题,尤其是星号标记的问题,你回答了多少个“是”?如果还有

多项没有做到的话,那么这就行动起来吧!

原文 :http://everythingsysadmin.com/the-test.html

译文 :http://os.51cto.com/art/201109/294825.htm

“将所有请求保存在一套数据库中有助于团队

内部对信息的共享。”——自测题目#1

Page 5: Linux运维趋势 第13期 服务器优化

005

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

交流Interact

005

Quora使用到的技术

以前向大家介绍过 Stack Exchange 的系统架构和 Facebook 的系统架

构,今天和大家说说 Quora 的。本文主要参考了 Phil Whelan 的这篇文章

《Quora’s Technology Examined》。关于 Quora是个什么网站我就不多说了,

国内对他的 C2C 网站叫“知乎”。呵呵。我们还是来看看 Quora 的技术吧。

Search-Box

Quora 只能搜索问题,主题标签,用户名,和主题标题。没有全文搜索,所

以,你无法搜索问题和答案的内容。而搜索中使用前缀搜索方式,比如你输

入 mi,则 Microsoft 会马上出来。其搜索还会有一些非常简单的模糊匹配

的算法。另外,如果有重复的问题,其中一个问题会自动跳转到另一个问题,

但是在搜索中还是会出现。搜索中没有拼写检查。

一开始,他们使用的是一个开源的

搜索服务器,叫 Sphinx。其支持上述

的那些功能。现在他们不用这个技术

了,因为受到了一些限制。他们做了

一个比较新的解决方案,这个算法由 Python 实现。

Amazon Web Service

Quora 全部 host 在 AWS 的 EC2 和 S3 上,这对于这些刚刚起步的快速

发展的公司非常关键,因为你可以省去了很多硬件和维护的成本。(建一

个数据中心并不是所有公司都能干的事)。Quora 的操作系统使用 Ubuntu

Linux,这是非常容易部署和管理。

其静态页使用了 Amazon 的 CDN 的 Cloudfront 服务分发,CloudFront 用

于所有的静态图片 , CSS 和 JavaScript。图片先传到 EC2 服务器,使用

Pyhon S3 API 处理后后传到 S3。

HAProxy Load-Balancing

HAProxy 作为前端负载均衡服务器,反向代理服务器是 Nginx,Nginx 后

面则是 Pylons (Pylons + Paste) , 承担动态 Web 请求。

Pylons,是一个轻量级的 Web 框架,通常都是在 Nginx 后面使用。选用

Pylons 就像你在春节先饺子当主食一样。他们把 Pylons 中的 template 和

ORM 取走而使用自己的技术(由 Python 写成),这个地方就是 LiveNode 和

WebNode2 的地方。

Thrift

Thrift 用于后端服务器间的通讯。

Thrift 服务由 C++ 开发。Facebook 同

样使用了这个技术。

Tornado

Tornado web 框架用于实时更新,其运行在 Comet 服务器上,其用来处

理大量的需要长时间 poll 和 push 更新的网络连接。

Long Polling (Comet)

Quora 的网页并不是简单的显示,每一个页面都需要更新,或是创建问

题,答案和评论。所以,他们使用了 Long Polling 而不是传统的 Polling,传

文/Phil Whelan编译整理/陈皓

“Quora全部host在AWS的EC2和S3上,这对

于这些刚刚起步的快速发展的公司非常关键。”

Page 6: Linux运维趋势 第13期 服务器优化

006

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

交流Interact

006

统的 Polling 需要浏览器一端不停地重

复地向服务器询问——“有更新吗?”,

服务器说没有,于是过一会浏览大再

问,现在呢?服务器说,还是没有,浏览

器过一会又问,现在呢?服务器说,还没好。这样一来,就好像让我们的客

户端放到了驾驶室里,这显然是有问题的,因为只有服务器知道什么时候会

有更新。而且浏览器这么干,很快会让服务器的负载加上去。

Long polling 也就是我们熟知的 Comet,其让服务器来控制这些事,让

客服端等在那里听服务器的响应。在 client 和 server 的会话对于两者是是

相同的,而不是 client 需要等着然后向服务器查询。服务器端可以把一个

连接打开很长时间(比如 :60 秒),在这段时间里,服务器会查看是否有相应

的东西需要更新,如果有的话,就发给浏览器。如果没有的话,就等下一次

的 client 询问。可见,这种服务器等一会再响应的方法可以让浏览器少发

几次查询。

对于 long-polling 的最好的地方是,可以降低浏览器和客户端间来来回

回的次数。让服务器端来控制时间,所以,内容更新可能会只是几个毫秒,

或是几十秒。服务器端也可以积攒一堆更新后,一次发给浏览器。这样做

会更有效率。

但是,这个方法的黑暗面是——这会让服务器端出现大量的 TCP 链接,

想一想,Quora 也是百万级用户的应用了,只需要 10% 的在线用户,你就需

要一个可以处理 10 万并发量的架构。注意,如果一个用户在其浏览器里打

开了多个 Quora 网页的话,那么,这个链接器会是非常致命的。

当然,好的消息是已经有一些技术专门为 Long Polling 设计,这些技术可

以让你在那些等待的连接中只会消耗非常非常少的内存(因为那些等待连

接并不需要所有的资源)。例如 :Nginx 是一个单线程的事件驱动的小型服

务器,每一个链接只花非常小的内存。每一个 Nginx 的进程只会在一个时

候处理一个连接。这意味着其很容易扩展成一个可以处理成千上的并发量

的服务架构。

MySQL

就 像 Adam D’Angelo 的 老 东 家

facebook 一样,Quora 重度使用 MySQL。

他们的行事原则是,尽可能的把数据放在一台机器上,使用 hash 主键把

大规模的数据存放到多个数据库中。坚决不用表连接。Adam 参考了

FriendFeed 的一篇文章 How FriendFeed uses MySQL to store schema-less

data,并说你不应该在你的社区还没有 100 万用户的时候使用 NoSQL 数据

库。

并不只是 Quora 和 FriendFeed 使用 MySQL,Google,Twitter,Facebook 都

在使用 MySQL.

Memcached

Memcached 用于 MySQL 的前端缓存。

Git

Git 是他们的源码版本控制工具 .

Charlie Cheever 遵从 “14 Rules for Faster-Loading Web Sites”

Steve Souders, High Performance Web Sites 和 Even Faster Web

Sites 的作者,其列了一些 rules 让你网页更快的原则。 Charlie Cheever 的

Quora 创始人提到这些过,这应该也是 Quora 的速度的原因。

“One resource we used as a guide is Steve Souders’ list of rules for

high performance websites:http://stevesouders.com/hpws/rules.php”

本文有删节,完整内容见原文 :

http://coolshell.cn/articles/4939.html

英文原文 :Quora's Technology Examined

“只需要10%的在线用户,你就需要一个可以

处理10万并发量的架构。”

Page 7: Linux运维趋势 第13期 服务器优化

007

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

八卦News

007

红帽收购Gluster Nginx走向商业化

Nginx 宣布获得了来自包括 Dell CEO Michael Dell 私人投资公司等的

300 万美元投资,在 2012 年会推出一个商业版本。

http://os.51cto.com/art/201110/296452.htm

IBM 宣布将收购私营的系统软件公司 Platform Computing,这是一家分布

式计算环境集群和网格管理软件公司,客户包括 CERN、花旗集团等。

http://os.51cto.com/art/201110/296437.htm

Ubuntu 11.10 将成为首个支持 ARM 架构的操作系统,同时,它也是首个

新增云服务业务流程优化引擎 JuJu 的 Ubuntu 版本。

http://os.51cto.com/art/201110/296283.htm

Citrix 发布 XenServer 6,可以在思杰的 CloudStack 云平台上使用,支持

巨大的 VM,还可以通过微软的 System Center 2012(SCVMM)进行管理。

http://os.51cto.com/art/201110/295987.htm

40 年前的本月,也就是 1971 年 10 月,世界上第一封电子邮件 (Email)

被发出。

http://os.51cto.com/art/201110/295950.htm

Rackspace 宣布 :有意在 2012 年创办一个基金会,将 OpenStack 完全接管

过去,从而有机会创立一个真正开源的云计算项目。

http://os.51cto.com/art/201110/295947.htm

——八卦,新闻与数字 2011.09 - 2011.10

一个多月前,Kernel.org 公布了自己遭受的安全攻击,并将网站下线。现

在,Kernel.org 网站重新上线。

http://os.51cto.com/art/201110/295479.htm

Red Hat 宣布将以 1.36 亿美元现金的价格收购开源存储软件提供商

Gluster。Gluster 的产品主要用于管理非结构性数据。

http://os.51cto.com/art/201110/295377.htm

红帽企业版 6.2 Beta 发布,内核优化集成了处理器任务管理,网络,虚

拟化,I/O 子系统,创建 EXT4 文件系统速度更快。

http://os.51cto.com/art/201110/295776.htm

Ubuntu 是最受欢迎的 Linux 桌面发行版,有 62.1% 的受访者正在使用 ;

50% 的 Linux 用户曾经用过或正在使用 1 种以上的发行版。

http://os.51cto.com/art/201109/292937.htm

IBM 和 Canonical 之间有一些开发方面的合作,这是否意味着 IBM Power

小型机和刀片、System Z 大型机上将会出现 Ubuntu 的身影?

http://os.51cto.com/art/201109/292640.htm

Solaris 10 8/11 发布,该版本在性能上有所提升,并对新的硬件提供了

支持。更新后的 ZFS文件系统可以作为 root文件系统部署在 Solaris 10上。

http://os.51cto.com/art/201109/292161.htm

Page 8: Linux运维趋势 第13期 服务器优化

008

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

专题Special

008

服务器性能调优

性能调优,首先是要确定性能调优的目标是什么,如果现在应用已经满

足了需求,就没必要去做性能调优了,毕竟不经过一个系统的过程,其实是

无法确定你所做的性能调整是否真的调优了性能,是否没有造成应用中其

他的问题,所以确定性能目标是非常重要的。

在定义性能目标的时候通常这么定义的 :

1、最大并发数

2、Quality of Service :服务的质量,在软件系统方面我们认为主要表现

在请求的出错率,系统的 load 等。

3、最长响应时间 :对于任何请求所能承受的最大响应时间。

4、TPS :每秒需要支持的最大事务数,最典型的指标是 :“某页面最高需

要支撑每秒 7000 次的访问次数”。

例如一个 web 系统,需要定义出来的目标是 :

并发目标 :最高支撑 200 并发 ;

QoS :出错率须控制在万分之一,系统的 load 最高只能到达 10 ;

TPS :每秒完成 7000 次请求的处理 ;

最大响应时间 :最长允许的响应时间为 5 秒。

当然,还可以把性能指标定到更为细节,例如某个方法的 TPS 在 100 并

发时需要达到多少。

—— BlueDavy 之技术 Blog :性能调优概述

Page 9: Linux运维趋势 第13期 服务器优化

009

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

专题Special

009

Linux 性能及调优指南:了解Linux性能指标

在我们了解 Linux 操作系统中各种调优参数和性能度量工具前,有必要

讨论一下关于系统性能的各种可用指标和他们的意义。我们只涉及了最重

要的一些指标。

处理器性能指标

【CPU Utilization】

CPU 使用率,这可能是最直接的指标了,它表示每个处理器的整体使用

率。在 IBM System x 架构中,如果在持续一段时间里 CPU 使用率超过

80%,就可能预示着 CPU 出现了瓶颈。

【User Time】

用户时间,表示用户进程所花费的

CPU 百分比,包括 Nice 时间。在用户

时间值很高的情况下,表明系统正在

执行实际的工作。

【System Time】

系统时间,表示内核操作所花费的 CPU 百分比,包括硬中断 (IRQ) 和软

中断 (SoftIRQ)。系统时间值持续很高表明网络或驱动器堆栈可能存在瓶

颈。通常系统只花费很少时间在内核时间上。

【Waiting】

等待,花费在等待 I/O 操作所需的 CPU 时间总和,与阻塞【Blocked】值

相似,系统不应该花费过多的时间等待 I/O 操作 ;否则你应该检查一下 I/O

子系统各方面性能。

【Idle time】

空闲时间,表示 CPU 空闲的百分比。

【Nice time】

Nice 时间,表示花费在执行 re-nicing(改变进程的执行顺序和优先级)

进程的 CPU 百分比。

【Load average】

平均负载,不是百分比,是 TASK_RUNNING 和 TASK_UNINTERRUPTIBLE 之

和的平均值。如果请求 CPU 时间的进程

发生阻塞,平均负载将会上升。相反如果

每个进程都可以立即执行不会错过 CPU

周期,平均负载就会降低。

【Runable processes】

可运行进程,表示准备执行的进程。这个值在持续一段时间按内应该不

会超过物理处理器数量的 10 倍,否则 CPU 可能存在瓶颈。

【Blocked】

堵塞,在等待 I/O 操作完成前,进程是不能继续执行。进程堵塞可能意

味着 I/O 存在瓶颈。

文/IBM Redbooks译/飞哥也是哥

“如果在持续一段时间里CPU使用率超过

80%,就可能预示着CPU出现了瓶颈。”

Page 10: Linux运维趋势 第13期 服务器优化

010

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

专题Special

010

【Context switch】

上下文交换,系统中进程之间进行交

换的数量。上下文交换次数过多与大

量的中断有关,这可能暗示着驱动器或

应用程序存在问题。通常是不需要上

下文交换的,因为每次只需要刷新 CPU 缓存,但有些上下文交换是必要的。

【Interrupts】

中断数量中包括硬中断和软中断。硬中断会对系统性能产生非常不利

的影响。高中断值表明软件存在瓶颈,可能是内核或者驱动。请记住中断

值中也包括 CPU 始终所导致的中断。

内存性能指标

【Free memory】

空闲内存,与其它操作系统相比,不必过分在意空闲内存值。Linux 内核

将大量未使用的内存分配作为文件系统缓存使用,所以在已用内存扣除用

于缓冲和缓存的数量得到实际空闲内存。

【Swap usage】

交换空间使用,这个值表示已使用的交换空间数量。交换空间的使用只

能告诉你 Linux 在管理内存上是多么有效。要想确定内存是否存在瓶颈,

Swap In/Out 的数量才以为着用来。如果 Swap In/Out 长时间保持在每秒

钟超过 200 到 300 页以上可能表示内存存在瓶颈。

【Buffer and cache】

缓冲与缓存,被用来作为文件系统和块设备的缓存

【Slabs】

表示内核所使用的内存。注意内核

的页是不能被交换到硬盘上的。

【Active versus inactive memory】

活动与非活动内存,提供关于活动内存的相关信息。非活动内存会作为

候选被 kswapd 交换到硬盘。

网络性能指标

【Packets received and sent】

特定网卡已收到和已发送的封包数量。

【Bytes received and sent】

特定网卡已收到和已发送的字节数量。

【Collisions per second】

每秒钟冲突数,发生在指定网卡的网络冲突的数量。持续出现冲突值表

示在网络架构中存在瓶颈而不是服务器。在大多数正确配置网络中,冲突

是非常罕见的,除非网络架构是由 hub 组成的。

【Errors】

错误,被标示为失败的帧的数量。这经常是由于网络不匹配或部分网线

损坏引起的。对于铜缆千兆网部分网线损坏会产生严重的性能问题。

本文有删节,完整内容见原文 :

h t t p : / / h i . b a i d u . c o m / i m l i d a p e n g / b l o g /

item/2d1dc7cbc7235f1b7e3e6fe8.html

英文原文 :Linux Performance and Tuning Guidelines

“在大多数正确配置网络中,冲突是非常罕见

的。”

Page 11: Linux运维趋势 第13期 服务器优化

011

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

专题Special

011

小规模低性能低流量网站优化实践

假定现在你已经有了一个基本的 VPS 可用,基本内存 512MB 。参考

官方提供的各种安装指导将 LAMP 这个组合运行了起来,操作系统一般用

Ubuntu ,Web 服务器 Apache ,数据库 MySQL ,然后是 PHP ,以及需要

安装的应用软件,WordPress 、Drupal 或是 OpenCart 什么的,一步一步配

置好,能够正常的浏览页面。按照官方指导文档操作的一个好处是会包括

一些基本的优化一点的配置。不至于出现太大的错误。

一旦应用就绪后,登录到操作系统中,通过 top / iostat / free 等基本

操作系统命令收集基准数据,做记录。收集信息越全面,对于后面的优化就

越便利。优化没有魔法,只有合理的方法。

1.内存相关的调整

内部测试或是较小范围使用,可能

这样也不会遇到太大问题。一旦访问

人数多了一点,机器响应可能就有点

慢了。对于 VPS ,第一步着手调整

的就是各个组件对内存的使用。因为内存受限,对内存的使用一定要精打

细算一点。记住一旦内存耗尽,一部分内存调用压到磁盘上,系统负载会飙

升,一般就会挂掉。

一般来说,对于 LAMP 环境,以下几个地方要注意 :

PHP 程序的内存相关的调整

PHP5 配置文件 php.ini 中 memory_limit 定义的值默认情况是 16MB,

该参数定义单个 PHP 脚本消耗最大的内存大小 ( 大意 )。如果程序某个

页面需要的内存超过这个限制,访问者最可能遇到一个 HTTP 500 错误,

查看 Web 服务器错误日志也可以看到。多数情况下,这个值需要做相应

调整。比如设置为 32MB,是否合适,需要做观察。有一个经验方法是观察

top 命令的输出,看相应进程的 SHR 字段的值,实际上总是尽量大一点点。

但不能过大,一旦有个别程序写的不好调用的时候占用过多资源,会导致

VPS 挂掉。

经常有人问,这个服务器跑某某 Web 应用,能支持多少并发 ? 一个大

致的思路是估算单个进程占用的内存,看系统能分配多少内存给应用程序,

并发的量大致可以估算得到。但实际上,这个提问基本没多大价值。

另外,还有一个比较重要的参数需要修改 output_buffering 需要修改为

On 或是具体数值 (eg, 4096)。修改配

置后,检查是否生效 (如何检查 ?)。另外,

记住 error_log 的位置,随时查看。

MySQL 数据库内存占用

如果不确定 MySQL 内存使用情况,可以利用 MySQLReport 这个工具

收集一下 MySQL 实例的信息报告,不同时间段多收集几次作为对比。然

后相应的调整 key_buffer/query_cache_size 等参数的大小 , 一次调整一

个参数,重启动 MySQL ,继续抽取报告,分析数据,然后调整下一个参数。

既然需要编辑配置文件 my.cnf , 建议顺手加大一点 max_connections 这

个参数 ( 为什么 ?)。

多数内存问题都是由数据库 I/O 引起,导致 I/O 问题多由不合理数据

文/冯大辉

“一个大致的思路是估算单个进程占用的内

存,看系统能分配多少内存给应用程序。”

Page 12: Linux运维趋势 第13期 服务器优化

012

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

专题Special

012

库调用有关 ( 这么说严谨么 ?),解决不

合理调用要么修改应用,要么通过查询

缓存或是 Key-Value Cache 等办法缓

解。这地方说来话长,假定 VPS 上基

本不会有这么复杂的环境。

2. 影响 CPU 利用率的调整

这个主要针对 PHP 的 Opcode(Accelerator) 而言,解析、编译 PHP 代码

是相当消耗 CPU 的操作。常见的要么是 APC, 要么是 eAccelerator 或是

XCache,在 Ubuntu 下安装配置都相对简单,参数调整简单搜索一下就知

晓了。如果是 PHP 环境,那么一定要用 Opcode 减少 CPU 的负荷 ( 为什

么 ?)。至于用哪一个关系倒是不大,但前提是必须要有一个。

另外,张磊同学这篇 让进程运行在指定的 CPU 对于特定需求的应用,

很有借鉴意义。

3. 网络参数控制

修改 /etc/sysctl.conf 文件,增加如下几行 :

图片来源

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

然后 sudo sysctl -p 使修改生效。

使用如下一行命令观察半连接数量 :

$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a,

S[a]}'

其实一般来说,网络连接数不会成为最明显的瓶颈。但顺手调整一下也

好,「不费电」。有人问,如果遇到 DDoS 怎么办?忍着。

优化最重要的是找到瓶颈,对症下药。前面已经说到了内存、CPU、网络,

大致提了一点 I/O 问题,基本也就够了。PHP 的 Log , MySQL 的慢查询

Log ,Apache 的 Error Log ,常过滤看一下有没有新情况。

补充一点,别忘了修改 OS 的 ulimit 限制(配置步骤略)。

上面提到的不少修改建议不要照葫芦画瓢,知其然,还要知其所以然。

每一步的调整多阅读系统手册,尤其是涉及到具体的参数数值,一定要针

对实际情况修改。对基本的配置足够掌握之后,可以根据具体情况尝试性

能效率的组件,比如用 Nginx/Lighttpd 替换 Apache ,但是要记住,如果

Apache 不是瓶颈的话,用传说中性能更好的 Web 服务器来替换无疑是折

腾。

再次提醒不要过度优化,足够满足需求就行了。有更多的精力完全可以

放在其他环节上。另外,如果基本的调整做过之后,想用最省事的办法改善

性能,那么,直接向服务商购买额外的内存吧。

好吧,最后我想说的是其实这个优化思路并不局限于 VPS ,这个最小实

践套路对于复杂的服务器环境也是基本适用的。

本文有删节,完整内容见原文 :

http://www.dbanotes.net/techmemo/tuning_linode_vps.html

“PHP 的 Log , MySQL 的慢查询 Log ,

Apache 的 Error Log ,常过滤看一下。”

Page 13: Linux运维趋势 第13期 服务器优化

013

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

专题Special

013

详解服务器内存带宽计算和使用情况测量

前段时间我们在 MYSQL 调优上发现有瓶颈,怀疑是过多拷贝内存,导致

内存带宽用完。在 Linux 下 CPU 的使用情况有 top 工具 , IO 设备的使用情

况有 iostat 工具,就是没有内存使用情况的测量工具。 我们可以看到大量

的 memcpy 和字符串拷贝(可以用 systemtap 来测量),但是像简单的数据移

动操作就无法统计,我们希望在硬件层面有办法可以查到 CPU 在过去的一

段时间内总共对主存系统发起了多少读写字节数。

所以我们内存测量的的目标就归结为二点 :1. 目前我们这样的服务器

真正的内存带宽是多少。 2. 我们的应用到底占用了多少带宽。

首先来看下我们的服务器配置情况 :

$ sudo ~/aspersa/summary

(输出内容略)

DELL R710 的机器上有 2 个 X5670CPU, 每个上面有 6 个 core,超线程,

所以共有 24 个逻辑 CPU。上面插了 12 根 8192MB(1333 MHz) 内存条。

我们的机器架构从之前的 FSB 总线结构变成现在的 numa 架构,谢谢 @

fcicq 提供的信息 , 请参考右侧图片(来源):

我们可以清楚的看到每个 CPU 都有自己的内存控制器直接连接到内存

去,而且有 3 个通道, CPU 直接通过 QPI 连接。 内存控制器和 QPI 上面都

会流动数据。

我们服务器用的是 DDR3 内存,所以我们需要计算下在这样的架构下我

们内存的带宽。

DDR3 内存带宽如何计算,参看 这里

从配置信息可以看到我的服务器的内存条 : DIMM_A1 8192 MB 1333

MHz (0.8 ns), 有 12 根,每个 CPU 连接 6 根。

根据文章我们计算如下 :每个通道 (1333/8)*64*8 /8 = 10.6G

Byte ;而我们的 CPU 是 3 个通道的,也就是说这个 CPU 的总的内存带宽是

10.6*3=31.8G ;我的机器有 2 个 CPU, 所以总的通道是 63.6G, 理论上是

这样的对吧 ( 有错,请纠正我 ),我们等下实际测量下。

从上面的计算,显然内存带宽不是瓶颈。那问题出在那里呢,我们继续

看!

我们需要个工具能够搬动内存的工具。这类工具测试处理的带宽是指

在一个线程能跑出的最大内存带宽。 挑个简单的 mbw(mbw � Memory

BandWidth benchmark) 来玩下 :

$ sudo apt-get install mbw

$ mbw -q -n 1 256

文/Yu Feng

Page 14: Linux运维趋势 第13期 服务器优化

014

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

专题Special

014

(输出内容略)

CPU 内存带宽测量工具方面,在 @

王王争 同学大力帮助下,同时给我详

尽 地 介 绍 了 PTU(intel-performance-

tuning-utility), 在 这里 可以下载。

解开下载的二进制包后,bin 里面带的 vtbwrun 就是我们的硬件层面的内

存带宽使用测量工具,下面是使用帮助 :

$ sudo ptu40_005_lin_intel64/bin/vtbwrun --help

(输出内容略)

$ sudo ptu40_005_lin_intel64/bin/vtbwrun -c -A

运行期截图见下图 :

该图清楚的指出 System Memory Throughput(MB/s): 13019.45, 其中

QPI 也消耗挺大的。

此外,我们还需要知道 CPU 的 topology 结构,也就是说每个操作系统的

CPU 对应到哪个 CPU 哪个核心的哪个超线程去。有了这个信息,我们才能

用 taskset 把内存测试工具绑定到指定的 CPU 去,才能精确的观察内存使用

情况。

$ sudo ./cpu_topology64.out

(输出内容略)

# 或者最简单的方法,让 Erlang 告

诉我们

$ erl

(输出内容略)

# 我们顺手写个 shell 脚本可以运行多个 mbw 绑定在指定的 CPU 上

$ cat run_mbw.sh

#!/bin/bash

for i in $(seq $1 $3 $2)

do

echo $i

taskset -c $i mbw -q -n 9999 256 >/dev/null &

done

$ chmod +x run_mbw.sh

我们知道 CPU0 的逻辑 CPU 号码是奇数, CPU1 的逻辑 CPU 号码是偶数。

只要运行 ./run_mbw from to increase 就达到目的。

有了这些工具,我们就可以做试验了。喝口水继续 :

$ sudo ./run_mbw.sh 0 22 2

0

2

...

我们可以看到 CPU 的绑定情况,符合预期。

那么内存的带宽呢?有点问题,内存被 2 个 CPU 消耗,并且有 QPI。究根

本原因是我们在操作系统启动的时候把 numa 给关掉了,避免 mysqld 在大

内存的情况下引起 swap。(本文未完,完整内容见原文 :

http://blog.yufeng.info/archives/1511)

“究根本原因是我们在操作系统启动的时候把

numa给关掉了。”

Page 15: Linux运维趋势 第13期 服务器优化

015

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

专题Special

015

http长连接200万尝试及调优

对于一个 server,我们一般考虑他所能支撑的 qps,但有那么一种应用,

我们需要关注的是它能支撑的连接数个数,而并非 qps,当然 qps 也是我们

需要考虑的性能点之一。这种应用常见于消息推送系统,也称为 comet 应

用,比如聊天室或即时消息推送系统等。comet 应用具体可见我之前的介

绍,在此不多讲。对于这类系统,因为很多消息需要到产生时才推送给客户

端,所以当没有消息产生时,就需要 hold 住客户端的连接,这样,当有大量

的客户端时,就需要 hold 住大量的连接,这种连接我们称为长连接。

首先,我们分析一下,对于这类服务,需消耗的系统资源有 :cpu、网络、内

存。所以,想让系统性能达到最佳,我们先找到系统的瓶颈所在。这样的长

连接,往往我们是没有数据发送的,所以也可以看作为非活动连接。对于系

统来说,这种非活动连接,并不占用 cpu 与网络资源,而仅仅占用系统的内

存而已。所以,我们假想,只要系统内存足够,系统就能够支持我们想达到

的连接数,那么事实是否真的如此?

如果真能这样,内核来维护这相当大

的数据结构,也是一种考验。

要完成测试,我们需要有一个服务

端,还有大量的客户端。所以需要服务端程序与客户端程序。为达到目标,

我的想法是这样的 :客户端产生一个连接,向服务端发起一个请求,服务端

hold 住该连接,而不返回数据。

1. 服务端的准备

对于服务端,由于之前的假想,我们需要一台大内存的服务器,用于部署

nginx 的 comet 应用。下面是我用的服务端的情况 :

Summary:Dell R710, 2 x Xeon E5520 2.27GHz, 23.5GB / 24GB

1333MHz

System:Dell PowerEdge R710 (Dell 0VWN1R)

Processors:2 x Xeon E5520 2.27GHz 5860MHz FSB (16 cores)

Memory:23.5GB / 24GB 1333MHz == 6 x 4GB, 12 x empty

Disk-Control:megaraid_sas0: Dell/LSILogic PERC 6/i, Package

6.2.0-0013, FW 1.22.02-0612,

Network:eth0 (bnx2):Broadcom NetXtreme II BCM5709 Gigabit

Ethernet,1000Mb/s

OS:RHEL Server 5.4 (Tikanga), Linux 2.6.18-164.el5 x86_64, 64-

bit

服务端程序很简单,基于 nginx 写的一

个 comet 模块,该模块接受用户的请求,

然后保持用户的连接,而不返回。Nginx

的 status 模块,可直接用于监控最大连接

数。

服务端还需要调整一下系统的参数,在 /etc/sysctl.conf 中 :

net.core.somaxconn = 2048

net.core.rmem_default = 262144

net.core.wmem_default = 262144

net.core.rmem_max = 16777216

文/李飞勃

“有那么一种应用,我们需要关注的是它能支

撑的连接数个数,而并非qps。”

Page 16: Linux运维趋势 第13期 服务器优化

016

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

专题Special

016

net.core.wmem_max = 16777216

net.ipv4.tcp_rmem = 4096 4096

16777216

net.ipv4.tcp_wmem = 4096 4096

16777216

net.ipv4.tcp_mem = 786432 2097152 3145728

net.ipv4.tcp_max_syn_backlog = 16384

net.core.netdev_max_backlog = 20000

net.ipv4.tcp_fin_timeout = 15

net.ipv4.tcp_max_syn_backlog = 16384

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_max_orphans = 131072

/sbin/sysctl -p 生效

这里,我们主要看这几项 :

net.ipv4.tcp_rmem 用来配置读缓冲的大小,三个值,第一个是这个读缓

冲的最小值,第三个是最大值,中间的是默认值。我们可以在程序中修改读

缓冲的大小,但是不能超过最小与最大。为了使每个 socket 所使用的内存

数最小,我这里设置默认值为 4096。

net.ipv4.tcp_wmem 用来配置写缓冲的大小。

读缓冲与写缓冲在大小,直接影响到 socket 在内核中内存的占用。

而 net.ipv4.tcp_mem 则是配置 tcp 的内存大小,其单位是页,而不是字

节。当超过第二个值时,TCP 进入 pressure 模式,此时 TCP 尝试稳定其内

存的使用,当小于第一个值时,就退出 pressure 模式。当内存占用超过第三

个值时,TCP 就拒绝分配 socket 了,查看 dmesg,会打出很多的日志“TCP:

too many of orphaned sockets”。

另外 net.ipv4.tcp_max_orphans 这个值也要设置一下,这个值表示系统

所能处理不属于任何进程的 socket 数

量,当我们需要快速建立大量连接时,

就需要关注下这个值了。当不属于任

何进程的 socket 的数量大于这个值时,

dmesg 就会看到”too many of orphaned

sockets”。

另外,服务端需要打开大量的文件描述符,比如 200 万个,但我们设置最

大文件描述符限制时,会遇到一些问题,我们在后面详细讲解。

2. 客户端的准备

由于我们需要构建大量的客户端,而我们知道,在一台系统上,连接到一

个服务时的本地端口是有限的。由于端口是 16 位整数,也就只能是 0 到

65535,而 0 到 1023 是预留端口,所以能分配的只是 1024 到 65534,也就是

64511 个。也就是说,一台机器只能创建六万多个长连接。要达到我们的

两百万连接,需要大概 34 台客户端。

当然,我们可以采用虚拟 ip 的方式来实现这么多客户端,如果是虚拟 ip,

则每个 ip 可以绑定六万多个端口,34 个虚拟 ip 就可以搞定。而我这里呢,

正好申请到了公司的资源,所以就采用实体机来做了。

由于系统默认参数,自动分配的端口数有限,是从 32768 到 61000,所以

我们需要更改客户端 /etc/sysctl.conf 的参数 :

net.ipv4.ip_local_port_range = 1024 65535

/sbin/sysctl -p

客户端程序是基于 libevent 写的一个测试程序,不断的建立新的连接请

求。

3. 由于客户端与服务端需要建立大量的socket,所以我们需要调速一下最大文

件描述符。(本文未完,完整内容见原文:

http://blog.lifeibo.com/?p=269 )

“要达到我们的两百万连接,需要大概34台客

户端。当然,我们可以采用虚拟ip的方式。”

Page 17: Linux运维趋势 第13期 服务器优化

017

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

专题Special

017

MySQL数据库的优化:单机优化

单机 MySQL 的优化我分为三个部分,一是服务器物理硬件的优化,二是

MySQL 安装时的编译优化,三是自身配置文件 my.cnf 的优化。

一、服务器硬件对MySQL性能的影响

磁盘寻道能力(磁盘 I/O),我们现在上的都是 SAS15000 转的硬盘。

MySQL 每秒钟都在进行大量、复杂的查询操作,对磁盘的读写量可想而知。

所以,通常认为磁盘 I/O 是制约 MySQL

性能的最大因素之一,对于日均访问量

在 100 万 PV 以上的 Discuz! 论坛,由于

磁盘 I/O 的制约,MySQL 的性能会非常

低下!解决这一制约因素可以考虑以下几种解决方案 : 使用 RAID1+0 磁

盘阵列,注意不要尝试使用 RAID-5,MySQL 在 RAID-5 磁盘阵列上的效率

不会像你期待的那样快 ;

CPU 对于 MySQL 应用,推荐使用 DELL R710,E5620 @2.40GHz(4

core)* 2 ,我现在比较喜欢 DELL R710,也在用其作 Linux 虚拟化应用 ;

物理内存对于一台使用 MySQL 的 Database Server 来说,服务器内存建

议不要小于 2GB,推荐使用 4GB 以上的物理内存,不过内存对于现在的服务

器而言可以说是一个可以忽略的问题,工作中遇到高端服务器基本上内存

都超过了 32G。我们工作中用得比较多的数据库服务器是 HP DL580G5 和

DELL R710,稳定性和性能都不错 ;特别是 DELL R710,我发现许多同行都是

采用它作数据库的服务器,所以重点推荐下。

二、MySQL的线上安装

我建议采取编译安装的方法,这样性能上有较大提升,服务器系统我建

议用 64bit 的 CentOS 5.5,源码包的编译参数会默认以 Debug 模式生成二

进制代码,而 Debug 模式给 MySQL 带来的性能损失是比较大的,所以当我

们编译准备安装的产品代码时,一定不要忘记使用“--without-debug”参

数禁用 Debug 模式。

而 如 果 把 --with-mysqld-ldflags

和 --with-client-ldflags 二个编译参

数设置为 --all-static 的话,可以告诉

编译器以静态方式编译和编译结果代

码得到最高的性能。使用静态编译和使用动态编译的代码相比,性能差距

可能会达到 5%至 10%之多。我参考了简朝阳先生的编译参数,特列如下,

供大家参考

./configure �prefix=/usr/local/mysql �without-debug �without-

bench �enable-thread-safe-client �enable-assembler �enable-profiling

�with-mysqld-ldflags=-all-static �with-client-ldflags=-all-static

�with-charset=latin1 �with-extra-charset=utf8,

gbk �with-innodb �with-csv-storage-engine �with-federated-

storage-engine �with-mysqld-user=mysql �without-embedded-server

�with-server-suffix=-community �with-unix-socket-path=/usr/

local/mysql/sock/mysql.sock

文/抚琴煮酒

“Debug模式给MySQL带来的性能损失是比较

大的。”

Page 18: Linux运维趋势 第13期 服务器优化

018

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

专题Special

018

三、my.cnf优化

对 MySQL 自身的优化主要是对其

配置文件 my.cnf 中的各项参数进行优

化调整。下面,我们根据以上硬件配置

结合一份已经优化好的 my.cnf 进行说

明 :

#vim /etc/my.cnf

以下只列出 my.cnf 文件中 [mysqld] 段落中的内容。(注释部分略)

[mysqld]

port = 3306

serverid = 1

socket = /tmp/mysql.sock

skip-locking

skip-name-resolve

back_log = 384

key_buffer_size = 384M

max_allowed_packet = 4M

thread_stack = 256K

table_cache = 614K

sort_buffer_size = 6M

read_buffer_size = 4M

join_buffer_size = 8M

myisam_sort_buffer_size = 64M

table_cache = 512

thread_cache_size = 64

query_cache_size = 64M

tmp_table_size = 256M

max_connections = 768

max_connect_errors = 1000

wait_timeout = 10

thread_concurrency = 8

skip-networking

table_cache=1024

innodb_additional_mem_pool_size=4M

innodb_flush_log_at_trx_commit=1

innodb_log_buffer_size=2M

innodb_thread_concurrency=8

key_buffer_size=256M

tmp_table_size=64M

read_buffer_size=4M

read_rnd_buffer_size=16M

sort_buffer_size=32M

thread_cache_size=120

query_cache_size=32M

※ 值得注意的是 :

一、如果 Key_reads 太大,则应该把 my.cnf 中 Key_buffer_size 变大,保持

Key_reads/Key_read_requests 至少 1/100 以上,越小越好。

二、如果 Qcache_lowmem_prunes 很大,就要增加 Query_cache_size 的值。

很多时候我们发现,通过参数设置进行性能优化所带来的性能提升,可

能并不如许多人想象的那样产生质的飞跃,除非是之前的设置存在严重不

合理的情况。我们不能将性能调优完全依托于通过 DBA 在数据库上线后

进行的参数调整,而应该在系统设计和开发阶段就尽可能减少性能问题。

本文有删节,完整内容见原文 :

http://database.51cto.com/art/201103/247839.htm

“保持Key_reads/Key_read_requests至少

1/100以上,越小越好。”

Page 19: Linux运维趋势 第13期 服务器优化

019

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

专题Special

019

MySQL写入优化

innodb_buffer_pool_size

如果用 Innodb,那么这是一个重要变量。相对于 MyISAM 来说,Innodb

对于 buffer size 更敏感。MySIAM 可能对于大数据量使用默认的 key_

buffer_size 也还好,但 Innodb 在大数据量时用默认值就感觉在爬了。

Innodb 的缓冲池会缓存数据和索引,所以不需要给系统的缓存留空间,如果

只用 Innodb,可以把这个值设为内存的

70%-80%。和 key_buffer 相同,如果

数据量比较小也不怎么增加,那么不要

把这个值设太高也可以提高内存的使

用率。

innodb_additional_pool_size

这个的效果不是很明显,至少是当操作系统能合理分配内存时。但你可

能仍需要设成 20M 或更多一点以看 Innodb 会分配多少内存做其他用途。

innodb_log_file_size

对于写很多尤其是大数据量时非常重要。要注意,大的文件提供更高的

性能,但数据库恢复时会用更多的时间。我一般用 64M-512M,具体取决于

服务器的空间。

innodb_log_buffer_size

默认值对于多数中等写操作和事务短的运用都是可以的。如果经常做

更新或者使用了很多 blob 数据,应该增大这个值。但太大了也是浪费内存,

因为 1 秒钟总会 flush(这个词的中文怎么说呢?)一次,所以不需要设到

超过 1 秒的需求。8M-16M 一般应该够了。小的运用可以设更小一点。

innodb_flush_log_at_trx_commit (这个很管用)

抱怨 Innodb 比 MyISAM 慢 100 倍?那么你大概是忘了调整这个值。默

认值 1 的意思是每一次事务提交或事务外的指令都需要把日志写入(flush)

硬盘,这是很费时的。特别是使用电

池供电缓存(Battery backed up cache)

时。设成 2 对于很多运用,特别是从

MyISAM 表转过来的是可以的,它的意

思是不写入硬盘而是写入系统缓存。日志仍然会每秒 flush 到硬 盘,所以

你一般不会丢失超过 1-2 秒的更新。设成 0 会更快一点,但安全方面比较

差,即使 MySQL 挂了也可能会丢失事务的数据。而值 2 只会在整个操作系

统 挂了时才可能丢数据。

上面是网上看的,我发现慢查询日志内有很多 update 和 insert 的查询,

就把 innodb_flush_log_at_trx_commit 改成了 2,效果很明显,改成 0 会更明

显,但安全性比较差。做下面的操作启动 mysqld 就生效 :

vim /etc/my.cnf

innodb_flush_log_at_trx_commit=2

也可以在 mysqld 运行时执行 :

set GLOBAL innodb_flush_log_at_trx_commit = 2

下面是 mysql 手册上 innodb_flush_log_at_trx_commit 的解释 :

文/崔玉松

“大的文件提供更高的性能,但数据库恢复时

会用更多的时间。”

Page 20: Linux运维趋势 第13期 服务器优化

020

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

专题Special

020

如果 innodb_flush_log_at_trx_commit 设置为 0,log buffer 将每秒一次地

写入 log file 中,并且 log file 的 flush( 刷到磁盘 ) 操作同时进行 ;但是,这

种模式下,在事务提交的时候,不会有任何动作。如果 innodb_flush_log_

at_trx_commit 设置为 1( 默认值 ),log buffer 每次事务提交都会写入 log

file,并且,flush 刷到磁盘中去。如果 innodb_flush_log_at_trx_commit 设置

为 2,log buffer 在每次事务提交的时候都会写入 log file,但是,flush( 刷

到磁盘 ) 操作并不会同时进行。这种模式下,MySQL 会每秒一次地去做

flush( 刷到磁盘 ) 操作。注意 :由于进程调度策 略问题,这个“每秒一次的

flush( 刷到磁盘 ) 操作”并不是保证 100% 的“每秒”。

默认值 1 是为了 ACID (atomicity, consistency, isolation, durability)

原子性,一致性,隔离性和持久化的考虑。如果你不把 innodb_flush_log_at_

trx_commit 设置为 1,你将获得更好的性能,但是,你在系统崩溃的情况,可

能会丢失最多一秒钟的事务数据。当你把 innodb_flush_log_at_trx_commit

设置 为 0,mysqld 进程的崩溃会导致上一秒钟所有事务数据的丢失。如

果你把 innodb_flush_log_at_trx_commit 设置为 2,只有在操作系统崩溃或

者系统掉电的情况下,上一秒钟所有事务数据才可能丢失。InnoDB 的 crash

recovery 崩溃恢复机制并不受这个值的影响,不管这个值设置为多少,crash

recovery 崩溃恢复机制都会工作。

另外 innodb_flush_method 参数也值得关注,对写操作有影响 :

innodb_flush_method : 设置 InnoDB 同步 IO 的方式 :

1) Default � 使用 fsync()。

2) O_SYNC 以 sync 模式打开文件,通常比较慢。

3) O_DIRECT,在 Linux 上使用 Direct IO。可以显著提高速度,特别是

在 RAID 系统上。避免额外的数据复制和 double buffering(mysql buffering

和 OS buffering)。

原文 :

http://fendou.org/2011/08/30/mysql 写入优化 /

【特别推荐】

大话IT第15期

——列数最强企业版Linux企业级 Linux 市场百花齐放,红帽 RHEL、SUSE Enterprise Linux、

Ubuntu Enterprise Linux 都各有什么本事?

本期大话 IT 带你走近企业级 Linux,简单探讨一下企业级 Linux 的

特性和不同版本之间的差异之处。

在线收听 :http://os.51cto.com/art/201109/289849.htm

下载音频 :http://down.51cto.com/data/247325

大话 IT 下载专题 :http://down.51cto.com/zt/99

注 :本期节目中所述企业版 Linux 仅包括有厂商商业支持的 Linux

版本,其中 CentOS已经在 2009年由 OpenLogic提供付费的商业支持。

本期参与录制 :沫沫、浩浩、Sunny、嘉文、鲜橙

主持人 :嘉文、鲜橙

本期编导 :鲜橙

脚本监督 :lazycai

《IT 听听看》微博 :http://t.sina.com.cn/itttkan

有关IT听听看之大话IT:

由一群喜欢音频的 IT 从业者自发性建立的栏目,针对 IT 业界或技

术点进行轻松的调侃和剖析,目地是让大家再轻松之余了解到 IT 信

息,让 IT 专业人士和普通人都能听出快乐是团队目标。

Page 21: Linux运维趋势 第13期 服务器优化

021

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

技巧Tips

021

应用SELinux中的目标策略限制进程运行

几乎所有的服务进程都在限制下运行。并且,大多数以 root 身份运行的

系统进程(比如说 passwd 进程)都是受限制域性的。当进程受限制时,它

只能在自己限制的域内运行,例如 Web 服务进程 httpd 只能运行在 httpd_t

域内。如果一个受限制的进程被黑客攻击并控制了,根据 SELinux策略配置,

这个黑客也仅仅只能访问这个受限制的域,因此攻击所带来的危害也比传

统的 Linux 小了很多。

以下通过一个具体的限制进程的例

子(RHEL 或者 Fedora 系统中的例子)来

说明 SELinux 是如何将进程限制在自己

的域内运行的。这个例子以用户非常

熟悉且常用的 Apache 服务器中的 httpd 进程为例,来介绍 SELinux 是如何

阻止 httpd 进程来访问由其他域管理的文件类型的。

(1)运行 sestatus 命令来确认 Linux 中 SELinux 是运行的,它运行在

enforcing 模式下,该模式可以简单理解为 SELinux 的完全运行模式,它可以

进行强制访问控制),且确保采用了目标策略,如图 1 命令所示 :

图1 使用sestatus确认SELinux是否运行

运行结果表明 SELinux 运行在 enforcing 模式下,且采用了目标策略。

(2)采用 Linux 中的 root 用户权限,使用如下命令在 httpd 的工作目录中

创建一个新的文件 :

#touch /var/www/html/testfile

(3)运行如下命令来查看该文件的 SELinux 上下文信息 :

# ls -Z /var/www/html/testfile

- r w - r - - r - - r o o t r o o t

uncon f i ned_u:ob j ec t_ r:h t t pd_sys_

content_t:s0 /var/www/html/testfile

从上述结果可以清楚地看到 :在默

认情况下,Linux 用户是非限制的,因此刚创建的 testfile 文件的 SELinux 上

下文中的类型标记为 unconfined_u。RBAC 访问控制机制是用于进程的,不

是用于文件。并且,角色对于文件来说也没有什么太大的含义,因此上述

结果中的 object_r 角色也仅仅是一个用于文件的通用角色。在 /proc 目录

下,与进程相关的文件可以采用 system_r 角色。另外,结果中的 httpd_sys_

content_t 类型允许 httpd 进程访问该文件。

(4)以 Linux 的 root 用户身份,运行下述命令来运行 httpd 进程 :

#/sbin/service httpd start

(5)切换到一个 Linux 用户具有权限的目录下,运行如下命令,确认是否

能够正确的执行并下载文件 :

#wget http://localhost/testfile

(6)使用 chcon 命令来对文件的类型进行重新标识。然而,这样的标识

文/李洋

“在默认情况下,Linux用户是非限制的。”

Page 22: Linux运维趋势 第13期 服务器优化

022

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

技巧Tips

022

不是永久性的修改,一旦系统重启,该

标识就会改变回去。对于文件类型的

永久性改变,需要采用 semanage 命令,

这个命令在后面将进行详细介绍。下

面,以 root 用户的身份,运行图 4 所示

chcon 命令来将上面步骤中创建的 testfile 文件的类型改为由 Samba 进程使

用的文件 ;然后,运行 ls -z /var/www/html/testfile 命令来查看改变的

结果,如图 2 所示。

图2 chcon命令运行结果

(7)在传统的 Linux 中 httpd 进程可以访问 testfile 文件,下面需要尝试

一下在 SELinux 中,该进程是否能够成功访问 testfile 文件。如步骤(5)所

示,再次运行该命令进行文件下载工作,发现命令运行失败,文件没有权限

下载,运行结果如图 3 所示。

图3 wget命令执行失败

通过上述 7 个步骤的详细演示可以得知 :虽然传统的 Linux 的 DAC 机制

允许 httpd 进程访问 testfile 文件,然而 SELinux 的 MAC 机制却拒绝该访问

操作。原因在于 :该文件的类型(samba_share_t)httpd 进程不能访问,因此

SELinux 拒绝了该操作。同时,SELinux 对这些操作日志进行了详细的记载,

以方便系统管理员事后进行审计和处

理,可以查看 /var/log/messages 文件,

如图 4 所示。

另外,相关的错误日志也可以查看 /

var/log/audit/audit.log 文件 :

type=AVC msg=audit(1241564654.246:26): avc: denied { getattr }

for pid

图4 /var/log/messages文件图示

并且,由于该操作牵涉到 httpd 服务进程,由于该服务也有自己的日志

文件,因此,也可以通过 /var/log/httpd/error_log 文件进行查看,如图 5 所

示 :

图5 /var/log/httpd/error_log文件图示

本文有删节,完整内容见原文 :

http://netsecurity.51cto.com/art/201110/295978.htm

“SELinux对这些操作日志进行了详细的记

载,以方便系统管理员事后进行审计和处理。”

Page 23: Linux运维趋势 第13期 服务器优化

023

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

运维DBADatabase

023

MySQL从库集群方案之HAProxy篇

HAProxy 反向代理服务器支持双机热备支持虚拟主机,其配置简单,拥

有非常不错的服务器健康检查功能。当其代理的后端服务器出现故障,

HAProxy 会自动将该服务器摘除,故障恢复后再自动将该服务器加入。

这里有两台 HAProxy 机器,分别安装 keepalived,组成热备形式。作用 :

当一台有问题,另一台可以在 1 秒内接管。

xinetd 服务的作用是检测端口,本文中使用 8890 端口。HAProxy 用 http

协议检测这个端口是否正常。

MySQL 同步状态脚本,是放在从库本地,由 xinetd 服务来激活脚本,正常

就会输出 200 状态码给 HAProxy,证明从库正常 ;否则,就剔除。(这里就可

以加上短信报警了)

系统架构图(见本页右侧)

使用软件

HAProxy 1.4.16

Keepalived 1.1.20

Xinetd 2.3.14

MySQL 同步状态脚本 0.2

一、系统约定

系统环境

OS:CentOS 5.6 x86_64

MASTER:192.168.1.65

BACKUP:192.168.1.66

VIP:192.168.1.67

serivce Port:3306

文/崔晓辉

Page 24: Linux运维趋势 第13期 服务器优化

024

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

运维DBADatabase

024

工作流程

准备工作 :应用配置好 slave 的 VIP 192.168.1.67 端口 3306

(1) 应用服务器

(2) 连接 HAProxy 的 vip 192.168.1.67:3306,根据算法,分配到一台

slave。

(3) 检测 slave 的 8890 端口是否返回 http 200 状态码。

(4) 返回 200 状态码,HAProxy 返回正常,继续服务。

(5) 返回 503,剔除该 slave,并将 mysql 请求转发到另外一台 slave。

(6) 有问题的 slave,发送短信报警,相关人员检查。

二、Keepalived 1.1.20 的安装配置(略,详见原文)

三、HAProxy 1.4.16 的安装与配置(略,详见原文)

四、xinetd 安装和配置(略,详见原文)

MySQL 同步检测脚本(脚本检测同步 sql 和 IO 进程是否都为真,以及

select 是否达到 20 个进程以上)

#!/bin/bash

# /usr/local/bin/mysqlchk_status.sh

# This script checks if a mysql server is healthy running

# on localhost. It willreturn:

# "HTTP/1.x 200 OK\r" (if mysql is running smoothly)

# � OR �

# "HTTP/1.x 503 Internal Server Error\r" (else)

MYSQL_HOST="localhost"

MYSQL_PORT="3306"

MYSQL_USERNAME="repdb63"

MYSQL_PASSWORD="mylqs9eyex7s"

# We perform a simple query that should return a few results

#/usr/loca l/mysql/bin/mysql -hloca lhos t �u repdb63 �

pmylqs9eyex7s -e "show slave status\G;" > /tmp/rep.txt

mysql -urepdb63 -pmylqs9eyex7s -e "show full processlist;" >/

tmp/processlist.txt

mysql -urepdb63 -pmylqs9eyex7s -e "show slave status\G;" >/

tmp/rep.txt

iostat=`grep "Slave_IO_Running" /tmp/rep.txt |awk '{print $2}'`

sqlstat=`grep "Slave_SQL_Running" /tmp/rep.txt |awk '{print $2}'`

result=$(cat /tmp/processlist.txt|wc -l)

#echo iostat:$iostat and sqlstat:$sqlstat

# if slave_IO_Running and Slave_sql_Running ok,then return 200 code

if [ "$result" -lt "20" ] && [ "$iostat" = "Yes" ] && [ "$sqlstat"

= "Yes" ];

then

# mysql is fine, return http 200

/bin/echo -e "HTTP/1.1 200 OK\r\n"

else

# mysql is down, return http 503

/bin/echo -e "HTTP/1.1 503 Service Unavailable\r\n"

fi

注意 :在 mysql slave 另行建立一个具有 process 和 slave_client 权限的

账号。

本文有删节,完整内容见原文 :

http://os.51cto.com/art/201109/293493.htm

Page 25: Linux运维趋势 第13期 服务器优化

025

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

脚本Scripts

025

Linux上获取本机ip的各种perl写法

大家讨论使用 Gearman 做分布式处理时,各机需要注册一个独立的 job

作为信息反馈,但是为了方便,Gearman::Worker 脚本 register_function 代

码又要通用,于是想到了使用各自的 ip 地址作为 job 命名 ~

那么怎么在 worker 脚本里获取本机 ip 作为 func 呢?

第一种办法,最简单的,调用 shell :

$ip = `ifconfig eth0|grep -oE '([0-9]{1,3}\.?){4}'|head -n 1`;

注 :这里输入是固定的,所以简单的 [0-9]{1,3} 了,如果是在 web 程序

等地方验证 ip,需要更严谨!

或者

$ip = `ifconfig eth0|awk -F: '/inet addr/{split($2,a," ");print

a[1];exit}'`;

好吧,这样显得太不 perl 了,而且频繁的调用外部 shell 不太好,第二种 :

open FH,"ifconfig eth0|";

while(<FH>){

last unless /inet addr:((\d{1,3}\.?){4})/;

print $1;

}

看起来稍微 perl 了一些,虽然实质跟上面的调用 shell 和 grep 法是一样

的。

第三种,更 perl 一点,纯粹读文件 :

open FH,'<','/etc/sysconfig/network-scripts/ifcfg-eth0';

while(<FH>){

next unless /IPADDR\s*=\s*(\S+)/;

print $1;

}

进一步的,如果不一定 rh 系,还要去读 /etc/issue,确定网络配置文件

到 底 是 /etc/sysconfig/network-script/ifcfg-eth0 还 是 /etc/network/

interfaces 还是其他,然后根据不同发行版写不同的处理方法……

好 吧,大 家 来 充 分 体 会 CPAN 的 魅 力,去 search 一 下,找 到 一 把

Sys::HostIP、Sys::HostAddr、Net::Inetface 等模块。第四种 :

use Sys::HostAddr;

my $interface = Sys::HostAddr->new(ipv => '4', interface =>

'eth0');

print $interface->main_ip;

不过进去看看 pm 文件,汗,这几个模块都是调用 ifconfig 命令,不过是根

据发行版的不同进行封装而已。

还有办法么?还有,看第五种 :

perl -MPOSIX -MSocket -e 'my $host = (uname)[1];print inet_

ntoa(scalar gethostbyname($host))';

不过有童鞋说了,这个可能因为 hostname 的原因,导致获取的都是

127.0.0.1……

那么最后还有一招。通过 strace ifconfig 命令可以看到,linux 实质是通

过 ioctl 命令完成的网络接口 ip 获取。那么,我们也用 ioctl 就是了!

#!/usr/bin/perl

use strict;

use warnings;

文/三斗室

Page 26: Linux运维趋势 第13期 服务器优化

026

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

脚本Scripts

026

use Socket;

require 'sys/ioctl.ph';

sub get_ip_address($) {

my $pack = pack("a*", shift);

my $socket;

socket($socket, AF_INET, SOCK_DGRAM, 0);

ioctl($socket, SIOCGIFADDR(), $pack);

return inet_ntoa(substr($pack,20,4));

};

print get_ip_address("eth0");

这样的好处,就是只调用了核心模块,在分发脚本时,不用连带安装其他

模块。

注 :这个其实是根据网上有的一个 py 的脚本修改的,py 版如下 :

#!/usr/bin/python

import socket

import fcntl

import struct

def get_ip_address(ifname):

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

return socket.inet_ntoa(fcntl.ioctl(

s.fileno(),

0x8915, # SIOCGIFADDR

struct.pack('256s', ifname[:15])

)[20:24])

print get_ip_address('eth0')

原 文 :http://chenlinux.com/2011/09/20/get-ip-address-by-perl-

on-linux.html

【特别推荐】

51CTO专项调研

Linux桌面发行版生存状况·65.9% 的 Linux 桌面用户最初从技术网站和学校了解 Linux,另

有 27.8% 由口口相传得知 Linux。可见,Linux 相关的推广目前集中

在技术网站与高校,在中小学以及公共领域的推广力度相对较弱

·62.6% 的 Linux 桌面用户同时也在从事 Linux 相关的工作,其中

又以 Linux 运维为主

·Ubuntu 是最受欢迎的 Linux 桌面发行版,有 62.1% 的受访者正

在使用 ;50% 的 Linux 用户曾经用过或正在使用 1 种以上的发行版

·50% 的受访者对目前 Linux 平台上的软件支持情况表示不满意,

说明软件支持仍是 Linux 桌面普及的瓶颈

·28% 的 Linux 用户已购买智能手机、平板等移动设备,50% 表示

关注。移动终端的发展对 Linux 桌面也已经产生冲击

——更多调研结果,请查阅《51CTO 专项调研 :Linux 桌面发行版

生存状况》

报告下载地址(51CTO 下载频道):

http://down.51cto.com/data/254493

报告下载地址(微盘):

http://vdisk.weibo.com/s/FCTk

报告在线阅读(SlideShare):

http://www.slideshare.net/51CTO/51cto-linuxfinal

Page 27: Linux运维趋势 第13期 服务器优化

027

《Linux 运维趋势》投稿信箱 : [email protected]

杂志订阅 : http://os.51cto.com/art/201011/233915.htm

51CTO 系统频道:http://os.51cto.com

工具Tools

027

拼装的艺术:vim之IDE进化实录

vim 有一套自己的脚本语言,通过这种脚本语言可以实现与 vim 交互

的,达到功能扩展的目的。一组 vim 脚本就是一个 vim 插件,vim 的很

多功能都是通过其插件实现,在官网上有丰富的插件资源,任何你想得到的

功能,如果 vim 无法直接支持,那一般都有对应的插件为你服务,有需求时

可以去逛逛。

vim 插件目前分为两类 :*.vim 和 *.vba。前者是传统格式的插件,实

际上就是一个文本文件,通常 someplugin.vim (插件脚本)与 someplugin.

txt(插件帮助文件)并存在一个打包文件中,解包后将 someplugin.vim 拷

贝到 ~/.vim/plugin/ 目录,someplugin.txt 拷贝到 ~/.vim/doc/ 目录即

可完成安装,重启 vim 后刚安装的插件就已经生效,但帮助文件需执行

helptags ~/.vim/doc/ 才能生效。传统格式插件需要解包和两次拷贝才能

完成安装,相对较繁琐,所以后来又出现了 *.vba 格式插件,安装更便捷,

只需在 shell 中依次执行如下命令即可 :

vim someplugin.vba

:so %

:q

有时间,建议看看它们的帮助文档(:h someplugin)。

[-多文档编辑-]

一个 EXCEL 文档可以有多个 SHEET,你可以在不同 SHEET 间来回切

换,同样,编程时也需要类似功能,即,同时打开多个文件,可以自由自在地

在不同代码文件间游历。这种需求,vim 是通过 buffer 来实现的。每打开

一个文件 vim 就对应创建一个 buffer,多个文件就有多个 buffer。

插件名 :MiniBufExplorer

操作 :打开一个以上文档时,vim 在窗口顶部自动创建 buffer 列表窗

口。光标在任何位置时,CTRL-TAB 正向遍历 buffer, CTRL-SHIFT-TAB

逆向遍历 ;光标在 MiniBufExplorer 窗口内,输入 d 删除光标所在的 buffer

注意 :将如下信息加入 .vimrc 中 :

“允许光标在任何位置时用 CTRL-TAB 遍历 buffer

let g:miniBufExplMapCTabSwitchBufs=1

编辑单个文档时,不会出现 buffer

列表,如左图所示。

当前编辑的是 hardinfo.c 文件,该

文件中有调用 parameters_init() 函数,

但该函数定义在 util.c 文件中,当我

在 parameters_init() 上 输 入 CTRL-]

后,vim 新建 util.c 文件的 buffer 并

自动定位到 parameters_init(),这时,

vim 同时在编辑 hardinfo.c 和 util.c

两个文档,可从顶部的 buffer 列表中

查看到。如左图所示。

本文为删节版,完整内容见原文

(PDF 下载):

http://ishare.iask.sina.com.cn/f/18766458.html

文/[email protected]

Page 28: Linux运维趋势 第13期 服务器优化

招募启事《Linux 运维趋势》的建设需要您的加入!

您可以通过如下方式参与我们杂志的建设 :

1、推荐文章

无论是您在互联网上看到的好文章,还是您自己总结 / 整理的资

料 ;无论是英文还是中文 ;无论是入门的还是高端的,都欢迎推荐!

您可以直接在《Linux 运维趋势》新浪微群中分享 :

http://q.weibo.com/121303

2、投稿

如果您愿意与大家分享您技术经验的热诚,那么欢迎您的投稿!

原创或译文均可,稿件在 51CTO 首发可领取稿酬 :)

投稿信箱 :[email protected]

3、推广与意见

如果您喜欢我们的杂志,认为这本杂志对于您的工作有所帮助,请

向您的 Linux 好友、同事们推荐它!

如果您觉得这份杂志还有什么地方需要改进或补充,也希望您能

够提出您的宝贵意见!

反馈可至《Linux 运维趋势》新浪微群 :

http://q.weibo.com/121303

或在新浪微博

@51CTO 系统频道

本刊发布日期 :每个月的第二个星期五

您可以通过如下方式检查新刊发布 :

1、电子邮件订阅 :

http://os.51cto.com/art/201011/233915.htm

2、RSS 订阅 :

http://www.51cto.com/php/rss.php?typeid=777

3、iPad 订阅 :

...coming soon!

本期杂志封面由 钱靓 制作

《Linux 运维趋势》是由 51CTO 系统频道策划、针对 Linux/Unix 系

统运维人员的一份电子杂志,内容从基础的技巧心得、实际操作案例

到中、高端的运维技术趋势与理念等均有覆盖。

《Linux 运维趋势》是开放的非盈利性电子杂志,其中所有内容均收

集整理自国内外互联网(包含 51CTO 系统频道本身的内容)。对于来

自国内的内容,编辑都会事先征求原作者的许可(八卦,趣闻 & 数字

栏目例外)。如果您认为本杂志的内容侵犯到了您的版权,可发信至

[email protected] 进行投诉。