GitHub 上个月宣布把所有服务器转移到 Rackspace，他们原先在 Engine Yard 使用的是云计算和虚拟机 10 VMs/39 VCPUs/54GB RAM，移到 Rackspace 后使用的物理服务器配置为 16 Servers/128 Cores/288GB RAM. GitHub 在最近的一篇博客：How We Made GitHub Fast 中分享了他们的架构和经验。

Load Balancer

GitHub 使用了一对 Xen 虚拟机（lb1a 和 lb1b）做 load balancer，运行的是 ldirectord.

前端服务器

Load balancer 把请求发给4台前端服务器中的1台，每台服务器配置为 8 cores/16GB RAM，运行 Nginx，前端（frontend）服务器分别命名 fe1, …, fe4. 在 Nginx 接受到连接请求后转发给 Unix domain socket，并由 16个 Unicorn worker 进程进行处理，其中的某个 worker 会取得请求后开始运行 rails 代码。每个前端服务器还运行4个 ProxyMachine instances，由 HAProxy 来路由。

数据库服务器

MySQL 数据库运行在2台 8 cores/32GB RAM/15000 RPM SAS drivers 的服务器上，命名为 db1a 和 db1b. 其中一台做 Master，另一台做 slave，MySQL 由 DRBD 来做 replication. GitHub 还在数据库服务器上运行 Redis 来保存一些信息。

文件服务器

目前有4对文件服务器，每台配置为 8 core/16GB RAM /6× 300GB 15000 RPM SAS drives/RAID 10，命名为 fs1a, fs1b, …, fs4a, fs4b. 任何时候每对服务器里面都有一台是 active 的，另一台在一旁等候，随时准备接手。每对服务器的数据同步也是通过 DRBD 来实现的。每个文件服务器还运行2个 Ernie RPC 服务，由 HAProxy 来路由，每个 Ernie 运行 15个 ruby works 来响应 RPC 调用。

Memcache 服务器

上面每对文件服务器里面都有1个 master (active) 和1个 slave，多数时候 slave 都很空闲，所以 GitHub 巧妙的利用了这些空闲资源，在每台 slave 文件服务器上拿出 12GB RAM 做分布式 memcache 服务器，服务器别名为 memcache1, …, memcache4.

Google 工程师 Jeff Dean 在刚过去的 LADIS 2009 Workshop 上做了一个 keynote talk：Designs, Lessons and Advice from Building Large Distributed Systems，并且透露了 Google 正在进行一个叫做 “Spanner” 的计划，设计目标是能扩展到1000万台服务器。Google 按照 Servers -> Racks -> Clusters -> Data centers 这样的顺序把服务器从机柜扩展到多个数据中心。VPSee 最近在部署 SunRay 和虚拟化，需要采购更多的服务器，基本选定就 SUN 了，因为有买一台送一台的优惠，剩下的问题就是每台服务器配置多大的处理器、内存和硬盘能充分发挥服务器的能力，达到最佳性价比，这篇 pdf 提到了每台 Google 服务器的配置，CNET 的这篇报道还提供了 Google 服务器的照片。

Google 服务器：

The Google server was 3.5 inches thick–2U, or 2 rack units, in data center parlance. It had two processors, two hard drives, and eight memory slots mounted on a motherboard built by Gigabyte. Google uses x86 processors from both AMD and Intel.

有意思的是 Google 服务器用到了电池，原因是比 UPS 要便宜的多：

“This is much cheaper than huge centralized UPS,” he said. “Therefore no wasted capacity.”

Server: DRAM: 16GB, 100ns, 20GB/s, Disk: 2TB, 10ms, 200MB/s
Rack (80 servers): DRAM: 1TB, 300us, 100MB/s, Disk: 160TB, 11ms, 100MB/s
Clusters (30+ racks): DRAM: 30TB, 500us, 10MB/s, Disk: 4.80PB, 12ms, 10MB/s

