又要到夏天了,气温上升,笔记本又热起来。早就调研了笔记本风扇,当时是冬天,需求不强烈。现在是时候出手了。

     这种偏门的东西在b2c上是买不到的,只能求助万能的淘宝。目前淘宝有如下几个档位,170+,120,85

     170+的价格倒是在那,但是很难说是不是正品,店铺介绍里看说有指纹没问题啥的。。。感觉靠谱度也就一般般。
     120区间有不少,看配图什么的蛮有那么点意思,另外店家号称85的是翻新货。也不是没可能。

     最后筛选了下北京的,有一家最近出货量比较大,还有实体店地址且欢迎实体店购买,正好离得非常近,于是中午遛弯顺便过去买了下。

     不得不说中关村现在确实是衰落了,e世界一层都关了,楼上人也不怎么多。坐电梯上楼,店铺离的不远,很快找到了,老板拿出两个风扇,告诉我说这是原装的,硅脂没法复制,他们都做不出来。不太懂这个。我感觉就点几点硅脂能有啥难度?不过这种配件也不寄希望于买到原厂正品啥啥的,降温效果好就行。于是搞了个。


     晚上回家开始拆电脑,别的都好说,expresscard那里有个螺丝需要拧下来我忘记了,以为不用拧,结果主板搞不下来,我还以为是之前把外壳摔变形的原因,还用了一点蛮力,所幸最后发现这个问题及时纠正。。否则就呵呵了。

    新风扇跟原装的不太一样,新的是两条热管,细一些,老的是一条比较粗的热管。一对比确实老风扇老态龙钟了。


    换好开机,压力测试。效果还是挺明显的。之前待机状态就有40+度,d壳很热。压力5分钟后能到80+度。d壳热的快能煮鸡蛋了。更换后待机三十多度,压力后能到60度,d壳虽然也比较热了,不过热点较分散,不像之前集中在cpu那一块。至于静音方面。只能说即使在全速运转阶段,也基本听不到风扇的声音。



     相当爽,电脑又可以哈皮的用下去了。





Tags: , ,
    最近搞了个机器。想搞成同时支持openvz和kvm虚拟化技术的host。从原理上讲认为问题不大,因为两者分别是不同层面的虚拟化技术,一个是硬件级别虚拟化,一个是cgroup水平的进程级虚拟化(对这块了解不深,说错勿怪)。所以还是可能同时安装的。

    搜了下方案,果然有个proxmox的发行版是解决这个需求的。看了下文档,集成了一堆面板啥的,东西越多bug就越多。还是自己diy一个。

    由于openvz是需要打过patch的内核运行,而kvm则需要kvm和kvm_intel内核模块的加载(amd的就是kvm_amd)。所以难点就是这个的兼容。其他用户态的进程如果有冲突啥的都好解决。

    首先选用debian7(我喜欢debian),发现需要用openvz的源,源里使用的openvz内核是2.6.32。而debian7的内核目前是3.2。风险比较大。从源里拖了openvz内核deb包下来看,发现居然32位的内核不带kvm模块,而64位的才有。哭了。不知道他们咋搞的。于是64位系统搞起。结果发现kvm_intel加载不进去。报input/output err。用-f强制加载后报签名被拒绝。估计编译的时候哪里错了,虽然有内核源码和.config,不过还是不自己编译了,太折腾。

    还是用debian6。debian6的官方源里已经包含openvz了。内核版本也是2.6,32系列。跟debian6默认内核版本相同。这个感觉靠谱。装上重启进入openvz内核。modprobe加载kvm内核模块。ok,成功了。



     下一步就是进程和网络上的调整了。都不是大问题。



     结论是:openvz目前还是建议用debian6官方源里的包。兼容性好。
Tags: , ,
    很久没写blog了。今天考虑写一篇,登陆过程中想起目前登陆还是http裸奔状态,安全性实在是差。决定加一个登陆https保护。

    之前搞过一个startssl的免费证书,一年到期了。这次不想用他家了,一副浓浓山寨风。去namecheap搞了一个,很快就签发了。

    给一个子域名部署上去,把博客登陆提交地址改成https地址。这样密码的提交操作就被https保护了。


     如果只这么做了,登陆是不会成功的。因为子域的session和主域session默认是不通的。

     在session_start前加一句:  ini_set("session.cookie_domain", '.snooda.com');


     然后重启一下浏览器(此步骤必须)


     尝试一下登陆,ok了。
