最近的 NOSQL meetup 又把SQL数据库的 scale 问题抛出来了。NoSQL guys 对 SQL 不满的主要原因是：SQL 数据库不能很好的 scale。我们可以通过 caching，用 master-slave 分担负载，给数据库横向/纵向分区等技术来减轻 SQL 数据库的负担，但是还不能真正做到 scale。目前最好的方法还是修改应用程序的代码把数据库分散存储在不同的数据库服务器上。随着 Web 应用的规模越来越庞大，这些方法始终没有解决 SQL 数据库 scale 的根本问题。Google/Amazon/Yahoo/Facebook 等都陆续自立门户，纷纷推出了自己超大规模 scale 的数据存储方案，这些方案用来处理海量数据，已经不能叫它们传统的数据库了，更像是分布式键值/文件存储系统。

什么是 scale

什么才算是真正的 scale？

How well a solution to some problem will work when the size of the problem increases, when the size decreases the solution must fit.

我对 scale 的理解是至少要满足下面三个条件：

1、扩展伸缩。加入一个新的数据库服务器后，原先的数据库的容量就扩大，性能也能增大。能立刻自动的把数据部署到新的数据库服务器上，不需要应用程序干预。拿掉一个服务器后，反过来也一样。

2、应用程序透明。对应用程序来说应该是透明的，应用程序不关心也不应该知道数据存储是怎么存储的，存储在哪个服务器上。

3、自动接管/自愈。一台服务器坏了或者 down 了不丢失数据，不影响其他数据库服务器和整个数据库的运行。

一个好例子就是RAID5：

继续阅读 »

对于一个每日 PV 不超过1万的小博客来说，性能不是问题，一般的 VPS 都可以搞定，稳定性远比性能要重要。服务器 down 掉，会导致博客不能访问，不能更新，长时间 down 的话会失去读者，影响自己的写作计划/情绪，影响pagerank等等。前段时间 Hyperv 报漏洞，导致 FsckVPS 的很多客户丢失重要数据，长时间都不能恢复。小博客/网站的性能不是那么重要，每天没有那么多的访问压力。

为了给博客增加可靠性，给博客做个简单镜像是必要的，幸运的是我们的要求不高，不需要那些什么实时热备份，均衡负载，透明切换等高科技，只需要每隔一段时间同步一下博客以及数据库就可以了，很少有人能坚持每天写一篇博客，能每天写两篇就算牛博了，所以每天同步一次就够了。这里将讨论如何用 rsyn，ssh 和 mysqldump 来同步博客和数据库。

约定

为了更好的描述细节，这里作以下约定：

继续阅读 »

现在流行的 web 服务器里面都提供 sendfile 选项用来提高服务器性能，那到底 sendfile 是什么，怎么影响性能的呢？sendfile 实际上是 Linux 2.0+ 以后的推出的一个系统调用，web 服务器可以通过调整自身的配置来决定是否利用 sendfile 这个系统调用。先来看一下不用 sendfile 的传统网络传输过程：

read(file, tmp_buf, len);
write(socket, tmp_buf, len);

硬盘 >> kernel buffer >> user buffer >> kernel socket buffer >> 协议栈

一般来说一个网络应用是通过读硬盘数据，然后写数据到 socket 来完成网络传输的。上面2行用代码解释了这一点，不过上面2行简单的代码掩盖了底层的很多操作。来看看底层是怎么执行上面2行代码的：

1、系统调用 read() 产生一个上下文切换：从 user mode 切换到 kernel mode，然后 DMA 执行拷贝，把文件数据从硬盘读到一个 kernel buffer 里。
2、数据从 kernel buffer 拷贝到 user buffer，然后系统调用 read() 返回，这时又产生一个上下文切换：从kernel mode 切换到 user mode。
3、系统调用 write() 产生一个上下文切换：从 user mode 切换到 kernel mode，然后把步骤2读到 user buffer 的数据拷贝到 kernel buffer（数据第2次拷贝到 kernel buffer），不过这次是个不同的 kernel buffer，这个 buffer 和 socket 相关联。
4、系统调用 write() 返回，产生一个上下文切换：从 kernel mode 切换到 user mode（第4次切换了），然后 DMA 从 kernel buffer 拷贝数据到协议栈（第4次拷贝了）。

