最近发现有个问题,一个自制的webserver在应答前端请求时,总是要处理1s以上,似乎是由于哪里等待了1秒。研究了下发现:Expect: 100-continue这个东东。

    100-continue这个状态码之前是很少遇到的。这个是http1.1协议为了提高效率设置的。当客户端要POST较大数据给webserver时,可以在发送http头时带上Expect: 100-continue,服务器如果接受这个请求,应答一个HTTP/1.1 100 Continue,那么客户端就继续传输正文,否则应答417,客户端就放弃传送剩余的数据了。这样就避免客户端吭哧吭哧传了一大堆数据上去,结果服务端发现不需要的情况。

    libcurl在不同版本里逻辑不同,有的版本libcurl会在POST数据大于1024字节的时候发送100-continue请求,有的版本则不会。我们用到的libcurl版本会发送,而自制webserver不会应答这个请求,客户端等待1s钟没有收到肯定或否定的应答,还是继续传输了正文,虽然逻辑上并没有问题,但速度上就慢了下来。

    加了下逻辑,对100-continue进行应答,速度马上提高很多。



Tags: ,
    很久之前就有一个问题在困扰,就是明显感觉svn操作完后要顿一顿才结束。一直以为是svn机器性能问题,后来上了ssd也没效果。

   最近抽时间看了下。

   先strace一下看看时间,发现在操作末尾两个gettimeofday之间夹了个select操作。会阻塞几百ms到1s不等,然后超时。

   第一感觉是最后处理完了可能给服务器发回个什么数据之类的,服务器那里哪个规则配的不对,客户端连不上然后超时了。

   看svn源码,看不出来末尾做了啥网络操作,封装了好多层,不确定是不是哪一层注册了什么奇奇怪怪的回调函数,在最后析构时搞一把。

   用gdb单步跑了一下。

   发现svn_io_sleep_for_timestamps函数很可疑。

   查看代码,发现这是个延时函数。svn通过mtime获取文件修改信息,所以每次svn co操作末尾,svn会等待一小段时间再返回,svn客户端判断apr_stat返回的文件mtime是不是1000000整倍数(stat看到的mtime小数点后面是否全是0),如果是0,那么svn认为该文件系统不支持毫秒级粒度的mtime记录,就会等待系统时间秒的跳变,即等待平均0.5s,最长1s。如果不是0,那么只等待1ms。
  
   由于svn使用的apr_sleep为了实现较高精度的sleep延时,使用了select来做延时。这就是strace中select系统调用的由来。


   这里还有一个问题,就是如果文件mtime恰好是整数,那么svn就会判断失误,进而等待较长的时间。作者认为总比每次都等较长的时间好。

   之前用的文件系统是ext2,它只支持秒级精度的mtime,而ext4支持更高精度。

   找了一台机器,划了两个同样大小的分区,一个格式化为ext2,一个格式化为ext4,使用svn co向两个分区中checkout代码,前者耗时0.3到1s不等,后者稳定在100ms。性能提升非常明显。





