Shell's Home

context切换测试——线程创建有关部分请求review

Oct 31, 2014 - 1 minute read - Comments

线程模式开销 使用t_thread程序,循环1M次,重复6次,原始数据如下: 9.57,8.22,21098,0,0,0,104% 9.77,8.40,29704,0,0,0,104% 9.36,8.17,10390,0,0,0,106% 9.56,8.50,14514,0,0,0,107% 9.35,8.34,7244,0,0,0,108% 9.57,8.43,26351,0,0,0,106% 统计结果如下: time mean = 9.53 time var = 0.02 kernel mean = 8.34 kernel var = 0.013 解读数据可以看到,thread模式的开销为9530ns(已经降到纳秒级了),CPU将为8340ns,精确级别在20ns级别。粗略换算一下每次create的开销大约是30k个时钟周期。简单对比可以看出,thread模式比fork模式大约快了5倍。

context切换测试——调用开销有关部分请求review

Oct 30, 2014 - 1 minute read - Comments

函数调用开销 使用s_call来测试性能,循环1G次。 2.35,0.00,17,0,0,0,99% 2.34,0.00,13,0,0,0,99% 2.34,0.00,10,0,0,0,100% 2.35,0.00,10,0,0,0,99% 2.34,0.00,14,0,0,0,99% 2.34,0.00,6,0,0,0,99% 统计结果如下: time mean = 2.34 time var = 0.000022 每次call的开销为2.34ns,约7个指令周期。当然,这些并没有考虑调用压栈和数据返回。 内核调用开销 使用s_syscall来测试性能,循环1G次。这里特意选用了一个不可能失败的内核函数,getpid,来衡量每次进入getpid的开销。 4.37,0.00,76,0,0,0,99% 4.34,0.00,43,0,0,0,99% 4.37,0.00,124,0,0,0,99% 4.37,0.00,63,0,0,0,99% 4.36,0.00,48,0,0,0,99% 4.36,0.00,47,0,0,0,99% 统计结果如下: time mean = 4.36 time var = 0.00011 这里可以看到,纯粹的内核进入开销小到非常惊人,只有4.36ns,约合13个指令周期,而且这里还要进行数据的查询和返回。所以内核调用开销在下面的测试中全部忽略不计。

context切换测试——python有关部分请求review

Oct 29, 2014 - 1 minute read - Comments

python yield模式性能测试 python下的测试就不用time了,我们改用python的timeit,循环100M次。具体可以看py_yield.py。数据结果如下: 7.64262938499 9.2919304393e-06 5.41777145863 4.94284924931e-06 从结果来看,100M次循环的平均时间是5.4s,平均每次大约54ns。使用yield后变为76ns,增加了22ns。 python greenlet模式性能测试 这次代码在py_greenlet.py,循环10M次。数据结果如下: 5.35270996888 7.44085846125e-05 5.31448976199 5.82336765673e-05 单次循环时间消耗为535ns。比最初的54ns,增加了481ns。基本来说,时间增长了10倍率。 这是预料中的,因为greenlet早就声明自己通过堆栈拷贝来实现上下文切换。这会消耗大量CPU时间。从原理上说,栈越深,消耗越大。但是测试结果表明两者几乎没有差异,栈深反而性能更加优异(TODO: why?)。

context切换测试——进程有关部分请求review

Oct 28, 2014 - 1 minute read - Comments

测试环境 Intel® Pentium® CPU G2030 @ 3.00GHz 8G内存 debian jessie Linux 3.16-2-amd64 2014年10月27日 附注一下,该CPU有2核心,无HT,1ns3个时钟周期。 测试方法 测试代码如下: time -f "%e,%S,%c,%r,%s,%K,%P" ./perf_fork 数据的意义分别为: 总时间,占用CPU时间,context switch次数,读/写次数,内存耗用,CPU使用百分比。 数据处理方法如下: import numpy as np p = lambda s: [float(line.strip().split(',')[0]) for line in s.splitlines()] q = lambda s: [float(line.strip().split(',')[1]) for line in s.splitlines()] np.array(p(s)).mean() np.array(p(s)).var() np.array(q(s)).mean() np.array(q(s)).var() 进程fork开销 使用s_fork程序(注释语句关闭模式),粒度1M次,重复6次,原始数据如下: 49.04,26.83,29784,0,0,0,55% 51.53,26.38,32057,0,0,0,52% 49.88,26.02,30892,0,0,0,53% 51.39,27.13,37573,0,0,0,54% 52.89,28.12,37924,0,0,0,54% 51.19,27.02,35880,0,0,0,54% 统计结果如下: time mean = 50.98 time var = 1.52 cpu mean =