上面4个步骤有4次上下文切换，有4次拷贝，我们发现如果能减少切换次数和拷贝次数将会有效提升性能。在kernel 2.0+ 版本中，系统调用 sendfile() 就是用来简化上面步骤提升性能的。sendfile() 不但能减少切换次数而且还能减少拷贝次数。

再来看一下用 sendfile() 来进行网络传输的过程：

继续阅读 »

为了加快网站访问速度，除了可以优化后端数据库，cache，操作系统，web 服务器，重新设计架构以外，优化前端页面性能也很重要。

建议

Yahoo 的性能小组经过长期的研究总结出了几条让网站访问更快的实战经验：Best Practices for Speeding Up Your Web Site。High Performance Web Sites 和 YSlow 的作者 Steve Souders 在其教授的 Stanford CS193H 课程里谈到了这14条建议：

Make fewer HTTP requests
Use a CDN
Add an Expires header
Gzip components
Put stylesheets at the top
Put scripts at the bottom
Avoid CSS expressions
Make JS and CSS external
Reduce DNS lookups
Minify JS
Avoid redirects
Remove duplicate scripts
Configure ETags
Make AJAX cacheable

随后 Steve Souders 在其新书 Even Faster Web Sites 谈到了更多建议：

继续阅读 »

有个学生在 WebHostingTalk 上发帖请教 VPSLink 的 64MB VPS 是否撑得住18个静态网站的托管，后面有很多所谓的 ”专家“ 跟帖：

I do not believe you can host 18 websites on 64MB of RAM. I’d bump that up to at least 128 or 256.

I’d suggest 256 MB minimum. 128 MB might suffice if you really know what your doing (for memory optimization) but you may encounter problems getting things installed without burst memory or swap.

I really wouldn’t advise anything lower than 265MB RAM for website hosting. Seriously, even if you do use LXAdmin with Lighttpd and any other optimization, it’ll still not be enough.

所谓的 ”专家“ 都不相信 64MB 的 VPS 能应付那个学生的要求。那到底 64MB VPS 能不能用来托管18个静态网站呢？18个网站听上去好像很多，其实可以看作是一个网站只不过多了一些 HTML 页面而已。那个学生的问题要看具体网站访问量来定，不过就一般的静态网站来说，64MB 的 VPS 绰绰有余。lowendbox.com 写了一篇文章 “Yes, You can Run 18 Static Sites on a 64MB Link-1 VPS” 来反驳 “专家”。VPSee 完全站在 lowendbox 这一边，并且 VPSee.com 可以证明 64MB VPS 足够支持一个每天 700PV 左右的 WordPress 博客，VPSee 估计每天 1000PV 左右也是可以扛得住的。

为了证明 64MB 的 VPS 可以干很多事，VPSee 注册了一个 VPSLink 的 64MB VPS，详细看这里：VPSLink 试用），然后把自己另外一个 PV 在700左右的博客搬了过去，经过下面一番优化之后：

继续阅读 »

MySQL 是一个很棒的 open source 数据库引擎，大部分的网站和博客都是由 MySQL 驱动的。MySQL 的默认安装占用的内存资源比较大（相对于一个只有 64MB 的 VPS来说），优化 MySQL 可以减少内存消耗，把更多的内存省下来留给其他程序。

MySQL 的配置文件在 /etc/mysql/my.cnf（Debian 5），为了方便调整配置，MySQL 为小资源系统提供了一个叫做 my-small.cnf 的配置文件，是给小于 32MB 内存的服务器设置的。我们可以在这个配置文件的基础上作小部分的调整。

先找到 /usr/share/doc/mysql-server-5.0/examples/my-small.cnf，然后覆盖 /etc/mysql/my.cnf（Debian）。如果是 CentOS 5 的话，路径是：/usr/share/doc/mysql-server-5.0.45/my-small.cnf，覆盖 /etc/my.cnf。

参数说明

如果不使用 BDB table 和 InnoDB table 的话，加入下面2行关闭不需要的表类型很有必要，关闭 innodb 可以省下大量内存，虽然 InnoDB 好处多多但是在一个64MB的 VPS 上并不能体现出来，并且很占内存。

skip-bdb
skip-innodb

继续阅读 »

Nginx 小巧，高效，稳定等优点非常适合配置不高，内存小的 VPS。这里的优化策略不是让nginx每秒能处理更多的请求，那是一个繁忙网站要做的。记住，这是一个只有 64MB 的 VPS，对于架设一个访问量不大的网站/博客来说，尽可能减少 Nginx 的内存占用率是最重要的，用尽量小的 Nginx 占用内存去满足不大的访问量。