Tags:
    想上无风扇电源,所以调研下电源去掉噪声后其他地方如何降噪。开始拿cpu风扇入手。cpu散热器用的最便宜的超频三青鸟3。cpu是32nm Sandy Bridge 赛扬G550,比较节能。看网络上有些人在尝试G530无风扇工作,不过都比较简单,决定自己试一下。


    有很多人是在bios中对cpu进行降频以实现降温的,想了下,感觉这种方法灵活性不足,另外太过高端。决定不采用。还是用软件的cpufreq比较简单灵活。使用sensors工具查看cpu温度。


    首先拔掉cpu风扇电源,开机滴滴报警,忽略之,进入系统。看到温度在50度左右。cpu默认工作在1.6G频率下。


    写了个死循环程序,先单核跑满,单核心运行在2.6G频率下,温度缓慢上升。慢慢上升到83度左右稳定下来。

    然后尝试双核跑满,结果温度迅速冲上90+,我看sensors里提示的温度最高值为102度。急忙停了压力,温度1s内就降到了60+。还是挺快的。

     看来默认情况下双核满载单靠散热器是不行的了。下面尝试限制最高频率后的满载测试。

     首先限制双核1.6G,满载,温度没什么变化,很正常,cpu本来就在1.6G下跑着,满不满载没啥区别。
     2G+1.6G,温度上升至70+
     2G+2G,温度缓慢上涨2-3度,看来较低频率情况下,总温度和温度较高那个核的温度相关性大,与发热总核数关系不怎么大。
     2.1G+2.1G,温度上升至80+
     由于80度就已经算是较高的温度了,所以没有继续往上测试。


     当前室温在20度左右。

     也就是说2.1G是可以无风扇长时间稳定运行的一个频率。再高就不好说了。以后有需求就搞个自动限频脚本,温度升到指定值就降低频率防止过热。


     然后看看频率对性能的影响。在网上随便扒拉了一个算某某值的命令,大致跑了下,1.6G频率下跑完需要40多秒,而2G频率下跑完只要33s,再高频率的就没有试了。看来性能还是有一些影响的。





    

  
Tags:
    很久没有写博了,最近一段时间比较忙,不过怕太长时间不更新被抛弃,还是写一些水文章吧。

    前两天入了块硬盘,之前装的台式机一直拿老笔记本硬盘跑着,容量不够了,最近感觉硬盘价格自洪水后又回归到比较合理位置了,于是准备出手。

    最开始看上的是希捷2T,用的人很多,不过网上一看评价,比较惨,说噪音大的,故障率高的等等。另外我的笔记本原装的就是希捷硬盘,用了两年就挂了。于是不敢买了,看看别的,看到了西数的1T蓝盘。


    说实话这一款也不怎么被看好,刚出来时评测说寻道时间高达20ms以上。性能比希捷的稍微差些。不过我比较在意的是噪音和稳定性,由于有计划上无风扇电源,所以对于其他部件的噪音很在意,性能倒是其次了。于是就选定了西数单碟1T。


     下单的时候看有人说新出的已经有寻道时间比较正常的批次了,心里又多了些期望。


     历经几天,终于到手了,刚拿到时感觉比想象的轻很多,看批次是9月30日出厂,产地马来西亚。回家装上,通电,听到一个嗖的加速声音,然后是磁头吱吱的来回运动,持续了1s,没有了。仔细听了下噪音,震动和声音比笔记本的大多了,带动机箱隔板有些颤动。不过相比于电源风扇的声音稍微好一点点。

     先装个windows跑跑hdtune,跟网上的数据对比了下。读取速度还是比较稳定的,基本上一个较为平滑的曲线,最高180MB左右,最低到了100MB以下。所幸寻道时间还可以,16ms,看来寻道时间长的问题修正了。

    由于用了比较老的hdtune,缓存大小测试不出。不过蛋疼的是,居然不支持噪音管理。设置了下aam,果然不行。囧,这也太弱了。另外转速也测不出。


    总体还凑合,反正比老笔记本硬盘快多了