一些经验和数据：

1-5% of your disk drives will die
Servers will crash at least twice (2-4% failure rate)

一些每个人都应该知道的数据：

L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns
Mutex lock/unlock 25 ns
Main memory reference 100 ns
Compress 1K bytes with Zippy 3,000 ns
Send 2K bytes over 1 Gbps network 20,000 ns
Read 1 MB sequentially from memory 250,000 ns
Round trip within same datacenter 500,000 ns
Disk seek 10,000,000 ns
Read 1 MB sequentially from disk 20,000,000 ns
Send packet CA->Netherlands->CA 150,000,000 ns

一个新 cluster 通常第一年会发生的事情：

~0.5 overheating (power down most machines in <5 mins, ~1-2 days to recover) ~1 PDU failure (~500-1000 machines suddenly disappear, ~6 hours to come back) ~1 rack-move (plenty of warning, ~500-1000 machines powered down, ~6 hours) ~1 network rewiring (rolling ~5% of machines down over 2-day span) ~20 rack failures (40-80 machines instantly disappear, 1-6 hours to get back) ~5 racks go wonky (40-80 machines see 50% packetloss) ~8 network maintenances (4 might cause ~30-minute random connectivity losses) ~12 router reloads (takes out DNS and external vips for a couple minutes) ~3 router failures (have to immediately pull traffic for an hour) ~dozens of minor 30-second blips for dns ~1000 individual machine failures ~thousands of hard drive failures slow disks, bad memory, misconfigured machines, flaky machines, etc.

上个星期订购的硬盘到了，8个 Seagate 500GB SATA 2 硬盘用来升级几台 SUN 服务器，替换上面的几个 250GB 老硬盘。VPSee 一直在服务器上用的是 RAID 10 和 RAID 5，传说中 RAID 0 的 IO 性能有很大提高，VPSee 对 RAID 0 的 IO 性能向往已久，今天刚好有多余的硬盘，可以测试一下。理论上来说，RAID 0 实现了一个线性的磁盘阵列，数据被切分成块（blocks）后分别写入各自硬盘，分散了 IO 负载，IO 性能会有很大提高，如果磁盘阵列里的每个磁盘控制器都只对应一个硬盘，充分分散 IO，那么 IO 性能应该更好。今天的测试结果发现不管是硬件 RAID 0 还是软件 RAID 0 性能都很差，差得自己都不能解释，理论上双硬盘 RAID 0 的性能应该是无 RAID 0的2倍，VPSee 的实际测试数据结果刚好相反，无 RAID 0 的性能是有 RAID 0 的2倍。测试结果还显示硬件 RAID 和 软件 RAID 性能接近，这一点很好解释，测试用的是 SunFire X2100 M2 服务器，上面自带的是 Nvidia RAID，被称为 “FakeRAID”，FakeRAID 其实也是一种软件实现，和 Software RAID 一样都会消耗 CPU，其性能和 Software RAID 相似不奇怪。

10月15日更新：10月13日测试结果显示不带 RAID 0 的性能比带 RAID 0 的还好得多，原因查明是因为其中的一个硬盘有问题，没料到没拆封的新硬盘居然还会有故障，导致先前的测试环境不公平，测试的结果无法合理解释。换了硬盘重新测试硬件 RAID 0，新的测试结果显示 RAID 0 的 IO 性能有较大提高，与理论相符；软件 RAID 1 用 CPU 模拟 RAID 功能，导致系统负载（load average）保持较高状态，和理论相符。（下面的数据已经更新）

双硬盘 + 普通挂载

无 RAID 0 测试也是设置的两块硬盘，一个硬盘用来装系统，另外一个硬盘挂上去。分别用 hdparm，bonnie++，iozone 测试：

# /sbin/hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads:   4076 MB in  2.00 seconds = 2036.86 MB/sec
 Timing buffered disk reads:  162 MB in  3.00 seconds =  53.97 MB/sec