优化 nginx.conf

Nginx 运行的进程数，一般设置成和 CPU 的核数相同。

worker_processes  1;

使用 epoll，Linux 内核2.6版本以上支持 epoll（eventport支持 Soaris，kqueue 支持 BSD系列），worker_connections 每个 Nginx 进程所允许的最大的连接数，max_clients = worker_processes * worker_connections。

 events { 
    use epoll;
    worker_connections  128;
 } 

设置连接的超时时间。

keepalive_timeout  5;

继续阅读 »

PHP 默认会有很多扩展模块自动启动，这里优化 PHP 的主要思路就是禁止那些用不着的模块去节省内存资源。

提高安全

一般来说，通过隐藏版本等信息来提高安全性的方法不是很管用。但在有些情况下，尽可能的多增加一点安全性是值得的。在 php.ini 文件里设置 expose_php = off 可以帮助隐藏 PHP 信息，这样就增加了一点点攻击者发现系统漏洞的难度。

expose_php = Off

提高性能

register_globals 既关系到安全问题也关系到性能问题，register_globals = On 的话容易导致变量滥用，给攻击者控制判断变量。不过现在的 PHP 版本都把这个参数默认设置为 Off。

register_globals = Off

继续阅读 »

前几天看到 VPSLink 在打折就跑去注册了一个 64M VPS，（具体请看：VPS 主机试用：VPSLink），想看看 64MB 的 VPS 能不能跑一个小规模访问量的 WordPress 博客，这里的小规模是指每日500 PV 以下。然后分别试着跑了一下 Debian 和 CentOS，默认安装后跑Debian没有问题，但是运行 CentOS 时明显感到系统很慢。CentOS/RHEL 官方推荐的最小配置(不带图形界面)虽然是 64MB 内存，但是考虑到同时要跑 MySQL，PHP，Wordpress 等程序 64MB CentOS就有点吃力了。还有一个考虑就是运行一次 yum 需要比 apt-get 多得多的内存资源。所以按照我的 VPS 配置，64MB内存，128MB 交换，2.5GB 的硬盘，就只能选 Debian 了。

Debian 是一个古老，严谨，自由而且流行的 Linux 发行版，有 n 多的软件包可以用，有很好的稳定性和安全性，是各大 Linux hosting 服务商的主流系统之一，几乎所有 Linux VPS 都支持 Debian 版本。安装 Debian 的系统最低内存要求是 64MB，但是官方文档也说了真正的最低内存配置要比 64MB 低一些，根据不同的硬件体系安装在只有 48MB 的 i386 上也是可能的。

查看 VPS 配置

1、查看以下 VPS 的硬件信息，做到心中有数

# free
# cat /proc/cpuinfo

继续阅读 »

当你在网上寻找一个便宜的低端 Linux VPS 的时候，通常考虑的重要指标是，价格（非常重要！ ） ，访问速度（低延迟的 SSH 访问，包括用户访问的速度），虚拟技术（ Xen 还是 OpenVZ？），稳定性（你不想你的网站每个月 down 很多次吧？），等等。许多VPS服务商都提供32位或64位的 VPS，不过我们不是很在意 VPS 主机是32位还是64位的。 先大致比较一下64位系统的优缺点吧，

优点：
可以访问超过 2GB 的超大内存地址空间，相比32位系统只能访问 2GB 的内存地址；
性能提升，因为 CPU 有16个一般用途的寄存器，相比32位系统只有8个；
通过使用优化的 x64-64 CPU 指令，性能得到提升。

缺点：
根据报告称同一应用程序64位比32位多消耗至少有60%以上的内存；
性能损失，因为64位是8字节，相比32位系统只有4字节。

更大的不一定是更好的。对于同一个程序来说，运行它的64位的版本比它的32位版本需要更多的内存，这意味着需要支付更多的成本。对于一个小网站或者博客来说32位的VPS已经足够了，我们不需要那些用不着的大内存地址空间，我们也不需要访问超大的数据库。

最近在 VPSLink 上注册了一个64M VPS，分别装了一次32位的 Ubuntu 和64位的 Ubuntu，安装完 php+mysql+nginx 后发现32位系统确实比64位节省更多的内存。32 or 64 Bit for Your VPS? 的作者也有同样的感受，除非你对64位有特别的需求，否则还是推荐低廉、快速而且有效的32位系统。