分类目录归档：linux系统管理

调整SWAP分区大小后，SWAP丢失为0的解决

发表评论

今天Linode升级了VPS的配置，内存从512MB升级到1GB了，原来机器配置的SWAP分区为512MB，打算调整到1GB，跟内存一样吧。
于是通过Dashborad调整了swap所在的分区/dev/xvdb的大小到1024MB，但是进入系统后free发现：
[@@@@@@]# free
total used free shared buffers cached
Mem: 1024976 248992 775984 0 16820 73128
-/+ buffers/cache: 159044 865932
Swap: 0 0 0

整个swap没有加载上，于是考虑到是扩展分区大小造成的，检查fstab，没有异常。用swapon加载提示：
[@@@@@@]# swapon -a
swapon: /dev/xvdb: read swap header failed: Invalid argument

原来是扩展后的swap分区没有格式化（初始化）。
[@@@@@@]# mkswap -f /dev/xvdb
Setting up swapspace version 1, size = 1048572 KiB
no label, UUID=xxxxxxxxx-xxx-xxx-xxxx-xxxxxxxxx
[@@@@@@]# swapon -a

再free一下看看：
[@@@@@@]# free
total used free shared buffers cached
Mem: 1024976 249000 775976 0 16932 73108
-/+ buffers/cache: 158960 866016
Swap: 1048572 0 1048572
正常加载了。

Linode免费升级VPS配置和流量配额了。

1条回复

一直在用Linode的VPS，博客、SSH Tunnel翻墙都用的挺好。自从Linode有在东京KDDI的机房后，国内访问更快了。赞，就一个字。
最近Linode对所有机房的服务器硬件和网络硬件做了一次大的升级。升级后，对VPS产品的配置和网络流量配额都提供了免费升级选项，幅度很大。
以我在用的Linode512为例，升级前配置：
CPU：4 core/Mem：512MB/Month’s Network Transfer：200GB/Price(per month)：$19.95
升级后：
CPU：8 core/Mem：1GB/Month’s Network Transfer：2TB/Price(per month)：$20.00
就贵了5美分，果断升级。

升级方法：登陆Linode后，在对应的VPS的Dashborad右侧最下方有一个Update的提醒，按照提示进行就好。
确认要升级后，会把你的VPS添加进入升级队列排队等待升级。
升级过程不需要干预，升级完毕后恢复到VPS原来的状态。IP、端口、服务都没有任何变化。
重新SSH登陆进去free看看，Enjoy！

一个困扰已久的Cacti问题

发表评论

集群用了cacti监控服务器，部署的时候用了最新的版本0.8.7g，nginx连接数的监控不能正常工作，困扰了我好久。

今天早上突然想起问题会不会处在spine身上，于是立马去尝试spine的debug.

手动执行<path_cacti>/scripts/get_nginx_clients_status.pl <stub_status_url>能够正确的获取返回的数据。

第一步：使用poller的debug：
/usr/local/php/bin/php -q /usr/local/nginx/html/cacti/poller.php –force –debug
可以看到很多这样的错误：
ERROR: not enough argument
应该就是在获取nginx client时出现的错误。

而且查看nginx client的rra，发现更新时间都是很久前的。

第二步：使用spine的debug：
cd <path_to_spine>/bin/
./spine -C ../etc/spine.conf –verbosity=5 -H 2
其中-H为Host的ID，可以在devices菜单中查到。

其中关于nginx连接数的信息：
NginxStatus, output: 0
可以看到，spine没有获取到数据。

去官网下上一个版本的spine，编译，安装，并重新执行：

./spine -C ../etc/spine.conf –verbosity=5 -H 2
有数据了

唉，0.8.7.g的bug真不少呢。

转：VMware ESXi 挂载 iSCSI 和 NFS 性能测试

发表评论

原文地址：http://www.yaoge123.com/blog/archives/202