# ./bonnie++
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine  Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
bang       4G 63786  98 68561  64 33488  16 35061  80 100811  19 232.2   0
              ------Sequential Create------ --------Random Create--------
              -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
        files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
           16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
bang,4G,63786,98,68561,64,33488,16,35061,80,100811,19,232.2,0,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++

# ./iozone -s 100M
                                                  random  random    bkwd   record   stride                                   
    KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
102400       4  340155  508979   586930   599212  566258  520126  534720   590170   563886   320739   433341  528295   520245

双硬盘 + 硬件 RAID 0（FakeRaid）

分别用 hdparm，bonnie++，iozone 测试：

# /sbin/hdparm -tT /dev/mapper/nvidia_igcjceec3
/dev/mapper/nvidia_igcjceec3:
 Timing cached reads:   1766 MB in  2.00 seconds = 883.57 MB/sec
 Timing buffered disk reads:  374 MB in  3.01 seconds = 124.24 MB/sec

# ./bonnie++
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine  Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
bang       4G 58566  92 116851  66 50132  30 27333  86 149623  35 364.4   1
              ------Sequential Create------ --------Random Create--------
              -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
        files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
           16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
bang,4G,58566,92,116851,66,50132,30,27333,86,149623,35,364.4,1,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++

# ./iozone -s 100M
                                                  random  random    bkwd   record   stride                                   
    KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
102400       4  149748  507946   937291   798155  792109  399647  852672   524171   802494   254962  1249892 1514190  1291883

双硬盘 + 软件 RAID 1（Software RAID）

分别用 hdparm，bonnie++，iozone 测试，系统负载 load average 居高不下：

# /sbin/hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   2236 MB in  2.00 seconds = 1118.92 MB/sec
 Timing buffered disk reads:   86 MB in  3.05 seconds =  28.19 MB/sec

# ./bonnie++
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine  Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
bang       16G  4735  10  4831   2  4117   1 18128  50 48536   7 344.5   1
               ------Sequential Create------ --------Random Create--------
               -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
        files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
           16 17649  47 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
bang,16G,4735,10,4831,2,4117,1,18128,50,48536,7,344.5,1,16,17649,47,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++

# ./iozone -s 100M
                                                  random  random    bkwd   record   stride                                   
    KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
102400       4  285771  558272   910466  1622948 1803419  919134 1026424  1561120  1785501   327527   768025 1131377  1174904

关于 Craigslist 的介绍以及一些访问量多大、负载多强大的数据就省略了，VPSee 关心的是背后的技术架构，主要参考文章：MySQL and Sphinx at Craigslist 和 Database War Stories #5: craigslist.

架构

硬件环境： Supermicro 4U 7043-P8、Dual Intel Xeon 3.2 512KB CPU、16GB 内存、16个硬盘组成的 Raid 10；
软件系统： Suse Linux 操作系统，网站大部分用 Perl 编写，使用标准的 LAMP 组合，memcached 做缓存，使用 Sphinx 全文搜索。

数据库

所有数据库服务器都运行 64 位的 Linux，每个服务器有 16GB 内存和16个硬盘。几台数据库服务器组成一个 db cluster，每个 db cluster 运行一个 Craigslist 服务。

forums：1个 master + 1个 slave，slave 主要用来备份，表使用 myIsam 引擎，DataDir 大小达到 17GB（包括索引在内），最大一个表有近4200万行。

classifeds：1个 master + 12个 slaves，多种不同用途的 slaves，其中 teamreader, longreader, thrashbox 用来备份以及一些非常耗时的特殊查询。还有1个离线 slave 以应付突发情况，比如 colo 崩溃了。其中数据库容积达到 114G（包括索引），最大一个表达到5600万条记录，数据表也是使用 myIsam 引擎。

