Tag Archives: Tuning

Tuning Linode VPS-小规模低性能低流量网站优化实践

偶然看到以前写过的这篇帖子 『小规模低性能低流量网站设计原则』,重新发到微博上引起了一点反响,觉得有必要以 Linode VPS 为例再做个简单的优化实践说明,免得总有人问我,也顺便赚点点击量 :)

假定现在你已经有了一个基本的 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 问题多由不合理数据库调用有关(这么说严谨么?),解决不合理调用要么修改应用,要么通过查询缓存或是 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 怎么办忍着。

4. 应用程序相关的调整
比较流行的开源程序,不安装第三方插件的情况下,性能多少过得去。建议如果没有必要,不要启用过多的第三方插件,尤其是一些带有统计或是「智能」显示内容之类的插件能不用就不用。

这些开源程序也基本上都有面向前端优化的静态化解决方案,比如 WordPress 的 Cache 相关的插件,强烈推荐启用。有时间看看前端优化的实践建议。

Tuning_LAMP.jpg (图片来源)
优化最重要的是找到瓶颈,对症下药。前面已经说到了内存、CPU、网络,大致提了一点 I/O 问题,基本也就够了。PHP 的 Log , MySQL 的慢查询 Log ,Apache 的 Error Log ,常过滤看一下有没有新情况。

补充一点,别忘了修改 OS 的 ulimit 限制:

编辑 /etc/security/limits.conf 增加如下两行(具体数值大点小点问题不大):

*  soft  nofile 40960
* hard nofile 40960

编辑 /etc/pam.d/common-session ,增加如下一行:

session required pam_limits.so

编辑 /etc/profile ,增加如下一行:

ulimit -SHn 40960

重新启动 OS 即可生效。

Linode 后台提供了几个基本的统计图,基本够用。可以设置磁盘 I/O 过高的时候报警,系统会发邮件给你。注意看一下网络流量的使用。不要因为个别文件被盗链而将带宽消耗殆尽。

上面提到的不少修改建议不要照葫芦画瓢,知其然,还要知其所以然。每一步的调整多阅读系统手册,尤其是涉及到具体的参数数值,一定要针对实际情况修改。对基本的配置足够掌握之后,可以根据具体情况尝试性能效率的组件,比如用 Nginx/Lighttpd 替换 Apache ,但是要记住,如果 Apache 不是瓶颈的话,用传说中性能更好的 Web 服务器来替换无疑是折腾。

再次提醒不要过度优化,足够满足需求就行了。有更多的精力完全可以放在其他环节上。另外,如果基本的调整做过之后,想用最省事的办法改善性能,那么,直接向服务商购买额外的内存吧。

好吧,最后我想说的是其实这个优化思路并不局限于 VPS ,这个最小实践套路对于复杂的服务器环境也是基本适用的。 –EOF

Tip:页面不要引用太多的三方脚本。否则也会被拖慢不少。

面向用户的网站性能优化

在互联网这个行业,”以用户为中心的设计“已经达成共识,但很少听到有人说”以用户为中心进行性能优化”之类的话,很多时候,网站性能优化是面向服务器来进行,或许,应该扭转一点思维,改到考虑如何面向用户进行网站性能优化的时候了。

优化的目的

为什么要做优化? 不外乎如下几种原因:

  • 节省资源,服务器、网络资源;
  • 消除或者减少系统瓶颈;
  • 提升用户体验

多数公司做优化都是从前两者出发,而”提升用户体验”虽然是从用户(网站访问者)角度出发,但却很少提升到非常重要的高度。

此外,或许也有炫技的因素在内,为了优化而优化,当然这是不可取的做法。

建立有效的度量

有效的优化方式前提是要能有有效的度量。一个用户访问网站,从 提交请求到得到响应,完整看到页面,中间的每个环节都应该确保优化得当。否则如果后端已经”完美”优化,单用户请求的页面有 N 多大图片,也是个糟糕的事情。在没有建立端到端的度量数据收集之前,很可能存在较大偏差。

end2end_web.png
(图Refer)

一些常见的问题是,您知道访问自己站点的用户在使用什么样的线路? 什么样的 ADSL 线路,有多少还在用拨号上网? 在网吧上网的用户有多少? 多少是移动设备用户? … 如果此类数据收集有所欠缺,也很难做出有效的性能度量。

一些优化的错误认识