Tags:
    Thinkpad刚买回来的时候散热性能是非常好的,夏天用也非常凉爽,但用上两三年后,d壳就会非常热,夏天感觉都能有五十度往上了。拆开彻底的清理过灰尘,好了一些,但远没有新机的时候好。

    看到网络上很多人提到给笔记本风扇上了油或者换了新风扇,温度下降很多。认为有可能是风扇老化了。

    查看风扇转速,发现还是3000+转啊,噪音是变大了。但转速在那里,散热器灰尘也吹干净了,风量不小。


    为啥就是那么热呢?



     今天终于找到了问题的答案。原来散热器也是会老化的。


     笔记本的散热器就是一个铜的家伙,之前一直以为是靠铜来导热,还想那么长,导热过去要多久。今天仔细一研究,发现小小的散热器也用的热管。时间长了,热管里的导热剂泄露,导致热管导热性能下降。于是就产生了这种结果:风扇狂转,风量很大,但温度就是降不下来。


      这个时候只更换风扇是不够的了。要将整个散热器更换才可以治本了。









Tags: ,
    最近发现很多同学不知道线上操作替换文件的要点。所以又整理了一下。


    线上替换一个正在运行进程的文件时(包括二进制、动态库、需要读取的资源文件等)。应避免使用cp/scp操作。而需要使用mv/rsync作为替代。

    原因:cp是将源文件截断然后写入新内容。也就是说正在打开这个文件的进程可以立刻感知到修改。修改文件内容很可能导致程序逻辑错误甚至崩溃。而mv则是标记”删除“老文件,然后放一个新的同名文件过去。也就是说老文件和新文件其实是两个不同文件(inode不同),只是名字一样而已。正在打开老文件的进程不会受到影响。如果进程使用了mmap打开某文件(比如载入so),如果目标文件被使用cp覆盖并且长度变小。那么读取差额部分的地址时(在新文件中其实已经不存在了),会导致SIGBUS信号。使进程崩溃。




    至于可执行文件本身。倒是不怕cp导致崩溃。。因为cp时会报”text file busy"。压根cp不了。这时候也应该使用mv类操作。替换完成后重启进程。执行的就是新的可执行文件了。





Tags:
    lighttpd有一个功能,就是收到SIGHUP信号时会重新打开日志文件。这样在日志切分时很有用。但最近发现了一个bug。

    就是如果有子进程挂掉。父进程新fork出的子进程accesslog会默认打日志到最最开始父进程启动时的那个文件里。


   看了下代码。原来父进程在收到SIGHUP的时候只是把errorlog重新打开了下。没有重新打开accesslog(没办法,这个句柄是mod_accesslog模块搞的)。所以父进程维护的accesslog句柄一直是最老的。它本身不打accesslog日志倒无所谓。但它fork出的子进程是打的。这样就有问题了。



    一个最简单方法。就是外部脚本判断进程有更新的时候发一个SIGHUP信号过去。

    根治方法就是父进程重新启动子进程时给其发一个SIGHUP信号。

    至于父进程自己处理SIGHUP时重新打开句柄这个我感觉不太好。毕竟那是模块内部数据。lighttpd主干不应该关心。





Tags: ,
    最近arm盒子想用下tun功能。结果发现内核编译时没开tun,所以决定编译一个。

    先去找到了当前内核的config文件。打开了tun支持。下一步就是去找内核的源码。找了半天。发现没有完全一样的。于是找了个版本相近的,编译完载入。显然加载不了。提示insmod: error inserting 'tun.ko': -1 Invalid module format。在dmesg里提示tun: no symbol version for module_layout。

    很多资料在这里提示没有Module.symvers云云。但我的编译目录是有这个文件的。所以不是这个问题。

    由于内核源码版本和当前内核版本并不完全一致。所以尝试关闭CONFIG_MODVERSIONS。编译后加载。

    insmod依旧提示invalid module format。dmesg里改为提示version magic 'xxxxxxxxxxxxxxxxxxxxxx' should be 'xxxxx'。


    modprobe是可以强制忽略version magic的。即--force-vermagic参数,使用后成功载入tun.ko。由于内核源码非常相近。故工作正常。
    查阅了一下2.4内核源码中对CONFIG_MODVERSIONS的说明,该参数有四种可能。即内核是否开启与要加载的扩展是否开启2*2。经观察发现在3时代内核上这个特性跟之前的文档不太一致。由于时间关系没有详细研究。

    modprobe还有个参数,即--force-modversion。是在编译时开启了CONFIG_MODVERSIONS的情况下忽略接口不一致的。这个参数没有实验。


    也就是说如果想给一个内核编译扩展。最好的方式当然是找到当时编译的环境。或者编译一个新内核+扩展给系统装上。但现实中往往无法这样做。这时找到相近的源码编译。最后强制载入也就行了。(生产环境不推荐)



    happy,tun可以用了。
