问题:在linux上面用架设了PPTP VPN，但连上以后大部分网站访问速度极慢，几乎无法访问。
解决:修改MSS值
iptables -A FORWARD -p tcp --syn -s XXX.XXX.XXX.XXX/XX -j TCPMSS --set-mss 1372

原因分析:
1.断开vpn的情况下：
ping -f -l XXXX www.baidu.com

一步一步测试（XXXX为MTU大小，可以从1500开始，逐渐减小，直到可以ping通）
我们可以得到可以ping通的MTU最大为1472；

2.连接vpn的情况下：

ping -f -l XXXX www.baidu.com

一步一步测试（XXXX为MTU大小，可以从1500开始，逐渐减小，直到可以ping通）
我们可以得到可以ping通的MTU最大为1372；

3.连接vpn，在服务器上用
netstat -i
查看接口，得到

Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 2850923 0 0 0 2675804 0 0 0 BMRU
lo 16436 0 36427 0 0 0 36427 0 0 0 LRU
ppp0 1396 0 177 0 0 0 96 0 0 0 MOPRU

可知ppp的最大mtu为1396，当然，对应的mss应为（mtu-20字节的IP头部-20字节的TCP 头部=)1356

1.Linux链接概念
Linux链接分两种，一种被称为硬链接（Hard Link），另一种被称为符号链接（Symbolic Link）。默认情况下，ln命令产生硬链接。

【硬连接】
硬连接指通过索引节点来进行连接。在Linux的文件系统中，保存在磁盘分区中的文件不管是什么类型都给它分配一个编号，称为索引节点号(Inode Index)。在Linux中，多个文件名指向同一索引节点是存在的。一般这种连接就是硬连接。硬连接的作用是允许一个文件拥有多个有效路径名，这样用户就可以建立硬连接到重要文件，以防止“误删”的功能。其原因如上所述，因为对应该目录的索引节点有一个以上的连接。只删除一个连接并不影响索引节点本身和其它的连接，只有当最后一个连接被删除后，文件的数据块及目录的连接才会被释放。也就是说，文件真正删除的条件是与之相关的所有硬连接文件均被删除。

【软连接】
另外一种连接称之为符号连接（Symbolic Link），也叫软连接。软链接文件有类似于Windows的快捷方式。它实际上是一个特殊的文件。在符号连接中，文件实际上是一个文本文件，其中包含的有另一文件的位置信息。

2.通过实验加深理解
[oracle@Linux]$ touch f1 #创建一个测试文件f1
[oracle@Linux]$ ln f1 f2 #创建f1的一个硬连接文件f2
[oracle@Linux]$ ln -s f1 f3 #创建f1的一个符号连接文件f3
[oracle@Linux]$ ls -li # -i参数显示文件的inode节点信息
total 0
9797648 -rw-r--r-- 2 oracle oinstall 0 Apr 21 08:11 f1
9797648 -rw-r--r-- 2 oracle oinstall 0 Apr 21 08:11 f2
9797649 lrwxrwxrwx 1 oracle oinstall 2 Apr 21 08:11 f3 -> f1

从上面的结果中可以看出，硬连接文件f2与原文件f1的inode节点相同，均为9797648，然而符号连接文件的inode节点不同。

[oracle@Linux]$ echo "I am f1 file" >>f1
[oracle@Linux]$ cat f1
I am f1 file
[oracle@Linux]$ cat f2
I am f1 file
[oracle@Linux]$ cat f3
I am f1 file
[oracle@Linux]$ rm -f f1
[oracle@Linux]$ cat f2
I am f1 file
[oracle@Linux]$ cat f3
cat: f3: No such file or directory

通过上面的测试可以看出：当删除原始文件f1后，硬连接f2不受影响，但是符号连接f1文件无效

3.总结
依此您可以做一些相关的测试，可以得到以下全部结论：
1).删除符号连接f3,对f1,f2无影响；
2).删除硬连接f2，对f1,f3也无影响；
3).删除原文件f1，对硬连接f2没有影响，导致符号连接f3失效；
4).同时删除原文件f1,硬连接f2，整个文件会真正的被删除。