服务器压力降低 = 用户访问速度快 这是最常见的一种优化态度。技术人员对自己的网站用尽了各种优化手段,服务器压力终于降低了,单用户会真的满意么? 未必。但如果从没观察过终端用户的访问习惯和网络连接方式能客观因素,也是徒劳。

前端优化不如后端优化重要 前端优化仍然没有受到应有的重视,仍有多数设计者对性能问题熟视无睹,随手弄个 1M 大小的活动页面对他们来说,图片设计是否华丽可能才最重要。对于越来越需要多媒体、富媒体表现的页面来说,前端优化其实是重中之重。两手抓,两手都要硬。用户访问费劲的页面,再华丽也是垃圾。

节省 PV = 减少 PV 以 KPI 为导向的 Web 公司中,PageView 可能是很多人的饭碗,轻易不要太岁头上动土。不过对于 KPI 制定者来说,起码要具备如何识别虚假繁荣的 PV (除非也是作弊团伙成员)。不必要的 PV 能节省就节省,节余的带宽资源留给更有价值的应用。

把优化作为项目来做 有些网站会有”起个项目对某某块做个优化”之类的事儿。优化应该是个长期、持续的事情,如果单纯的作为项目来做,可能一波热乎劲儿过去就没人管了。

–未完待续–

此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Oracle Hint: GATHER_PLAN_STATISTICS

今天 Oracle 公司 Real-World Performance Group 的 Andrew J. Holdsworth 与 Bob Carlin 来阿里作交流。尽管语言沟通上不是很顺畅,还是讨论的不亦乐乎。Andrew 过去也来过阿里巴巴作交流。

Andrew 今天提到了 GATHER_PLAN_STATISTICS ,这已经是短短一段时间第三次遇到这个 Hint 了,上次看到是在 Lewis 的 BLOG:DBMS_xplan in 10g,第二次在 Greg Rahn (也是 Real-World Performance Group 的成员)的 BLOG:Troubleshooting Bad Execution Plans ,以前或许也看到过,可能忽略了。

这个 Hint 在调查执行计划突变的时候非常有用,执行 SQL 的时候收集额外的统计数据。走投无路的时候,或许能用来救急。

另外一个以前忽略的话题是 CARDINALITY 评估错误引起的错误执行计划。事后查了一下,居然还有个 CARDINALITY hint (对,还有个 CARDINALITY Hint! )能直接指定 CARDINALITY 。

一天的讨论学到了两个知识点,已经很不错了. 这一天比较充实的.

EOF

下载 PPT : When to Use the Appropriate Database Technology,第二遍阅读的时候,发现这个 PPT 还是很好的。

这么多的 Oracle 性能工具

偶然看到 Tanel Poder 提到的一个 Metalink Note (438452.1): Performance Tools Quick Reference Guide 。这文档倒的确挺新,其中有几个工具值得关注一下。

LTOM:The Lite Onboard Monitor

Java 程序,定位是”实时诊断平台”。具有自动 Session 跟踪特性。另外具备自动 Hang 检测,自动数据收集等功能。该工具应该对于 Oracle 技能不太强的中小用户有比较大的帮助。但对于比较关键的系统,恐怕都不太放心跑一个 Java 程序在数据库上。

OPDG:Oracle Performance Diagnostic Guide

类似决策树的一个工具,访问的时候要打开个 Java 虚拟机,以我这样的网速根本访问不到(到了 22% 就停掉了) 。不知道等着着用这个工具的用户会急成什么样。

TRCANLZR:Trace Analyzer

格式化原始的 SQL Trace 数据,以 HTML 形式展现给用户。

HANGFG :Hang file generator

用以收集系统 Hang 住时的状态信息。看来,Oracle 出问题比较多的时候还是系统 Hang 啊 :)

除了这几个,还有 STACKX ,用以分析 Core 文件的内容;还有以前大家都知道的 OS Watcher ,现在也做了一些改进。这个软件包基本上是 Unix 的那些传统的性能工具加上比较有好的图表展现脚本。

应该说随着 Oracle 开发、开放更多的性能相关的工具出来,对于有一定经验的 DBA 来说,会有个很好的辅助作用。对于经验不够丰富的用户来说,不是缺少工具,而是即使有性能数据,也不知道如何分析,如何定位。

EOF
偶然发现,Metalink 对于文档的关键字也是用 Hint 的方式, 哈