archivedb：1个 master + 1个 slave，用来归档那些时间超过3个月的帖子，除了比上面的 classifeds 存的数据量大以外，其结构非常类似 classifeds，238G 的数据，9600万条记录。不同的是数据表使用的是 mrg_mylsam，MySQL 的 merge 引擎，方便把 archive 上分散的数据 merge 成更容易管理的块。这也是 merge 表的好处，这里一张表，那里一张表不方便管理，合成一张表更容易管理一些，不过 merge 引擎要求相似的表才能 merge，不是随便什么表都可以 merge 的。

searchdbs：4个 clusters（16台服务器），把 live 的帖子按照 area/category 切分，每个 cluster 只包含 一部分的 live 帖子，使用 myIsam 全文索引。不过要注意的是，全文索引（Indexing）很耗资源，很烧钱。

authdb：1个 master + 1个 slave，这个最小了，只是存一些临时、短暂的数据（transient data）。

MySQL 似乎在 64 位的机器上运行得更好一些。

全文搜索

Craigslist 刚开始使用了 MySQL 全文搜索（Full text indexing and searching），随着规模变大，MySQL 全文搜索逐渐不能应付要求，不能 scale，改用 Sphinx 做搜索，一段时间后发现 Sphinx 也不能满足需求，不能 scale，最后不得不 patch sphinx 以满足日益增长的庞大数据库和搜索需求。Craigslist 的经验是，在一张很大的表上做全文索引和搜索是行不通的，因为用户没有耐心去等待漫长的搜索过程，搜索结果往往不能在用户期望的时间内返回。

看多了超大规模高性能、超大数据库架构，有必要回到现实看看中等规模网站是如何架构的，毕竟不是每个网站、web app 都有机会做成 Google/Yahoo/Facebook/Amazon 那样。Ravelry 是一家用 Ruby on Rails 搭建的社区网站，学习一下 Ravelry 的 Rails 架构经验。

数据

数据和资料来源（2009）：Ravelry

43万注册用户
每个月约20万用户上线，每天约7万用户登录
每天约360万 PV（只包括注册用户，不包括其他途径访问），实际 PV 大概1000万每天
每天约900新用户注册
论坛每天发布约5万个新帖
网站有230万个项目、190万个帖子、130万条消息、800万张图片（大部分保存在 Flickr）
包括创始人在内公司一共才3.5个人（其中一个是 part time）

技术架构

Ravelry 使用了以下一些 Open Source 项目和技术：

Gentoo Linux
MySQL
Ruby Enterprise Edition
Memcached
Nginx/HAProxy/Apache + mod_passenger
Tokyo Cabinet/Tyrant
Sphinx
Xen
Munin/Nagios/Syslog-ng
Amazon S3/Cloudfront

Ravelry 刚开始运行在一个 VPS 上，随着网站规模的变大逐渐转向自己的硬件，服务器是从 Silicon Mechanics 购买的，托管在 Hosted Solutions 和 Cogent。Ravelry 使用 Amazon S3 做存储，Amazon CloudFront 做 CDN。

Ravelry 目前总共有7台物理服务器，Xen 虚拟化后成13台，使用 Gentoo Linux 操作系统。其中：

• 1台用来备份，1台用来测试；
• 1台用来做 master 数据库服务器，1台做 slave 数据库服务器 + Sphinx 搜索引擎；
• 另外3台用来做应用服务器，运行 Passenger，Ruby Enterprise Edition 和 Memcached。使用 Passenger 和 Ruby GC patches 节省了大量内存。

前端服务的架构大概像这样：nginx -> haproxy -> apache + mod_passenger，Ravelry 的创始人 Casey 提到他们主要的 scaling/tuning/performance 方面的工作还是集中在数据库部分。

Ravelry 使用 Capistrano 来快速部署新版本的网站程序，使用 Munin 来监测服务器资源、Nagios 来警告、Syslog-ng 来做日志，使用 Memcached 来缓存数据库对象，部分需要缓存 larger object 的地方用到了 Tokyo Cabinet/Tyrant。Ravelry 几乎把站内所有的用到 Markdown 标记语法的页面都缓存成了普通的 HTML。