　　iSCSI-target和NFS Server由一台Raid10(4*2.5′ 10Krpm 146GB)的VMware ESXi
3.5里的FreeBSD服务机提供，在另一台Raid1(2*3.5′ 15Krpm 146GB)的VMware ESXi
3.5里挂载iSCSI和NFS，然后分别以虚拟磁盘添加入FreeBSD测试机中。使用/usr/local/bin/iozone -i 0 -i 1
-i 2 -r 1024 -s 1G -t 2 -C测试。测试结果如下：

　　iSCSI测试：
Initial write = 5443.42 KB/sec
Rewrite = 4840.85 KB/sec
Read = 19823.13 KB/sec
Re-read = 19298.97 KB/sec
Random read = 44114.65 KB/sec
Random write = 4024.72 KB/sec

　　NFS测试：
Initial write = 952.76 KB/sec
Rewrite = 975.36 KB/sec
Read = 14782.20 KB/sec
Re-read = 16085.16 KB/sec
Random read = 41878.42 KB/sec
Random write = 794.31 KB/sec

　　CPU占用率上NFS只有iSCSI的一半，服务机和测试机都差不多。iSCSI时CPU占用率为15%左右，中间还有一段是30%多。NFS时基本都8%左右。两台机器均为2*Intel E5405，分配给虚拟机2个核。

　　测试机直接加载NFS测试：
Initial write = 2361.99 KB/sec
Rewrite = 2130.92 KB/sec
Read = 17595.85 KB/sec
Re-read = 18904.29 KB/sec
Random read = 13139.79 KB/sec
Random write = 2001.82 KB/sec

　　测试机本地测试：
Initial write = 8233.32 KB/sec
Rewrite = 12511.68 KB/sec
Read = 34969.73 KB/sec
Re-read = 34179.26 KB/sec
Random read = 82272.52 KB/sec
Random write = 4620.50 KB/sec

　　服务机本地测试：
Initial write = 6236.64 KB/sec
Rewrite = 9016.30 KB/sec
Read = 47051.42 KB/sec
Re-read = 47444.12 KB/sec
Random read = 27243.86 KB/sec
Random write = 3251.88 KB/sec

服务器不稳定的罪魁祸首找到了

1条回复

迁移到分布式集群后，困扰了我们很长时间的突发性Load异常终于在昨天找到原因了，原来是NFS的挂载选项引起的，我们之前挂载用的是sync模式，导致集群的web后端在往挂载于NFS服务器的日志目录打日志时会产生严重的延时，引起MySQL产生大量的sleep进程。而且在高并发的情况下，这种情况会不断的恶化，因为多个后端需要抢占日志文件，而sync决定了大家同时只能有一个后端在操作日志文件，其他的请求必须排队，高并发时nfsd的调度能力下降，会导致php-fpm出现大量的无法自己清理的sleep进程。

而且，由于我们自定义的日志是频繁打开和关闭文件的，于是，nfs用的portmap会产生大量的getattr类型的rpc call，查阅RedHat的文档的时候发现，频繁的getattr会大大降低nfs的性能，于是情况更加恶化了。所以前段时间妖气一直都不是很稳定。

经过在测试机上做的测试，把挂载选项调整为async后，往nfs上进行简单文件操作的php总执行时间从sync模式的25ms左右缩短到0.9ms，虽然和本机文件的0.0x ms比慢不少，但至少可以接受了。

async模式下，nfs服务端5s刷新一次脏数据到硬盘中，这个间隔还是可以接受的。调整为async后，日志都正常开启，MySQL的process list里面sleep终于没有了，偶尔有也是不超过1s的，正常了。

分布式系统带来的新的的技术难点和需要注意的地方真的很多，考虑的地方多很多。

妖气加油！

nfs优化（转）

发表评论

转自：http://www.linuxsky.org/doc/network/200709/130.html

1.设置块大小

mount命令的risize和wsize指定了server端和client端的传输的块大小。