bash严重漏洞

Sep 25, 2014 - 1 minute read - Comments

今天估计各大消息都在报这个漏洞,可能有些人看到有修复就放松了。目前来看,事情没那么简单。 CVE-2014-6271 第一个漏洞,编号为CVE-2014-6271。相应的dsa和usn。 具体的文章可以看这里。 简单来说,当bash执行时看到有变量定义了一个函数,函数尾部又剩余了部分代码。会直接把剩余代码执行了。导致简单的变量定义动作有机会执行任意代码。 对于未修补的系统,执行以下代码出现以下提示: $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a test 注意echo vulnerable应当不被执行的。 修复的系统则是以下表现: $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test CVE-2014-7169 第二个漏洞,编号为CVE-2014-7169。 这个漏洞是第一个漏洞没有修复完全导致的,最麻烦的是,这个漏洞没有修复,细节却满天飞了。 表现如下: $ env X='() { (a)=>\' sh

送书

Sep 4, 2014 - 1 minute read - Comments

最近清理家中藏书,打算送掉一部分纸质书。于是顺手列了一批自己需要,但是可以外借的书。 送人的部分,如果你需要,两个月内联系我,自己想办法拿走(例如H4,或者直接上门)。逾期我就直接送去资源回收了。借阅的部分,记得好好保管图书,不管借阅多久,记得回头还我。 送人 delphi 5.0 开发多媒体应用 ISBN 7-5084-0470-X C++语言程序设计 ISBN 7-302-03926-7 计算机绘图 ISBN 7-313-01482-1/TP.273 borland C++ windows程序设计 ISBN 7-115-05265-4/TP.117 最新C++语言精华 ISBN 7-5053-3975-3/TP.1731 C++语言程序设计 ISBN 7-302-04504-6 C++使用手册 ISBN 7-5053-2890-5/TP.959 microsoft visual C++ .net技术内幕 ISBN 7-302-08931-0 操作系统教程 ISBN 7-04-012664-8 借阅 模式识别 ISBN 7-121-02647-3 深入解析Windows操作系统 ISBN 978-7-121-03969-0 计算机网络 ISBN 7-302-08977-9 深入浅出MFC ISBN 7-900614-93-1 Python源码解析 ISBN 978-7-121-06874-4 数据结构与算法(Java语言版) ISBN 7-111-11902-9 网络渗透技术 ISBN 7-121-01035-6 密码编码学与网络安全 ISBN 7-5053-9395-2 人工智能及其应用 ISBN 7-302-02127-9 神经网络原理 ISBN 7-111-12759-5

如何分辨网站真假

Aug 19, 2014 - 1 minute read - Comments

老婆想去新疆玩,结果她居然从百度上搜了一下新疆国旅就联系开了。我一直不知道,直到她和我说,对方要求缴500元到一个支付宝帐号里。我立刻要求她不要付钱,然后开始查证真假。 第一家网站 她开始给我的是这家:http://www.17xjly.net/。 老规矩,先whois,再dig,再whois。 whois域名的结果是没有任何信息?! dig后的IP是113.10.247.20。再whois一遍,发现服务器在香港。此外也没有任何信息。 ICP是新疆的,查全国ICP登记无信息。 开始想不通,这家伙在新疆背景这么深厚?突然醒悟过来。这家伙是个.net域名,注册地不在中国,服务器不在中国,凭什么要人家ICP备案啊。就因为号称是新疆的网站? CAO,这种网站给的支付宝,鬼知道打进去会发生什么。。。 第二家网站 百度上排名很高的是这家http://www.yuyutrip.net/和这家http://www.yoyotrip.net/。两家的页面很像,但是又明显有区别,不知道是竞争对手还是什么。 老规矩。 whois域名的结果是这个: Registrant State/Province:Shanghai Registrant Name:shxg shxg 注册地上海? dig了更好玩。这两个域名的IP指向是同一个。121.52.217.137。再whois发现是这个: netname: TopnewNET descr: Beijing Topnew Info&Tech co., LTD. 没听说过。 ICP倒是有: 北京博通天下网络技术有限公司 U旅商旅网 2013-06-09 咳咳,漏底了吧。虽然号称国旅,但是是一家北京公司在上海注册的域名。 好玩的是,这家网站上面给出的地址,是真的(具体后面会说)。但是电话却不对。 真的国旅 google出手,马上就有。结果是这个http://www.cits.com.cn。 老规矩。 whois域名可以看到这个: Registrant: 中国国际旅行社总社有限公司 注册者看着就很NB。 dig一下,发现IP是这个,219.143.192.35。这个IP可牛逼了。whois一下: inetnum: 219.143.192.0 - 219.143.192.255 netname: CITS 我擦,专属C类IP段! ICP查询后结果是这样的: 中国国际旅行社总社有限公司 国旅在线 www.cits.com.cn 2014-07-23 www.cits.net 2012-11-29 这个网站上有400电话,打过去说新疆只有团体游。不过人家给了正确的地址和电话,和第二家网站的地址一致,电话却不一样。 事情到这里,我的基本判断是。和第二家网站做生意还是有点谱的,ICP是真的,地址国旅也认。最低限度,他至少是一家合法的旅行社——虽然不保证是国旅下属。第一家么,谁爱信谁信。 上海国旅 后面有点更好玩的事情。国旅在线上有上海,而google查询结果上也有不少上海国旅。那么谁是真的呢? 上海国旅1 例如这家http://www.scits.com/。 域名的whois是这样的: Registrant Organization: SHANGHAI CHINA INTERNATIONAL TRAVEL SERVICE CO.,LT Registrant City: shanghai dig后发现IP是210.14.68.234,再whois是这样的: netname: SVA descr: Science & Technology Network Communication Co., Ltd.