Ravelry 在开始上线的头几个月几乎每天都会修正 bug、推出新版本，得益于 Ruby 的快速开和 prototype 的能力。Casey 说，Ruby is fun! Fun is important.

Fotolog 是一个以图片为主的 SNS 网站，让 VPSee 好奇的是用 Solaris 的 Web 2.0 站点不多，看看 Fotolog 有没有什么新东西。

数据

数据和图片来源（2007）：Fotolog: Scaling the World’s Largest Photo Blogging Community

超过1100万用户
超过24亿条评论
每个月超过35亿 PV 和 2000万独立访问，Alexa Top 20
总共有超过2亿张的图片，每天还有超过50万张照片上传
20%用户每天在 Fotolog 停留 24分钟
32台 MySQL 服务器和一个由30台 memcached 服务器组成的集群

技术平台

Solaris 10
MySQL
Apache
Java / Hibernate
PHP
Memcached
3PAR
IBRIX
CDN

MySQL

32台 MySQL 服务器被分成4个集群：User, GB (guest book), PH (photos), FF (friends and favorites lists)。每个集群又被分成一个 shard 集，并由一个应用服务器集做前端。每个 shard 集包括若干个 MySQL 服务器，一个只写的 Master-Master 配几个只读的 Slaves，应用服务器把读请求发给 Slaves，把写请求发给 Master。MySQL 只存储图像的 metadata，没人想要把图像存到数据库里吧？什么是 metadata？metadata 是 “data about other data”，如一张照片的 metadata 就是一些包括：作者，年份，照片说明，摄影设备等信息就是这张照片的 metadata。

继续阅读 »

Database Sharding@Netlog 详细的描述了 Netlog 数据库架构的演变过程，文章浅显易懂，非常值得学习。本文数据、图片均来自：Database Sharding at Netlog, with MySQL and PHP

数据

约4000万活跃用户
每月约5000万独立访问
每月约50亿 PV 和 每月 60亿 online minutes
在数据库 sharding 以前，高峰时期每秒3000次以上数据库查询
26种语言，30多个国家，5个最活跃的国家主要集中在欧洲

技术平台

Squid
Lighttpd, Apache
PHP
MySQL
Debian
Memcached
Sphinx
and many more.

Netlog 数据库架构的历史

netlog 从7年前的一个 hobby project 发展而来，数据库从单台服务器扩展到树型多台服务器。

继续阅读 »

37signals 是除了 Twitter 以外的又一个高流量 Ruby on Rails 架构的示例。

数据

数据来源（2007）：Ask 37signals: Numbers?

约30台服务器组成的 cluster，从 1 CPU 的文件服务器到 8 CPU 的应用服务器，加起来大慨 100 CPUs 和 200GB 内存（正计划把服务器数量减到16台，92 CPUs 和 230GB 内存，性能更高，架构更简单更易管理）。
客户总共上传约 5.9TB 的数据

Stack

以下是 37signals 用到的一些 stack：

Apache
HAProxy
Ruby on Rails
Mongrel
Memcached
MySQL
Xen
Amazon S3

值得注意的是用到了 Xen 虚拟技术和 Amazon S3 云存储。Memcached 现在已是高访问量网站的标准配置了，就不介绍了。有意思的是，DHH 在 Interview with David Heinemeier Hansson 提到，随着技术的发展，硬件越来越便宜，如果能用硬件解决问题就尽量用硬件，除非绝对必要，否则 shard 数据库来分载流量很痛苦。所以 37signals 不太赞成随便 shard，他们现在的主程序就跑在1台 128GB 的主服务器上，然后有多个备份服务器支持，主服务器不久会扩充到 256GB。VPSee 推测他们的 load balancing 是 Xen 之间的 load balancing，不是物理服务器之间的分载。