Tags: , ,
    最近一直苦于没有什么话题来写博,今天终于找到一个。    有人疑惑为什么使用fq代理后访问某些网站反而快了,疑问是不是某防火墙在捣鬼。    世界上一共40亿个ipv4地址,ipv6就更多了,为啥访问任意一个地址就能访问的到?是谁维护了这40亿个地址的分布?从这个ip到那个ip途径的路由是谁来指定的?

    从我们电脑的上网来讲,接入网络就能上网,这个是很稀松平常的事,但如果同时接入两个网络呢?比如一根有线一根无线,那么流量是怎么走的呢?这个时候电脑里的路由表就发挥了作用,运行route print命令,可以看到一行行的规则,每个网络包都会从上到下匹配这些规则,如果匹配上,就按规则指定的端口转发出去。一般同一时间段内流量只从一个网卡流出。


    进一步讲,家里多人上网的话会有路由器,对于家里电脑间传送文件和访问公网网站,流量是分发到不同端口的,路由器的路由表规则就不再是简单的向某一个端口分发,而是针对不同的ip段走不同的分发规则,一般内网ip流量分发至对应内网端口,公网流量统一从公网端口发送。

    对于公网上的流量,一样是按照路由表指示的路径行进,路由表是如何生成的呢?

    首先不会是每个ip一条记录,因为数据量太大,这里就用到了ip的分块,最早是用a,b,c三类来划分,后来由于粒度太粗,后来改用子网掩码的形式,子网掩码规定的范围是ip段的网络名,其余部分是可用地址范围(不全是,本文内容不做涉及),这样,路由表的尺寸就能缩减不少。

    互联网是网状的,每个路由都会于1个或多个其他路由进行连接,连接可能断开,可能阻塞,可能新建,所以路由表也会不断更新,一个路由器如何得知互联网上其他路由间的连接状态从而更新自己的路由表,就需要用到路由交换协议,比如RIP,路由器将自己所知道的路由信息广播给周边路由,这样网络连通信息就能不断扩散至全网。


    不过网络上的路由器成千上万,如果所有路由都按照这种方式,效率非常低下。

    现实中,网络划分为了不同的自治系统:AS,AS的编号由ICANN管理,成为一个AS需要有多线路的连通能力,像电信、联通都是AS,一些较大的网络服务商也可以申请AS号和自己的地址空间。每个AS系统内部维护自己地址空间的路由信息,AS系统间的边界路由器使用BGP协议交换各自地址空间,这样,发往一个AS的网络流量只需要发给对应AS的边界路由即可。不过如果AS间网络带宽较小或者不稳定,就会有“跨网络互通问题”,就像国内电信和联通间访问效果不佳。

    早期国内主机解决网络互通问题会使用双ip的方案,同时接入一个电信ip和一个联通ip,再搭配智能dns,可以较好的解决了互通问题。但还是有浪费ip地址、智能dns解析不够准确的问题。

    后来就有了多线主机有的也叫bgp主机,只有一个ip,但同时接入多个线路,有双线、三线、甚至五线。对于接入的线路,均可以实现较好的访问效果。原理就是机房同时实现和多条线路的互通,将ip广播至每条线路。

    对于服务器可以通过接入多线的方式提高接入性能,对于上网者来说也一样。但同时开通两条甚至多条宽带的成本是比较高的,这样我们就可以借助多线服务器来提高网络访问速度。比如辽宁教育网用户访问辽宁联通,需要绕行至东北教育网节点甚至中国教育科研网节点,但如果借助一台部署在辽宁、同时接入教育网线路和联通线路的服务器中转。网络速度就能大大提高。对于访问国外站点也是一样。
    

    资料:
    查看全球bgp路由表:http://www.ris.ripe.net/bgpviz/
    telnet:route-views3.routeviews.org




    
Tags: , ,
    最近需要做一个基于php的多进程server。为了优雅重启,需要捕获一下kill发出的SIGTERM信号,于是用到了pcntl_signal。

    刚开始发现捕获信号无效,无法进入信号处理函数。研究了一下文档,发现要运行一下declare(ticks = 1);看解释说是为了产生时钟云云,我的理解就类似于晶振一样。添加后父进程可以收到信号了。

    但是子进程还是无法收到信号,排查了很久,没看到什么异常,子进程是平时阻塞噻socket_accept的,怀疑是不是系统调用在这里无法中断,于是改成while 1循环,可以顺利进入中断处理函数。

    然后搜索了一下,原来pcntl默认都是会自动重新启动被中断的系统调用的,对外表现则是无法中断系统调用的阻塞。

    这时回头看手册,原来pcntl_signal还有第三个参数,也是一个可选参数,就是让我们决定是否自动重启系统调用,选择不重启即可。