服务器操作系统的选择

Aug 14, 2014 - 2 minute read - Comments

今天被LTN问了一下怎么看一个知乎问题: 服务器操作系统应该选择 Debian/Ubuntu 还是CentOS? 其实我觉得他的大部分说法都没有错。如果你需要装一个服务器,确实首选是RH系的。 但是。。。 选用RH系的主要理由 其实你把回复从头看到尾,主要论点就一点: 哪个发行版,可以在长达7-10年的时间里,始终保持硬件稳定性的同时,又持续的升级补丁? 结论当然是RH!这是RH的主要卖点。 我们真的需要长达7年的硬件稳定性支持? 咳咳,今年上半年,蔽厂的运维碰到了这么一件尴尬事。 他们进货,去机房装系统,配置网络结构,加入运维管理系统,添加监控,交付。除去采购外,整个一套流程大概是一周。 我们在机房里面原本大约有10个机柜,那么一般扩充的时候,一次扩充一个机柜。 结果今年上半年的某一段时间,一周一个机柜的事情持续了两个月。运维同学辛辛苦苦装好一个机柜,周末打算轻松一下。被老大通知,又来客户了,机柜又不够用了,下周继续。 是的,我们现在20个机柜不止。机房有多少机柜我不知道,不过照这个趋势来看,我们快把机房包下来了。现在我们的带宽已经没有限制了,每个月月底按照合同秋后算账。 我们有一些有三年历史的服务器,台数不多。现在来看,性能已经远远不够。CPU不够快,也没有SSD,硬盘读写次数也太多。这些机器的下场,多数会被换下来折旧卖掉,或者作为测试服务器,搬去测试机房。而现在机房里面大半机器,都是两年以下历史的。而且至少一半服务器历史不超过半年(。。。)。从现状上看,把老服务器留在机房,其性价比并不合算。因为机房有机架密度问题,限制着我们的单机房极限,这相当于变相的租金。 如果考虑到这点,我们的线上服务器生命周期大概也就三年。最多。很多时候甚至还不到。 比我们更极端的是页游。他们的一组服务器生命周期一般是半年。半年内,要赚钱的也赚完了,不赚钱的也死完了。所以他们甚至不会新采购硬件服务器,而是直接使用虚拟机。 当然,虚拟机内的系统,支持时间是一年还是十年,对他们一点意义都没有。 为什么我们不喜欢三年以上的系统? RH系的提供10年级别的维护性,我换个说法,也就是最近的软件在RH的官方库里面找不到。当然,装最新的RH是有的,但是在安装了三年的一个系统上?肯定没戏。 怎么办?编译呗。 这大概就是国内谈到RH必编译的由来。 可是,我引用文内的一段话。 如果我今天告诉大家,我要做一个 http 的服务器,我不用 apache 不用 nginx, 为了性能我要用 xxx 为基础重写一套出来。我相信绝大多数人会问同样的问题, “你觉得你写的能比 ng 好么?” 再回头看看那时候你们自己吧。 同样,自己编译的软件,补丁维护速度,能和新系统比么?而且我们还得扔一个人下去搞补丁维护。 所以,正解是什么? 装一套新的,把数据导过去用呗。 我们的”数据“,都是装载在磁盘上的。而换”系统“并不需要更新这些数据,只要把系统盘擦掉重部署一遍,然后配置好deploy系统就OK。在开发之初,”环境“,”程序“和”数据“分离,就是一项基本原则。而且即使是”数据“,丢掉一台机器上的所有”数据“也不会构成问题。这应当是运维基础中的基础。只有少数几台服务器,既不能直接更换也不能停机。这些机器我们做特别的管理。 为什么蔽厂使用Ubuntu? 很简单。因为最初的开发希望在Linux上进行。直接在Linux上开发和测试,对于startup的快速开发是非常重要的。而开发用什么版本,服务器跟什么版本,这是最省事和好办的。如果你硬要和我争,说开发在Mac上,跑在Linux上一点事都没有。或者说开发一个发行,服务器一个发行也OK。 我至少得说这对于golang和python都不是事实。除非不用cgo,也不用python的C扩展。 先不提Mac下和Linux下的差异。我们今年在升14.04的时候就发现,12.04和14.04的编译互不通行。所以现在12.04的编译可以程序员自己编译了本地测,14.04的就必须在测试环境里干。一帮程序员远程tcpdump出结果,拷回本地wireshark一把。。。 看看就蛋疼。 当然,这也有个问题。就是上面”我们不喜欢三年以上的系统“。所以呢。明年我们的系统大概会轮换重装,14.04。。。 也很蛋疼。 Debian系的补丁不靠谱么? 那要看和谁比。这里有HeartBleed事件的统计。虽然不普遍,但是我觉得这种大漏洞比较有代表性。 CVE-2014-0160 - OpenSSL安全漏洞的非技術事件 我引用他的重点整理: RedHat 修復的速度比 OpenSSL 官方還快。 RedHat 派系的修復時間,除了 RedHat 外都算慢,如 Fedora 及 CentOS、Scentific, 他們都比 RedHat 慢 16 小時以上。 Debian 派系的修復時間,如 Debian 及 Ubuntu,都比 RedHat 慢上至少 12 小時以上。 Scentific 是列表中修復最慢的。 若以資安黃金 6 小時來說,Fedora、CentOS、OpenSUSE、Gentoo 及 Scentific 都不及格。 如果和RH比,Debian的修复速度是不及格,但是和CentOS比。。。怎么说呢?6个小时对10个小时,有种五十步笑百步的味道? 换你你愿意走几步? 另外,我也不知道原文说的升级一大包是怎么回事。我在Debian stable上查询ssl: $ dpkg -s libssl1.0.0 Version: 1.0.1e-2+deb7u12 Depends: libc6 (>= 2.7), zlib1g (>= 1:1.1.4), debconf (>= 0.5) | debconf-2.0 但是同时。 $ dpkg -l | grep libc6 ii libc6:i386 2.13-38+deb7u3 i386 Embedded GNU C Library: Shared libraries libc的依赖早就满足到不能再满足了。直到今天为止,openssl在debian上的升级还不需要你强制跟随升级libc6。而kernel根本没有依赖。 纠正原文的一点理解错误 Debian 是由社区维护、贡献的发行版本,其从选包、打包、都是由社区组织,分散行动的。 Debian 是没有真正意义的 release 概念的。Debian 有众多仓库,stable,testing, unstable ,experimental.