Tags: ,

top/vmstat等cpu iowait值含义

[| 不指定 2013/06/05 23:03]
    今天发现了一个现象。有一台io压力比较大的机器,基本iowait百分之七十左右。idle接近0。按我的理解是百分之七十的cpu都在等待或处理io。没有空闲的时间片了。

    但开启了一个视频转码服务后,iowait降到很低水平,usr和sys飙高,idle还是接近0。但此时发现视频转码和原io操作的服务均正常运行,未发生性能波动。

    马上感觉到其中的矛盾。cpu不是用完了么?为啥还能承受一个视频转码这种cpu密集的服务呢?

    
    仔细查看了一下iowait的解释。原来它的真实含义是:cpu空闲并且有进程在等待io就绪的时间。

    也就是说如果iowait很高。那么磁盘压力较大。但此时cpu是较为空闲的。此时如果运行诸如视频转码这种cpu密集型操作。是可以提高cpu利用率的。这一点在服务混布提高利用率上可以做文章。




Tags: ,
    今天发现这样一种部署情况:
   a的文件放在b的目录下,a不想让b看到,所以设置了700权限。

   其实这样也是不安全的。b虽然看不到a的文件,但可以把a的文件删掉。

   因为linux里,目录也是一个“文件”,里面记录了它里面有哪些文件,这些文件的inode。b的目录里可以放啥,b说了算,也就是说,只要将那个目录“文件”里不顺眼的文件项删掉,就能删掉文件,而不管对那个文件本身有没有权限。

   至于文件是不是真的被删掉了。取决于文件的引用数,如果没有其他硬链存在。文件就真的被删了。

  
   这里有一个特殊的目录:tmp。大家都可以往里面写,但只有属主可以删掉自己的。
   可以看下tmp目录的权限,它是root所有,所以对于普通用户来说,生效的是最后三位:rwt。其实应该是rwxt。t是特殊权限,是建立在x权限上的,如果删掉x权限,可以看到t变成了T。即失效了。

   t:SBIT(Sticky Bit)目前只针对目录有效,对于目录的作用是:当用户在该目录下建立文件或目录时,仅有自己与 root才有权力删除。
最具有代表的就是/tmp目录,任何人都可以在/tmp内增加、修改文件(因为权限全是rwx),但仅有该文件/目录建立者与 root能够删除自己的目录或文件。




  
Tags:
新增的HTTP返回码:
650:应用已删除或域名未绑定
651-654: 其他内部错误,请联系管理员


680:被应用防火墙ip黑名单封禁
681:超过应用防火墙设置的限额


配置功能(rewrite)新增点:

1,新增regex_url。该规则与url规则用法相同,区别是规则为标准正则。
例子:
         - regex_url: ^/[a-z0-9]\.html$
                   script: /index.php
                  
注意:regex_url和url规则在同一个app.conf不推荐混合使用。会有匹配顺序问题。

2,新增check_exist。检查文件和目录是否存在。支持的匹配规则:file_exist/dir_exist/not_exist
例子:
    - check_exist: not_exist
                   script: /index.php
                  
3,新增规则:status_code和location。
status_code指定返回的状态码。允许的值:301,302,403,404
location指定跳转地址(在status_code为301,302时使用)
例子:
         - regex_url: ^/secure_page$
                   status_code: 403

         - check_exist: not_exist
                   status_code: 302
                   location: http://example.com/error.html




url规则使用的lua正则由于使用比较晦涩,以后不推荐使用。本次新增的status_code和location也不再支持url规则。
原有url规则功能不受影响。



Tags: ,
分页: 2/31 第一页 上页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]