http://www.snooda.com/index zh-cn http://www.snooda.com/read/312 snooda <admin@snooda.com> Sun, 22 Jul 2012 15:06:44 +0000 http://www.snooda.com/read/312
    中午的时候准备看看日志确认下，结果发现真的一个访问都没有。。蛋疼了，发现凌晨5点后一点日志都没了，奇怪，心想网络没有断，为啥呢，访问了下页面，发现数据库挂掉了，无法更新。一查文件系统，原来只读了。发ticket说磁盘坏了，正在更换。等了一个多小时没好，等不及了，开始切换。

    刚准备好切换，机器down掉了，还好博客数据和程序都有备份，从代码仓库里check出来代码。备份里恢复出来数据库，恢复数据库的时候有个插曲，由于是全量备份，所以导入的时候会把目标库里的mysql库等信息都覆盖，会使目标数据库错乱，所幸没有flush，于是把目标库的备份重新覆盖了下。

    然后dns切换，由于主dns挂掉，只有从dns服务器还能工作，手动修改了数据文件指向新机器。修改ttl为300s，以便切回的时候能快速切回。

    周五机器更换磁盘起来了，但是没数据，客服说等磁盘寄回来后才知道数据能不能恢复。虽然自己有备份，但很多软件配置没备份，自己重新配比较麻烦。还是等数据。
   今天告诉我数据取出来了，给了个ftp取数据，搞到数据后恢复了一下环境，dns切换回来了。


    看来冷门数据也要做长周期备份了。
Tags - 故障 ]]> http://www.snooda.com/read/307 snooda <admin@snooda.com> Tue, 19 Jun 2012 15:57:07 +0000 http://www.snooda.com/read/307     现在使用最多的主机面板就是cpanel，而cpanel恰好有很多api。
    于是搞了一个面板，可以将一个普通的cpanel用户账号多人共享，互不干扰。这样方便了主机合租和账号分享。朋友们共享主机时不再需要购买多个主机或reseller账号了。
    不过面板的账户间共享资源，所以隔离性上还是不如reseller账号的。所以建议还是朋友或熟悉的人之间使用。

    项目地址：http://code.google.com/p/cp-share/
    本文地址：http://www.snooda.com/read/307
    第一版实现了域名，数据库，ftp账号的管理，功能和界面都比较简陋。不过已经可以满足基本的需求了。后续慢慢完善。

    附截图一张：




Tags - cpanel ]]> http://www.snooda.com/read/292 snooda <admin@snooda.com> Tue, 15 May 2012 15:25:57 +0000 http://www.snooda.com/read/292
    香港是众所周知的小水管，今天试了一下名不虚传，网站测速测一个wp的首页才6k的数据就惨不忍睹，测一个380k的图片，单线程稳定1.4M，应该是限速了。多线程直接各种超时，并且遇到一个从来没遇到的情况：测速时由于带宽跑到限制，ssh输入都挂了，无响应，停止测速才恢复。。。。小水管真是名不虚传。

    观察了一下稳定性，也非常一般般，波动不小。

    用台湾vps和香港vps搭了一对dns试了一下，刚开始设置所有记录均不缓存，发现我自己的电脑上每次都稳定在500ms左右，非常奇怪，因为到任意一台机器都只需要几十ms，解析时指定dns确实也只需要几十ms，后来把ns记录设置了缓存一分钟，发现在缓存期内延迟降到了几十ms，看来是由于不缓存ns记录时需要去一级域dns那里查顶级域名的ns记录导致的，不过奇怪，难道一级域dns给出的ns记录缓存时间是由顶级域dns里的ns设置决定的么？搞不懂。不过我把ns记录设置成缓存1小时时，发现监控宝的dns监控时间还是稳定在500ms左右，没有下降，ft。并且四个监控点还总有一个报获取不到记录。

   dns的性能测试实在是不好搞，设置成不缓存的话不太好同条件对比，因为dns商不会允许这么设。设缓存的话结果又往往取决于缓存dns服务器的性能。对于大站的话由于访问人数多，所以dns一定是被缓存住的，倒不用考虑dns问题，对于小站，每个访客都要从头解析一下域名，dns的速度就很重要了。

   不过通过今天的观察发现自己建dns性能也不如预想的那么好，不过毕竟定制性好。

Tags - dns ]]> http://www.snooda.com/read/282 snooda <admin@snooda.com> Sun, 06 May 2012 02:59:26 +0000 http://www.snooda.com/read/282
    通过命令展示出的数据可以看出丢包率：Loss，已发送的包数：Snt，最后一个包的延时：Last，平均延时：Avg，最低延时：Best，最差延时：Wrst，方差（稳定性）：StDev。非常强大。

    按d可以切换各个视图，按一下后切换到的视图用？来表示丢包，点表示正常，不过右括号不知道什么意思。再按一下就更复杂了，还有字母数字等等。网上的资料貌似也没有提到，等有时间看看源码。不过默认视图就足够用了。

    刚刚试了一下，从国内到博客服务器，丢包大户是：202.97.53.242，现在丢包率在6个点。看延迟应该是在美国的一个路由。






Tags - mtr ]]> http://www.snooda.com/read/270 snooda <admin@snooda.com> Sat, 21 Apr 2012 09:50:11 +0000 http://www.snooda.com/read/270
    今天发现最近搞的一个vps时间又不准了，前几天发现时间差了半分钟，找客服校准后今天看又差了4秒，平均每天要差1秒多点，相当不爽。发ticket希望客服能加个crontab任务定期校准一下服务器时间。

    在印象中电脑主板时钟已经做的不错了，怎么还会有每天差1秒这种问题。。。会不会主机商用的服务器有问题。比较囧。由于那个vps未来想观察一段时间稳定后作为主力机的。所以要求还是比较高。

     ]]> http://www.snooda.com/read/263 snooda <admin@snooda.com> Wed, 11 Apr 2012 18:52:07 +0000 http://www.snooda.com/read/263
    用法： python vz_checker.py /proc/user_beancounters (需要root权限）
    输出内容：

filename is:[user_beancounters]
Kernel Mem Info:                                   used:[5.723M] max_used:[35.539M] limit:[2048.000M] fail_count:[0]
Mem already allocated Info:                        used:[17.621M] max_used:[33.074M] limit:[96.000M] fail_count:[0]
Ram actually used:                                 used:[8.516M] max_used:[67.820M] limit:[96.000M] fail_count:[0]
Mem (Ram + swap) used:                             used:[9.848M] max_used:[13.219M] limit:[96.000M] fail_count:[0]



Kernel Mem Info：占用的内核内存大小，不可被swap，主要用来存放进程数据等。
Mem already allocated Info：已分配的内存大小，limit即为burst内存大小。
Ram actually used： 实际占用的物理内存大小。
Mem (Ram + swap) used：  占用的物理内存和swap大小。


如果  实际占用的物理内存 == 占用的物理内存和swap大小  那么恭喜你，你的vps里运行的程序都在内存中，主机超售不严重。
如果  实际占用的物理内存 <   占用的物理内存和swap大小   情况不妙，主机已经开始占用swap了，超售比较严重了。


另外我在测试过程中发现有一台vps实际占用物理内存大小显示比物理内存+swap总和还要大，现象很奇怪，查了一些资料没有关于这方面的说明，待后续调查。


脚本功能还比较粗糙，一些数据需要继续打磨，欢迎大家提意见~~
本文地址：http://www.snooda.com/read/263
下载地址：https://github.com/snooda/openvz_checker











Tags - openvz , 超售 , 内存 ]]>