架构师

Aug 13, 2014 - 1 minute read - Comments

一个好的架构师至少要做到四点: 识别甚至提前预测到程序不同阶段的性能瓶颈,并以合理的代价消除。 识别束缚程序员生产力发展的瓶颈,并合理的消除。 解决组里面的尖端问题。 成为组员的精神支柱和旗帜。 他不应该: 总结需求。这是产品经理的事,除非他兼任。 评估工作时间,并保证工作进度。这是项目经理的事,除非他兼任。 召集,协调工作细节。这个随企业有不同划分,理论上是行政领导干的。有的企业是技术系的来做行政领导,有的是PM。 亲自写程序。除了初创,架构师亲自冲上去写大段大段的程序是找死的先兆。 预测技术的发展方向,并做出技术决策。您让CTO干什么去? 政治斗争。架构师也来搞这个,要么被搞死,要么根本没心思做事。 但是架构师应该理解办公室政治,并且能够基本掌握情况。一点办公室政治都不懂的架构师肯定被搞死。

14年7月,无甚大事

Jul 30, 2014 - 1 minute read - Comments

这个月比较忙,啥都没说。堆月底做个总结吧。 空难 一个月三起,马航又来一次。我都不知道该说什么了。也许今年就应该避开马航,马英九。 马航空难就是一场悲剧,不仅对所有在空难中身亡的人而言。看到现在基本也看出来了,乌克兰政府,反抗武装,俄罗斯三个当事主体互相扯皮。调查人员进场缓慢(不知道是不是受到阻拦),现场破坏严重。将来就算调查出了结果,也完全可以抗辩说调查结果没有任何公信力。看来这个案子只能等待某国档案解密之时才能确认了——虽然我们都应当在心里确认了真相。 话说回来,确认了又能如何呢?美国不想陷的太深,欧洲有心无力,马来西亚?丫管个P事。也许今年马来西亚请巫师过来是对的,只是不应当找人,而是应当给他们自己的政府和航空去去祟。 另外两起空难暂时没啥想说的,等调查报告吧。 向所有在空难中死亡的人表达哀悼,祝他们在天国(具体地点视个人信仰)中安好。 显示器 又败家了。买了台显示器,型号VG2233-LED。优派的,22寸。最大特点是800元价位上内置了屏幕旋转,可以把屏幕转成垂直的(是的,就是一大长条)。程序员都理解这样做的价值。就算不是程序员,用来看看网页什么的,尤其是超长网页,也非常爽。 下面说说问题和需要注意的点。首先,这块屏幕是TN的(废话,这个价位难道还想用IPS么),这就造成垂直视角非常有限。而转起来后,很不幸的,就变成了左右视角。于是当你偏一点头去看的时候,会发现色彩亮度都不对了。 不过幸好,对程序员而言,这个问题并不致命。程序员既不会用这块屏去欣赏某些视频,也不会在写程序的时候左摇右晃,甚至跳一曲小苹果。 另一个细节是,你先看自己的显卡和window manager是否具备旋转屏幕的功能。虽然大多数显卡都有,但是少数(尤其是集成显卡)在旋转屏幕后性能很差。我在旋转屏幕都打开屏保,能明显看到卡顿。幸好,写程序也是没影响的。至于window manager,其实包括整个系统。我在用lxde的时候发现一个细节问题——lxpanel会把panel横跨整个虚屏幕。在旋转屏幕的情况下,另一块屏幕无法显示panel。而如果把另一块屏幕对准下沿,应用程序的title就会显示不出来。于是我只能强制panel的长度来避免这个问题。 汕头 今年去汕头玩了,具体就不写游记了,因为写不出来。如果我把游记详细的写出来的话,你们一定会以为是美食流水帐,并且质疑我报复社会。 所以我就数一下我吃的美食吧。 牛肉丸:当地特产。据说要人工用大锤子把牛肉打成酱来做。机器打出来的会发硬,不好吃。所以这算是在地(因为要离养殖地近)食品加工业,而且是劳动力密集行业。我问了问能不能带点回来送人,他们说只能抽真空。要买抽真空产品还不如直接在淘宝上买呢,还不算我们回程的携带重量。 鱼丸 鼠壳粿,厚粿:很当地特色,鼠壳粿甜的,厚粿似乎是放了某种海鲜。 广场豆花:他们的豆花是一整块一整块的,放很多红糖。很好吃。当地朋友说,每天就卖两桶,卖光就没了。我们吃的接近第二桶底。 水果冰:3-5元,现榨。比起上海来简直是白送一样的价钱。 牛肉火锅:当地牛肉很多,而且很好,所以很多人喜欢吃牛肉火锅。把牛肉放在网勺里面,在锅里面涮到半熟就捞起来吃。基本和北京涮羊肉一个思路,就是猛火滚汤快下快上。味道非常赞。当地对牛肉不同部位非常讲究,讲究到我根本认不出这些部位在哪里。反正去的话一定要吃啦。 炒冰:很有创意的想法。把现榨水果汁,放在一个制冷盘子上。随着下面大机器的高速制冷,整个水果汁就会变成一块块薄的冰片。拿一个小铲子铲啊铲的,确实很像炒菜。这样可以自己随意调和水果汁,做出不同口味的炒冰来。 总体来说,潮汕还是非常好玩的。对一个吃货而言,如果去不了台湾,就去潮汕。