标签归档：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！

让人郁闷的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数据包？