本文转载自:http://itech.cnblogs.com/

今天闲来无事，用自己的VPS作为测试平台，测试Xcache3.0和eAccelerator1.0哪个性能更好.第一次做这种事情，做得不够专业请指正，呵呵.

不使用eAccelerator1.0和Xcache3.0,测试结果:

Server Software: nginx/1.2.6
Server Hostname: ***.***.***
Server Port: 80

Document Path: /phpwind/
Document Length: 10903 bytes

Concurrency Level: 10
Time taken for tests: 283.546 seconds
Complete requests: 5000
Failed requests: 0
Write errors: 0
Total transferred: 57323498 bytes
HTML transferred: 54515000 bytes
Requests per second: 17.63 [#/sec] (mean)
Time per request: 567.091 [ms] (mean)
Time per request: 56.709 [ms] (mean, across all concurrent requests)
Transfer rate: 197.43 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 3
Processing: 308 567 31.1 564 699
Waiting: 300 517 29.1 515 642
Total: 308 567 31.1 564 699

Percentage of the requests served within a certain time (ms)
50% 564
66% 577
75% 585
80% 590
90% 607
95% 621
98% 638
99% 650
100% 699 (longest request)

只使用eAccelerator1.0,测试结果:

Server Software: nginx/1.2.6
Server Hostname: ***.***.***
Server Port: 80

Document Path: /phpwind/
Document Length: 10903 bytes

Concurrency Level: 10
Time taken for tests: 247.201 seconds
Complete requests: 5000
Failed requests: 0
Write errors: 0
Total transferred: 57323978 bytes
HTML transferred: 54515000 bytes
Requests per second: 20.23 [#/sec] (mean)
Time per request: 494.402 [ms] (mean)
Time per request: 49.440 [ms] (mean, across all concurrent requests)
Transfer rate: 226.46 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 4
Processing: 319 494 35.7 491 688
Waiting: 312 454 34.4 451 639
Total: 319 494 35.7 491 688

Percentage of the requests served within a certain time (ms)
50% 491
66% 505
75% 514
80% 520
90% 541
95% 559
98% 582
99% 598
100% 688 (longest request)

只使用Xcache3.0,测试结果:

Server Software: nginx/1.2.6
Server Hostname: ***.***.***
Server Port: 80

Document Path: /phpwind/
Document Length: 10903 bytes

Concurrency Level: 10
Time taken for tests: 1560.616 seconds
Complete requests: 5000
Failed requests: 0
Write errors: 0
Total transferred: 57323430 bytes
HTML transferred: 54515000 bytes
Requests per second: 3.20 [#/sec] (mean)
Time per request: 3121.232 [ms] (mean)
Time per request: 312.123 [ms] (mean, across all concurrent requests)
Transfer rate: 35.87 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 1
Processing: 1702 3120 183.2 3098 4918
Waiting: 1657 2976 175.0 2956 4745
Total: 1702 3120 183.2 3098 4920

Percentage of the requests served within a certain time (ms)
50% 3098
66% 3166
75% 3212
80% 3249
90% 3361
95% 3453
98% 3578
99% 3634
100% 4920 (longest request)

结果总结

结果令我很惊讶！！不知道是我的XCache3.0设置问题还是怎么回事，XCache3.0很慢啊，比不用还要慢！？！？而且在测试期间CPU平均负载达到了10！？！？但愿是我设置问题。。。自己先琢磨一阵，如果找到哪里出问题了，再来更新。。。。

就目前结果分析，eAccelerator1.0对LNAMP的加速效果明显。在并发数为10的情况下处理5000个请求，如果不用eAccelerator1.0，则要花费283.546秒，使用了以后，花费的时间减少到了247.201秒，足足减少了近40秒。

本次测试并发连接数为10，请求数为5000，就能有40秒差距，相信如果并发连接数更多，总的连接数更多，eAccelerator1.0的加速效果会更明显。所以对大流量高并发连接的网站来说，加速效果绝对是很给力的！

而对于XCache3.0。。。。我暂时不做评论。。。。也许是XCache3.0和ZendGuard3.3冲突了，这里先保留测试结果，等我琢磨透了再做评论。。。。

事实证明，XCache3.0和ZendGuard3.3并没有冲突，我把ZendGuard3.3禁用了，结果XCache3.0还是那样。。。

对于这次XCache3.0测试结果这么奇怪，为此我把我使用的XCache3.0的设置贴上来，欢迎指正:

[XCache]
extension = "/usr/local/php5/lib/php/extensions/no-debug-non-zts-20090626/xcache.so"
xcache.admin.auth = On
xcache.admin.user = "xcache"
xcache.admin.pass = "8e6867a5d05144cf4761d6481fc674a8"
xcache.size = 64M
xcache.shm_scheme = "mmap"
xcache.count = 4
xcache.slots = 8K
xcache.ttl = 0
xcache.gc_interval = 0
xcache.var_size = 16M
xcache.var_count = 4
xcache.var_slots = 8K
xcache.var_ttl = 0
xcache.var_maxttl = 0
xcache.var_gc_interval = 300
xcache.test = Off
xcache.readonly_protection = Off
xcache.mmap_path = "/dev/zero"
xcache.coredump_directory = ""
xcache.cacher = On
xcache.stat = On
xcache.optimizer = On

1.备份防火墙配置文件，并从DA官方下载新的防火墙配置文件：
cd /etc/init.d mv iptables iptables.backup wget http://files1.directadmin.com/services/all/iptables chmod 755 iptables

警告：DA官方提供的防火墙配置文件中打开的是SSH的默认端口22，如果你的SSH端口不是22，则会造成你无法远程登录!!!解决办法是下载DA的防火墙配置文件以后手动编辑它的端口白名单,使你自己定义的SSH端口为打开状态.

重启防火墙:
/etc/init.d/iptables restart

2.下载脚本block_ip.sh，该脚本可以列出IP黑名单,执行下述命令来安装这些脚本:
cd /usr/local/directadmin/scripts/custom wget http://files1.directadmin.com/services/all/block_ip.sh wget http://files1.directadmin.com/services/all/show_blocked_ips.sh wget http://files1.directadmin.com/services/all/unblock_ip.sh chmod 700 block_ip.sh show_blocked_ips.sh unblock_ip.sh

3.创建空的IP黑名单:
touch /root/blocked_ips.txt touch /root/exempt_ips.txt

4.最后一步不是必须的，但是为了避免自己被误拉黑，所以需要在进行上面设置后使用过一段时间而没有出现问题的时候再进行这一步。
自动将可疑IP加入黑名单，执行以下命令:
cd /usr/local/directadmin/scripts/custom wget http://files1.directadmin.com/services/all/brute_force_notice_ip.sh chmod 700 brute_force_notice_ip.sh

一.DirectAdmin磁盘和流量统计信息不正确,用户磁盘占用和流量统计始终为0

出现这种情况的原因通常是系统的计划任务有问题，DA官方给出的解决方案如下：
1.检查/usr/local/directadmin/data/task.queue文件是否存在，如果存在，且包含几条信息，那么就表示数据统计没有运行，因为这个文件正常情况下会定期删除。
2.检查/var/log/cron文件(如果是Debian的话，检查/var/log/syslog)，看dataskq是否每分钟运行一次，如果不是，执行：
chmod 644 /etc/cron.d/directadmin_cron
/sbin/service crond restart
3.确保crond服务运行正常：
ps ax | grep cron
4.重启cron服务:
service crond restart
如果你的系统未安装crond，则先执行下述命令安装crond:
yum -y install vixie-cron cronie
启动crond:
service crond start
设置开机启动:
chkconfig crond on
5.如果上述一切都检查完毕，但是task.queue依旧不正常的话，执行下述命令手动运行dataskq：
/usr/local/directadmin/dataskq d