继续阅读 »

Wikipedia.org 是个标准的运行在 LAMP 上的高流量网站，看看能从 Brion Vibber （CTO, Wikimedia Founation）的这篇讲义：Scaling and Managing LAMP at Wikimedia 学到些什么。（图片资源来自：Scaling and Managing LAMP at Wikimedia）

数据

每个月100亿 PV
高峰时后每秒达 50000 http requests
约400台 x86 服务器，约250台是 Web Server，剩下的基本上是 MySQL Server
只有7个工程师维护
每个月35000美元的带宽和 hosting 费用

LAMP

Wikipedia 是架在标准 LAMP 上的一个非常好的示例，以下是 Wikipedia.org 用到的一些 stack：

多个不同版本的 Linux，Ubuntu，Debian 等
Apache
PHP
MySQL

Cache

缓存就不用说了，从前端的 web cache，中间的 opcode cache，到后端的 database cache 都需要。Wikipedia 用 Squid + APC + memcached 来完成 cache 工作。Squid 对 wiki 这种内容为主，不经常变化的相对静态的 web 应用很有效。Wikipedia 还用 Squid 做 geographic load balancing，根据不同地理位置访问各地的服务器。只要用到 PHP　的地方就应该用到 opcode cache，Wikipedia.org 选择了 APC，good choice!，VPSee.com 也用 APC：）。memcached 用来缓存数据库的临时 object，不用反复从数据库读取，而且 memcached 可以做成缓存服务器供网上 share object，其他的服务器可以直接读取，比起从磁盘重新读取数据库，网络读取的延迟要小多了。现在大家都用 cache，送礼就送 cache（cash？）！

继续阅读 »

PHP 是一个解释型语言，每当浏览器请求服务器上一个 PHP 页面的时候，这个 PHP 页面都要在服务器上载入，分析，解释，然后返回给浏览器。对于一个复杂的 PHP 应用程序，如果有一个加速器能缓存 PHP 的中间代码避免每次重新载入同样的 PHP 页面将会很好的提高性能，因为每次浏览器请求将会直接从服务器缓存中读取已被解释过页面，不必再让服务器从磁盘重新读取，节约了磁盘 IO 的时间，也节约了CPU 解释页面的时间。所以对于复杂的 PHP 应用，会有大幅的性能提升。

像这样的加速器有很多，最出名的几个 PHP 开源加速器是：APC，eAccelerator 和 XCache。这里介绍安装和配置 APC。对于 64/128MB 的 VPS，VPSee 不推荐使用加速器，原因很简单，加速器需要适量的内存才能表现出良好的性能，64MB 运行一个 WordPress 刚刚好，还腾不出内存出来运行加速器。

安装必要软件包

# yum install gcc make
# yum install pcre pcre-devel
# yum install php-pear
# yum install php-devel
# yum install httpd-devel

安装 APC

# pecl install apc 

配置 APC

新建一个 apc.ini，加入下面配置：

# vi /etc/php.d/apc.ini
extension = apc.so
apc.enabled = 1
apc.shm_size = 32
apc.include_once_override = 1
apc.mmap_file_mask = /tmp/apc.XXXXXX

载入 APC

如果用的是 Apache 的话就重新启动 Apache，如果用 Nginx/FastCGI 就重启 FastCGI

# /etc/init.d/httpd start

测试

如果想看 APC 正在干嘛，就把 apc.php 拷贝到你的 web 目录，用浏览器访问 apc.php，就可以看到很清楚的数据和图表。先查找 apc.php 在哪，如果 locate 报错就先 updatedb 再 locate，最后打开浏览器访问 http://www.vpsee.com/apc.php 看效果。

# locate apc
locate: can not open `/var/lib/mlocate/mlocate.db': No such file or directory

# updatedb

# locate apc.php
/usr/share/pear/apc.php

# cp /usr/share/pear/apc.php /home/www/vpsee.com