mount -t nfs -o rsize=8192,wsize=8192,timeo=14,intr client:/partition /partition

如果未指定，系统根据nfs version来设置缺省的risize和wsize大小。大多数情况是4K对于nfs v2，最大是8K，对于v3，通过server端kernel设置risize和wsize的限制

vi /usr/src/linux2.4.22/include/linux/nfsd/const.h
修改常量: NFSSVC_MAXBLKSIZE

所有的2.4的的client都支持最大32K的传输块。系统缺省的块可能会太大或者太小，这主要取决于你的kernel和你的网卡，太大或者太小都有可能导致nfs速度很慢。
具体的可以使用Bonnie，Bonnie++，iozone等benchmark来测试不同risize和wsize下nfs的速度。当然，也可以使用dd来测试。

＃time dd if=/dev/zero of=/testfs/testfile bs=8k count=1024　　测试nfs写
＃time dd if=/testfs/testfile of=/dev/null bs=8k　　　　　　　 测试nfs读

测试时文件的大小至少是系统RAM的两倍，每次测试都使用umount 和mount对/testfs进行挂载，通过比较不同的块大小，得到优化的块大小。

2.网络传输包的大小
网络在包传输过程，对包要进行分组，过大或者过小都不能很好的利用网络的带宽，所以对网络要进行测试和调优。可以使用ping -s 2048 -f
hostname进行ping，尝试不同的package size，这样可以看到包的丢失情况。同时，可以使用nfsstat -o net
测试nfs使用udp传输时丢包的多少。因为统计不能清零，所以要先运行此命令记住该值，然后可以再次运行统计。如果，经过上面的统计丢包很多。那么可以
看看网络传输包的大小。使用下面的命令：

#tracepath node1/端口号
#ifconfig eth0

比较网卡的mtu和刚刚的pmtu，使用#ifconfig eth0 mtu
16436设置网卡的mtu和测试的一致。当然如果risize和wsize比mtu的值大，那么的话，server端的包传到client端就要进行重

组，这是要消耗client端的cpu资源。此外，包重组可能导致网络的不可信和丢包，任何的丢包都会是的rpc请求重新传输，rpc请求的重传有会导致
超时，严重降低nfs的性能。
可以通过查看

/proc/sys/net/ipv4/ipfrag_high_thresh
/proc/sys/net/ipv4/ipfrag_low_thresh

了解系统可以处理的包的数目，如果网络包到达了ipfrag_high_thresh，那么系统就会开始丢包，直到包的数目到达ipfrag_low_thresh。

3.nfs挂载的优化
timeo：　　如果超时，客户端等待的时间，以十分之一秒计算
retrans：　超时尝试的次数。
bg：　　　 后台挂载，很有用
hard：　　 如果server端没有响应，那么客户端一直尝试挂载
wsize：　　写块大小
rsize：　　读块大小
intr：　　 可以中断不成功的挂载
noatime：　不更新文件的inode访问时间，可以提高速度
async：　　异步读写

4.nfsd的个数
缺省的系统在启动时，有8个nfsd进程
#ps -efl|grep nfsd
通过查看/proc/net/rpc/nfsd文件的th行，第一个是nfsd的个数，后十个是线程是用的时间数，第二个到第四个值如果很大，那么就需要增加nfsd的个数。
具体如下：

#vi /etc/init.d/nfs

找到RPCNFSDCOUNT,修改该值，一般和client端数目一致。

#service nfs restart
#mount -a

5.nfsd的队列长度
对于8个nfsd进程，系统的nfsd队列长度是64k大小，如果是多于8个，就要相应的增加相应的队列大小，具体的在

/proc/sys/net/core/rwmem_default
/proc/sys/net/core/wwmem_default
/proc/sys/net/core/rmmem_max
/proc/sys/net/core/wmmem_max

队列的长度最好是每一个nfsd有8k的大小。这样，server端就可以对client的请求作排队处理。如果要永久更改此值