Tags:
    台湾vps已经不靠谱了。于是开始迁移至香港,台湾vps决定放弃。这时遇到了问题,就是dns又变成了单点。

    所幸服务商提供了slave dns功能,这个还是很少见的,不过这个功能对于我来说实在太有用了。

    估计也是这个服务太过小众,服务商的功能也是bug多多,发了无数ticket才搞定。

    首先是管理页面就有问题,添加slave dns记录后刷新页面,记录就消失了。也不生效。通知他们修正了下,搞定了。

    然后发现添加记录倒是成功了,但没有slave dns来拉取记录。而这时我操作太激进,把ns记录都切换过来了,结果导致落到slave dns上的请求都返回空记录了,发现后急忙切换回来。发ticket通知他们,告诉我要在allow-transfer里把所有的服务器ip都加上,试了下,似乎nslookup - slave dns ip 使用指定dns后还能成功了。很高兴。

     但过了一会发现请求还是落到了主dns上,并且有很大概率的失败,于是再次联系客服。客服说在添加slave dns记录时我的master dns ip没有记录上,重新添加不行,后来客服搞了一下,可能修复了bug,可以了。

     然后发现slave似乎不支持notify请求,我用rndc reload更新记录时没有slave来请求。

     先是添加also-notify,通知所有slave dns,因为默认是通知所有ns记录里的服务器,不过我并没有用到全部slave server,所以要手动添加其他服务器收到通知。

     发现还是无效,猜测可能是出口ip不对,于是添加notify-source指定了notify时的来源ip。

     重启bind9, 成功了。


Tags: ,
    自用开发机的ubuntu还是9.10版本,不在支持队列了,最近要编译一些东西,版本支持不足,于是决定升级到12.04。

    源列表直接更新成12.04的,然后dist-upgrade,结果出了很多奇奇怪怪问题,主要是python的依赖问题,原来的2.6升级2.7,而装2.7又依赖自身,自己编译了一个跑起来了,最后遇到了一个终极错误:Could not perform immediate configuration python2.7-minimal。 搞了半天解决不了,

    后来发现原来在apt-get命令里加上-o APT::Immediate-Configure=0暂时禁止检查即可。

    另外ubuntu升版本确实问题多多,还遇到很多相关检查版本失败的问题。可以通过修改
   /var/lib/dpkg/info/packagename.*相关文件来使其返回0让相关检查强制通过


Tags:
    今天baidu app engine(BAE)上线了应用防火墙功能,可以设置ip黑/白名单,设置单个ip的5分钟/24小时内请求数/请求流量限制。可以有效防御攻击。

    进入应用管理页面后,点击“应用管理”,页面中会看到“防火墙设置”,进入页面后即可进行设置。

    首先可以点击按钮开启和关闭应用防火墙,只有开启后防火墙各项设置才会生效。

    然后可以设置ip的黑白名单,支持以子网掩码的方式设置ip段。可以设置的数量为100.


    对于有攻击发生时,可以设置每个ip在不同时间周期内访问的次数和流量,对于超出的予以封禁,返回403错误。

    页面下方可以查看封禁情况,并可方便的把封禁的ip加入黑名单中。使用十分方便。




Tags: ,
    之前经常拿来备份数据的企业邮箱满了,而qq为了赚钱不让企业邮箱扩容了,所以没办法,准备换成可自动扩容的qq邮箱。但发现一些大邮件无法收到,查看mail.log后发现发送超时。错误信息:
dsn=4.4.2, status=deferred (lost connection with mx3.qq.com[119.147.6.81] while sending message body

而用企业邮箱的时候从来没有这个问题,排查了下,把postfix发送超时设长,无效,还是发送一分钟后就超时,看来是qq的mail服务器设置了1分钟超时,如果1分钟内邮件发送不完就断开连接。

    tracert了一下到两个邮件服务器的路由,前若干跳都是一样的,但后续设置了禁ping,无法得知具体路径。

    看来我的机器到qq邮箱mail服务器速度比较慢,而到企业邮箱速度快,有可能是qq邮箱设置了速度限制之类的东东,只能给企业邮箱开自动转发,把邮件中转一下了。



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