#vi /etc/sysctl.conf
net.core.rmmem_default=数目
net.core.wmmem_default=数目
net.core.rmmem_max=数目
net.core.wmmem_max=数目
#service nfs restart

昨天加班到今天凌晨1：36，可恶的nginx！

发表评论

nginx的缓存规则有了变化，或者说nginx对缓存部分做了bug fix，于是我们以前的写法就不生效了，研究了好久，终于搞定了。

这是继location的写法变化后另一个重大的变化，让我们好囧啊，现在的nginx，越来越向squid发展了，不喜欢。

ps：回去还淋雨了，好大的雨。

新项目又来咯……妖子们，期待吧

2条回复

回到座位上，看着新邮件的提示，点开，trac系统自动发送的，雷哥切完页面了，我要开工啦。

加上不董君9页的需求文档，国庆前一天的Deadline。看来之前我预计的真没错，十一前是闲不下来了，杯具呀。

上了CDN后，服务器那边表现还算不错，服务器集群不出问题我就轻松多了，确实有段时间没有正儿八经写网站的程序了，恢复恢复手感，嘿嘿。

妖气加油，妖子赛高！

PS：昨天还是做了个挺有用的东西，Cacti的插件demo，用来通过监控机远程在集群的其他机器上执行命令的WebShell，只写了雏形，忙完这个项目就好好完善一下，X君对这个插件demo还是抱有很大期望的，当然，我自己也是。发个开发版截图，请无视一个从来不会用PS的人–我自己用CS5改的那个logo以及Shell上方输出的调试信息…..

终于上盛大的正式CDN了

发表评论

中秋的前一天终于上了盛大正式的CDN，刚才切域名的时候手还抖了一下差点切错，这杯具的天气，嘿嘿嘿……

好啦，这下机房不用担心流量了，不用连夜跟电信联系改计费方案了，不用担心上联拥塞了，不用担心……

但是，XEN虚拟机网络效率比较低的问题还是要解决的。

还有我们的Nginx监控，还在悲催着，难道真的要哥自己写么？好吧，我承认，貌似除了这样，没有啥好的方案了。

让人郁闷的XEN

发表评论

今天下午，和X君对XEN和实体机的网络表现差异在生产环境进行了测试，通过测试，基本可以证明昨天莫名的网络问题，是虚拟机网络IO的瓶颈造成的，现在没有确定的是到底因为虚拟网卡的参数问题还是XEN本身的虚拟硬件的技术瓶颈。

根据我们的测试数据，一台实体机上开两个XEN虚拟机，只要有一个网络吞吐量到60Mbps，这台虚拟机就会发生掉ping，内外网ping延时增加，丢包率上升。

相对应的，实体机，网络吞吐量外网达到95Mbps，同时内网达到92Mbps，如此巨大的流量对内网ping的影响也就是从0.08x ms增加到0.10x ms，外网从49ms增加到51ms，基本无压力。

而且同一台实体机上的两个虚拟机在有一台网络高负荷的时候会对两外一台同宿主机的虚拟机产生轻微的影响。

这些都不是我们希望看到的，虽然我们有足够的前端，我们有足够的带宽，我们也丝毫不怀疑nginx的负载能力，但是还是早点上CDN比较稳妥，前端迟早都要换回实体机，要不然，以后肯定是隐患和瓶颈。

PS：今天发现了一个有趣的现象：在一台XEN虚拟机A上从一台实体机B上拷东西的同时用另一台实体机C来ping A，用cp和scp会有完全不同的结果。

用cp通过nfs拷，C ping A的延时从0.9ms立刻上升到3ms，并且飘忽不定。

用scp拷，C ping A完全无影响，一直都是0.9ms。

但是cp和scp用时几乎一样，平均速度都差不多。

真是很神奇，难道cp拷东西的同时会发送大量的ICMP或者UDP数据包？