见谁侃谁

关于潜水

2012-08-28T20:18:00.000-07:00

有个群里面聊到深潜，就是所谓的Scuba Diving。这个玩意儿是要考证的，没有证人家是不让你去潜水的。实际上办法证件的有两个主要组织，一个叫做PADI，另一个叫做NAUI。

PADI = Professional Association of Diving Instructors
NAUI = National Association of Underwater Instructors

前者是一个商业组织，以营利为目的。后者是一个非盈利组织，以兴趣爱好聚集在一起，不过这并不意味着不收你的钱。这两者据说前者的各种收费会多一些，但是装备和支援也会好很多。也有不少的有钱人两个证都会考……有钱人啊。

这里说一下PADI的几个主要的证，分为：
DSD = Discover Scuba Diving
大概就是带你到一个大泳池（深水），然后简单教一下，教练带着你潜一回，全程30分钟。这个玩意儿嘛，没啥意思。估计就是让你尝尝鲜，直到水肺潜水是什么个感觉。当然，最后可能也会给你一个什么证，只是这个证你不能在大海里面潜水的地方拿出来使用。所以，如果你真的想要潜到海底看看海底的生物，那么还是忘了这个课程吧。

OW = Open Water
顾名思义，就是开放水域。全程需要在课室、泳池先学习一下，然后要完成4次潜水，有的教练还会考笔试，证明你这4次潜水都认真的完成了联系。据说有网上课程，允许你在1年内按照你自己的意愿和规划来完成。这个课程主要是教你如何处理你的装备，以及在水下和水面如何控制身体等。据说一个课程下来是3-4天。不过，这个还是不能够深潜，要深浅的话需要完成下面一个课程。

AOW = Advanced Open Water
这个就高阶一些了，会教你深潜、从船上入水、夜潜、沉船潜水等，有很多的险等着你去探哦。不过是不是所有东西都要学了才能拿到证，这个就不清楚了。本人并非高富帅……据说课程也是3-4天。如果和之前的一个联合一起弄的话是7-10天……咦？为啥更长了捏？老实说我不知道，人家高富帅是这么说的。

当然了，还有很多更高阶的课程，至于还有什么，请自己搜索吧。

（一套装本好贵啊，入门单反一套都下来了。关键吧，那个气瓶……不像SD卡可以免费拍了删删完再拍的啊！还有那个潜水地点，呃，也是要Money的啊，不像是扫街是免费的啊！）

另类的智商考验

2012-08-09T02:01:00.000-07:00

前阵子和讯网在新浪微波上面发了一个叶诗文兴奋剂争议有关的帖子，里面称一氧化二氢是增强能量并导致获金牌的重要原因。结果里面有若干人不冷静，没智商的中招大骂其教练无耻，最后导致一干人等围观。甚至最后这位冒失的同学还把自己的微博名字给改了，大概是受不了大家的围观目光了。

一氧化二氢是水，这个大概能够有足够多的人（其实也不多，能够有33%就不错了），能看懂并欢乐的围观。但是后来另外一个帖子，就一片的高级黑。这个帖子的内容如下：

这里面的笑点在“血脑屏障”。什么是血脑屏障？实际上就是脑血管的致密屏障，主要作用是组织大分子进入脑部，避免影响脑部的化学平衡（否则大脑功能会紊乱）。这里面的大分子，显然不包括水、酒精这里一类低分子的物质。换句话说，血脑屏障无法阻止酒精进入大脑。也就是说，压根就不存在“在碳酸作用下”，导致酒精更“容易通过血脑屏障进入脑内”这一说法——本来就可以轻松进入。

CO₂ + H₂O ⇌ H₂CO₃
实际上，碳酸饮料的碳酸，实际上就是二氧化碳和水的结合体。而且碳酸这种物质本身极不稳定，受热、晃动就会分解为二氧化碳和水。事实上因为碳酸极不稳定，所谓的碳酸饮料并非直接使用的碳酸，而是用俗称小苏打的碳酸氢钠这种强碱若酸盐。这种强碱弱酸盐在喝到体内后，会在胃中发生如下的反应：

NaHCO₃ + HCl → NaCl + H₂CO₃

H₂CO₃ → H₂O + CO₂↑

也就是说，碳酸氢钠和盐酸反应变成食盐与碳酸，碳酸受热分解成水和二氧化碳。这就是为什么你喝个汽水容易打嗝，打不出隔会觉得腹胀的根本原因。所以，当你喝下碳酸饮料之后，绝大部分的碳酸氢盐会被分解成水和二氧化碳，其中的二氧化碳会有一大部分排除体外。从这个角度讲，也没有任何道理说碳酸会影响血脑屏障。

即便由于胃酸不足，以及二氧化碳再溶于水的角度考虑，有部分的碳酸会进入血液，那也不可能对血脑屏障产生什么重要影响，这是因为有血红蛋白的存在。血红蛋白的主要作用是氧气的运载，这个大家都知道。但是大家不知道的是，二氧化碳也可以和血红蛋白结合，并且还是导致与血红蛋白结合的氧气的释放的重要原因。也就是说，如果血液中的二氧化碳与水结合形成碳酸根与氢根，这两者水平较高的时候会争夺血红蛋白当中的结合点，挤出氧气。有一种病叫做“二氧化碳中毒”，就是这一原因引起的。而水肺潜水也需要通过某种方式将呼出的二氧化碳移除，否则将会导致中毒。

血液中的二氧化碳含量的上升，会导致另一个作用：换气速度加快。这是一个正常的反射作用，也很容易尝试：找个人捂住你的鼻子和嘴巴，很快你就会非常想要呼吸，放开后你会高频率的喘气。

也就是说，如果碳酸饮料中的碳酸即便能被吸收，也会通过血液予以排除。这些通过肠道吸收的二氧化碳数量，与你身体呼吸作用所产生的二氧化碳量相比，简直微乎其微。否则，大概你一喝下雪碧，就该不停地喘气了。

其实这些东西并不是特别难理解的，甚至很多都是高中化学必学的部分。可是：

当然，也有一些看到笑点的，比如：

那么，喝酒的时候和碳酸饮料是否会导致不适呢？确实有可能，这是因为释放的二氧化碳会撑得你的胃难受。同时，由于胃部被撑大，可能导致下列的一些后果：
1、贲门受不了压力被撑开，是为呕吐反应；
2、幽门受不了压力被撑开，酒精迅速流入小肠，迅速提高血液中酒精的浓度；
3、贲门、幽门都顶住了压力，胃部表面积被撑大，酒精吸收效率增加，迅速提升血液中酒精的浓度；

如果你仍然不相信碳酸和血脑屏障没有任何关系，那么你记得在喝酒的时候一定要做深呼吸，尽快排除体内呼吸作用所产生的二氧化碳。否则这些二氧化碳在血液中形成的碳酸会导致你的血脑屏障大开，导致酒精通过太多头痛死。不过请不要忘了，还有一种叫做低二氧化碳血症的呼吸中枢抑制症。搞不好会因为你的脑干抑制你的呼吸，最后窒息致死哦！

一些极细微的习惯

2012-08-07T20:53:00.000-07:00

人是否能赢得大家的尊重，其中一个因素是你对待一些可能影响他人的细节是如何处理的。当然，除了自己的行为习惯之外，大众的行为习惯也是重要因素之一。

最近公司突然很多人感冒，其中有几位严重到发烧，最后只好请假不来上班。对此大加笑谈A君是传染源，因为他之前也病了。然而就在大家说这个笑话的时候，B君大大的打了一个喷嚏，就如同之前连续好几天一样。我突然意识到，B君已经每天准点在下午的时候要打那么一两个喷嚏。之所以记得住，是因为每次打完喷嚏都能闻到一股浓浓的口水味飘过来。这怎么成，吸别人口水感觉恶心不说，还可能导致被传染。于是每次我就需要屏住呼吸，等待着股味道渐渐地散去。

其实这真是一种习惯问题：打喷嚏的时候应当避免对着别人，用手或者手绢纸巾掩面，可以减少飞扬的唾沫数量，减少传染的几率。这种东西理论上大家都应该知道，只是形不成习惯而已。人生来就是利己的，因此不是有利于自己的事情——比如是否会导致别人生病，是从来不会容易被自己意识到的。但只要你这么想：一个打喷嚏不捂嘴的人，别人会闻到，会觉得你恶心。打喷嚏的时候稍微捂一下，至少别人不会这么看待你。

其实这种“大家都知道，但是却总有很多人不执行”的例子真的不少。就在B君打完喷嚏之后不久，C君一口痰就吐在了垃圾篓里面。我立刻想起来小学的时候，楼道里还有所谓的痰盂，痰盂上面是有一个盖子的，盖子上面还有一跟长长的木棍。当时小学老师都会教：痰要吐在痰盂里，吐完了要盖上，因为痰干燥之后细菌可能会随风飞扬，传染疾病。当然了，裸露的痰盂必然不雅观。这些真不是什么闻所未闻的知识，但总有很多人是随便吐在开放空间如垃圾篓里面。尽管有塑料垃圾带罩着，不像以前那样总会搞得脏兮兮的、恶心兮兮的，但传染人的可能性并不会因为这个垃圾袋而减少。这种问题还真不是一个两个，比如我们家就有亲戚是这样。这与他们平时生活的环境有关——大家都是这么干的。也许这就是所谓的“垃圾场效应”或者“破窗理论”在作怪，要打破还真是不那么容易。（打破容易，但不伤面子的打破却很难。）还有很多人随街一吐，然后好像从来没发生过什么一样，该干啥干啥。这在我看来非常令人诧异的，但主角却完全不会感觉到。

比随便乱吐痰相比，另一个让人尴尬的问题是放屁。中国有句俗话叫做“管天管地，管不了拉屎放屁”。意思就是说，这些都是极正常的生理现象，而且还不能强制取消（比如憋回去）。然而，人总是可以有选择的——比如忍住，然后挪到人少的地方在释放。也许你会说，忍住很难，有时候不经意就出现了。其实，这还真不是——你会不经意就尿了，拉了？除非你有大小便失禁的问题，否则一般来说，大多数的屁你还是能提前感觉到的，这仍然是你愿意不愿意的问题。否则，你怎么解释有的人会站在对着你吹的风扇，前若无其事的放一个长达一分钟的响屁呢？我还真遇到过，当然，主角根本不知道自己做了些什么。

在饭桌上，这样的问题也不鲜见。我们有一帮人一度经常在一起吃饭，其中某位D君一直有一个习惯就是拿起筷子颠来倒去的在菜碟当中拨菜肴。而这个动作并非夹取某一块肉的前缀，很多时候只是为了拨一下，然后筷子往嘴里一放，嘬完筷子之后放下继续和大家交谈。最终的结果就是，这盘菜的每一个可以吃的部分都被拨过，大家只好放弃这一盘菜了。其实，口水当中含有大量的细菌，筷子在菜里面交错的越多，传染疾病的可能性也更高。以前还会提倡在公共食堂当中使用公筷，正是基于这一道理。这也是一个常识，只不过有些人习惯如此，因为他们从小周围的人就是这么干的。有一天我们都忍不住了，委婉的跟D君说这不太好，D君很诧异的说：啊？这不是表示和大家很熟悉很友好吗？

实际上，对于外国人来说，中国人在这方面就很难以理解：不仅仅用筷子在同一盘菜里面倒腾，还有所谓share food这么一说。其实这种不良习惯应当说大多数中国人都有，甚至我自己到了国外旅游的时候，某个餐厅的老外服务员曾问我们，是否需要Share food。当时我还很欢乐的答应说是，于是服务员多给了一个碟子。现在想想，还真不知道人家是了解了我们的习俗，还是故意调戏的。当然，这还算是好的了。甚至可能大部分地区还有这样的吃饭习惯：
桌子上发一个小勺，用于盛菜，而碗则是用来盛酒的。如果遇见了什么想吃的，甚至可以直接拿小勺勺菜，然后往嘴里面一送，如此往复。如果感觉到这么做太麻烦，甚至可以直接拿起某盘菜直接往嘴里一送，稀哩呼噜吸吸，就把汤汁喝下，喝完了之后把剩余的菜肴继续摆回桌面。其实这真不怪大家，大家都是这么做的，没什么可奇怪的。于是，在老外的鸡尾酒会上面，中国客人通常容易遭人嫌但自己还不知道，在那里不亦乐乎的拨弄食物。

其实要注意的细节真的很多，比如不要当众抠脚趾，不要随便乱穿马路等。这些种种其实已经是最低的要求了，大家都知道，只不过不做而已。有没有同样最低要求，但是大部分人都因为不知道所以不做的呢？也有，那就是随手要注意门。

这个注意分为两种，一种是关，还有一种是开。先说随手关门，我遇到的包括了开大会当中有人因事需要出去，结果开门就走，也不晓得关门。很多时候这回引起别人的尴尬，比如我要在会上说一些较为机密，或者可能容易引起其他部门同事误会的事情。可当事人一点都不觉得，概因大家通常就只想着自己的事情，而不考虑别人的感受。

如果随手注意关门这个小习惯可能知道的人会多一些，注意开着的门则很少人知道。在出国旅行之前，曾经听说外国人在开门之后会注意后面是否有人，否则自动弹回去的门可能会伤及随后注意力分散的行人。甚至，外国人会觉得你理应如此，因此并不会注意用手挡住前人已经打开的门。这算是一种绅士的行为，我也表示认同。在国内，我就开始时刻提醒自己要注意这一个问题，并且实践之。然而，这种长年累月下来只关心自己是否顺利通过的习惯，总是会时不时的跳出来。终于，在澳大利亚的无数次开关门中，就有一次我忘了这回事，结果玻璃门当的一声打在了后面的小女孩脑袋上。我记得十分清楚，当时自己其实是回头看到后面来了一个妈妈带着一个小女孩，可潜意识里面就觉得人家要伸手当门，因此就没有像往常一样挡住已经打开的玻璃门。结果果不其然，老外根本就没有这么一个“挡住已经打开可能随时会弹回来的门”的习惯，着实的打在了欢快地跑在前面的小朋友的脑门上。我立刻重新打开门，连说对不起。同样印象深刻的是，小朋友一点也没有哭，也没搭理我。大人则抬起下巴傲慢不满神情，仿佛视我至于无物，大踏步走开了。

正是这一个活生生的经历，让我意识到注意可能影响别人感受的细微习惯，是赢得别人尊重的起始点。大家觉得呢？

记鄂尔多斯团建（28日上午）

2012-07-31T21:04:00.001-07:00

第一天的会持续到1点多，回到宿舍倒头就睡。即便如此，第二天早上7点多醒来的时候，仍然是非常的困。而集合时间是8点整，于是匆忙跑去吃早餐。三两口的还没有吃饱，集合时间已经快到了。作为新闻记者的我，怎么能够缺少一个早餐的照片呢？于是乎掏出相机，换成定焦，咔嚓一拍，就有了上面这个价值至少200元人民币的照片——因为迟到两分钟，一分钟一百块。

其实我们这次去的地方，还真是途径了黄河的支流，看这条河得有多么的黄啊。好吧，其实就是一条小小溪流，据说不下雨的时候，是木有水的。

之前下了雨，连沙子看上去都是湿漉漉的。真的，这里真的是沙漠。

不然，怎么会有骆驼呢？

由于下雨导致小黄河出现，我们别无选择只能够坐缆车到达有东西玩的地方。（其实这真是一种智慧：如果修路直接到达景区，你就收不到这笔钱。）

还要做这种东风汽车改装的……舟？（如果实在修不成缆车，也可以参考这种盘剥方式。像这种双管齐下的景区，真少见。）

那种神舟有一种特殊的技能，就是把大家打会原型。有一件事情一直忘了说：你们知道为什么Stan和Johnson的秘书是Joyce和Sindi吗？根据价值观当中的“不确定的事情不说”，我就什么都不说了。真的，我什么都不知道。

坐完神州还要坐火车，艹，基本上所有交通工具都全了。

火车沿途会有一些远程表演节目，实际上人眼看也就如上图这般，想要看仔细了还真不容易。

这个时候大变焦的优势就发挥出来了，仔细辨认会发现演员其实都挺丑的。好吧，意思一下，这个最炫民族风咱也算见识过了。

其实，在遥远的山头上还有一位牵骆驼的兄弟。这个最坑爹，肉眼观察基本上就是32x32大小的一个Icon。（上面的全景图右上角可以看到……）

上一篇的时候有人跟我反映，“好像很无聊嘛”，我说第二天去玩会有聊些。不过说实话，黄茫茫的一篇沙漠，能怎样的有聊呢？于是大家都在想法子有聊，比如说互拍，这就比自拍有聊些。（Stan的那个是D700啊，高感那个好啊！不过好在我不眼馋，眼馋D800。）

除此之外，就算拍拍路人甲这种事情比较有意思了。

如果要说评选最无聊的，估计得算是排排站、秀美腿这种事情了。

或者假装自己会飞。

不过当众表演蛤蟆功这种事情，我觉得还是挺能活跃气氛的。

经过了长途的跋涉，

终于到达了本次活动最有意思的部分：看演员们表演蒙古族抢亲活动的舞台歌舞剧。

这个“蒙古包”内有乾坤，还套着一个“剧场包”。

“这得有多大啊？”看屋顶就知道了。

或者看看剧场内的大小也成。

啥？木有对比看不出？好吧，给你摆上个小银。

废话少说，表演开始鸟。

表演的时候演员基本上说的是蒙语，叽里呱啦的，我表示完全听不懂。大概这跟其他人听我说粤语没啥区别。其实现场表演有普通话解说，边上的屏幕也有字幕。

可是我忙于拍照，根本就没法分出一丁点的注意力来倾听，于是某些场景表示完全没看懂。比如说拿着这么大、这么深的马桶，还有一根这么粗的搅屎棍，这是要干什么呢？不知道为什么，我想到了阿里郎。

遗憾的是，这个表演没有看完，我们又被催着去下一个景点——游乐场。艹，走得鞋底都破了……

出来的时候还看到一个神似坤姐姐的照片，当然，真的不是她本人。照片上的人叫做李瑞什么，印章上的字不会念啊，我是文盲。是李瑞环的妹妹么？

去游乐场的交通工具是骆驼，瞧那天然呆的劲儿，真萌。不过有人说骆驼味儿骚，我怎么没有闻到？悲剧的是，拍完这张照片之后不久，相机就没有电了。原因是前面的表演我录影了，影片太大两个多吉，就不放了。其实我表示那个表演真的很好看，应该看完的。后面的游戏项目简直就是随便啦，全世界到处都能玩得到。据说有一个滑沙项目，沙子还会唰唰响——响沙湾嘛。不过可惜因为与后太潮湿，是听不到声音的。正因为这个原因，以及时间太赶，这个项目没有玩。不过价格据说是20元一次，比新西兰的滑沙贵太多了，新西兰那个免费，你自己爬上滑下，只要你还有一口气，时间来得及，随便玩多少次。我就滑了三回，然后就散架了。

好吧，码了那么多无图无真相的文字，这里用一张萌妹子的照片来谢罪吧。回头再来说说下午和晚上的活动——只有iPhone的照片啦，素质就担待吧。不过据说那个晚餐可真是金碧辉煌，值得期待啊。

记鄂尔多斯团建（27日）

2012-07-31T03:46:00.002-07:00

2012年6月底的时候，得到龙女一枚。住院一周后的第一件事情，就是赶紧买单反，加入毁一生的行列。据说镜头是最大的开支，为了节省开支，我只买了两个镜头，一个是50F/1.4定焦，另一个就是18-300F/3.5-5.6大变焦。刚买了没多久，就接到一个去鄂尔多斯组团打怪的任务，正好可以带上相机去练练。

其实本来我是想悄不知的带着相机去的，结果刘给力同学将我买了相机的消息泄露给了助理Joyce同学，于是我就变成了专职的新闻记者了。

要说这次组团打怪，必须首先说说亲爱的海军同学。海军同学这一次很悲催的当了一回我的司机，要知道他级别可比我高多了。如果有股权这回事的话，拿出来估计可以把我直接拍飞。（好吧，我欢迎来拍，会接住的……能接多少接多少。）

实际上这次活动的两位重要主角之一，是Johnson同学，另一位郑石同学稍后再介绍。大家知道为啥Johnson要穿绿sha儿的衬衫呢？猜猜。

其实我嚼得的吧，和海军同学话最投机的就是Johnson了。你看，红配绿，多般配啊！

其实吧，虽然海军同学没有去成，还是抓紧了机会在机场和Johnson互动了一把——组队打斗地主。不过这一次的大赢家不是他俩，是左边的Fancy同学，据说赢了2000多呢！怪怪，VP们出手就是大方啊！这数字够我买个镜头了快。

这一次去鄂尔多斯打怪，之所以海军悲催的没有去成的根本原因，就是……大家不要想多了，和上面那两个美女没有半毛钱关系……是因为飞艇晚点了，因为鄂尔多斯正在暴雨。于是从南苑机场出发的A团，只能眼睁睁的在候机室呆着。根据blablabla定律，人总是会自动分成两拨的：一拨是赌博的，另一拨自然是发呆的了，比如汤姐和坤姐。

当然，还有天然呆的。不过话说能呆的这么美的，也实属罕见。忘了介绍了，她是Sindi，Johnson的秘书。我没有造谣，大家一定要不信谣不传谣啊！

到了下午2点多，飞艇可算起飞了。下午3点多的时候，就到了鄂尔多斯。接待方排了一辆很大的地精车来接我们——原本预计是要接收AB两团的成员的，这会儿自然是显得其空无比了。

按照原定的计划，我们应该下午就开会讨论打怪的事情。结果这飞机一耽误，我们就改成直接吃饭了。不过，好歹我们也见到了从首都机场坐国航出发的B团成员。据说他们6点多起飞的飞机，飞到呼和浩特头上的时候，因为鄂尔多斯天气的原因，吧嗒一声就迫降呼和浩特了。哦，不对，是备降，备降。当然了，美女永远是社交的中心，看，左边是Allen，右边是另一枚主角Stan同学。（他们都在想啥呢？）

为了表示自己的知识丰富，这里特别告诉大家一个秘密：Stan的来源应该是德语的Stein，意思是石头，中文发音斯坦。估计郑石同学是仔细研究过的，否则怎么就取了一个Stan的洋名儿呢？在PS一句，爱因斯坦的德语意思是一块石头（Ein Stein）。没想到这世界上还有一块这么聪明的石头吧？

言归正传，话说吃饭的时候人们总是会表现的很奇怪，比如说瑛桥同学就突然觉得自己成了朗朗。

平时优雅大方的女猎人们突然也会自己承认自己是二，确实是二。

沉稳理智的志刚居然也抽风了。

更令人惊讶的是，Stan看上了Johnson。

你看他们连吃饭的步调都那么的一致，你就知道他们是互为彼此的天使的。其实海军你没来还真对了，不然你看到这一幕，得要有多麽地桑心啊。哎，海军啊，节哀吧！

我琢磨着这里最正常的应该是这两位助理同学了。哦，忘说了，Joyce是Stan的助理。我真的没有造谣，请大家不传谣，不信谣。（咳，我怎么觉得我写的有点乱……）

俗话说，饭后一支烟，快乐似神仙。应汤姐的要求，抽烟的照片不要脸。（怎么听着这么别扭啊……）

饭后部分人一起组织去散步（知道为什么不能在墙内发吗？），目标是围攻附近的铁西公园（知道为什么墙内不能发么？），据说有音乐喷泉可以拍照（知道为什么不能在墙内发吗？）。

可惜的是时间不足，没看到喷泉，只看到了一小撮不明真相的群众，无组织无纪律的伺机而动。（知道为什么墙内不能发么？总该知道了吧！好吧，我不知道为什么。）

当然，尽管没有拍到喷泉，还是拍到了一些个别的美景。（定焦在这方面就是给力啊！）

你知道散步要用什么态度吗？要“得瑟的卖萌”。您瞧瞧，Stan那个回眸一笑百媚生啊！可惜相机镜头不给力，给拍糊了。（相机高感还是不够，镜头没有防抖，定焦在这方面就是不给力啊！）

Johnson也不甘拜下风，你看，有意气指点江山的范儿吧，可惜就是萌少了点。

看到Johnson那么多照片，海军估计除了两眼放光之外，估计还会琢磨着兴许只是Stan看上了Johnson，Johnson的心还是在我这儿的。那我明确告诉你：放弃吧。

逛完了回来路上，大家还兴致盎然的买了很多红血蓝血——待会儿就要开会打怪了，不被一点估计会被秒的。

该吃吃，该逛逛，该买买，完了该开会打怪了。您瞧，这一瓶瓶水，一只只笔，一张张纸摆的是那么的整齐划一，颜色搭配还那么的合理。这显得我这个业余的摄影师是多麽的专业啊！（好吧，其实都是Joyce和Sindi的功劳。）

开会，就是一件严肃的事情了。

你看，连最不严肃的小姜都成了这副模样了。

连Johnson和Stan都不例外。（海军啊，要是你再的话，你会是什么表情呢？）

有的人还真喜欢在这种场合抢镜头，比如嵋姐姐和Allen。你觉得他们般配么？我觉得挺般配的。

其实出镜来博出位是不够的，要想Dennis那样边开会边吃香蕉才行。你看那销魂的小嘴，想不出位都难了。

还有很多出位的方法，比如舔舌头和摇头晃脑。

像敏姐姐和本伟这种两个五的经典造型，其实已经不流行了。

现在流行的是“竖中指”，以及“二”。（艹，这种表达不同意你的观点的方式是多麽的隐晦啊，我怎么现在才发现呢。）

其实大家为什么要这么隐晦呢？学学人家瑛桥的骂街站姿，多么的直接和伟岸啊！不过大家不要学他的激动。什么？没看出来哪里激动了？好吧，我没说，啥也没说。

如果你觉得自己很有魅力呢，也可以这样：看，我有带耳环哦！耳环上有很大的一颗钻石哦！闪到了没有？！

或者，我有项链哦！纯金的哦！上面的坠子还是我的英文名哦！看到了没有？！哼，就不让你看。

其实向着老板表达仰视，

或者陶醉，都是很不错的办法。（哎，Sindi你的表情真的是达人了。大家都哮啸！）

要是啸不会，也注意不要喝酒，小心肝！

喝酒除了伤肝，还会导致眼神迷离，呃，别人的。

如果喝酒的时候同时吃肉的话，还可以释放出催眠的效果。（海军啊，你看Stan都做了些什么……）

补充说明：那个喝酒吃肉时一种群杀伤技能。

开会很消耗时间。对了，小姜你这是什么表，看着很牛逼啊！

还会饿，幸好有东西吃。

不过最重要的还是回困啊！27日的行程报道到这里就结束了，大家洗洗睡吧！

（P.S.:其实还有好多不错的照片，想要的请找我。）

尼康和佳能单反性能对比（高感、色深、动态范围）

2012-07-21T22:35:00.000-07:00

2007年的时候第一次正式踏出国门，去马尔代夫玩了一个礼拜——度蜜月。既然是度蜜月自然少不了要拍点照片留念的，而当时仍是穷光蛋一个，拿了一个老旧的卡西欧卡片相机。具体型号已经不记得了，只记得的那个相机是一个亲戚在香港买的，当时让柜员小姐介绍，估计出于利润空间考虑介绍了这一款。后来亲戚拍照觉得照出来很难看，于是又买了一个索尼的卡片机，这一个就淘汰给我了。

话说当时对拍照这事情一点研究都没有，基本上只处于找个好看的景色按一下快门的境界。而马尔代夫的景色确实很美，白云下面是白色的沙滩，宝蓝清澈的海面上是蔚蓝的天空。最美的是夜晚，漆黑的分不清水面和天空，只见星星点点的灯光在闪烁，满天的繁星如精细研磨的盐粒洒满了天空。悲剧的是，那一个卡西欧的破卡片相机，根本就无法拍出这一画面。当时我也大概知道ISO这种东西的作用，数字越高越能够拍摄漆黑环境。而这个小破卡片机ISO最高只能够到200，也就是说基本只能工作在白天多云间阴的光线环境中。当然了，是可以通过增加曝光时间来解决问题，但是……我要拍人像哎，就算用三角架，我也不能曝光10秒吧？于是很遗憾的，这样的画面没有被记录下来。

后来去新西兰的时候，接了亲戚的一台佳能300D。这一次拍摄照片的质量明显上去了，甚至连大雾的天气也能拍下来（当然，后期稍微需要调整一下）。这一次的遗憾是该相机只搭配了一个18-50的狗头，拍人像什么的很不给力，拍远处不可到达的景色同样很不给力。从这以后，就开始关注单反这种毁一生的产品，整天思量着要入手一台，魔怔了。

众所周知，数码单反当中有最好的两个品牌分别是佳能和尼康。在此之前有机会接触的，基本都是佳能的产品，包括300D、7D还有5DII，每一个都只能说摸过。其中印象最深刻的当属5DII，不错的分辨率，非常高的ISO。而7D的高感则只能用一塌糊涂来形容，据说强项是高速连拍。（后来的研究发现，其高感虽说比300D高了将近一倍，但是和早前的入门级产品1000D，以及稍后推出的550D相比基本上没有什么本质上的差距。）

可是，从来没有摸过尼康家的产品，怎么对比哪一家的更好呢？好在有一个叫做DXOMARK的网站，专门对比了各款数码相机（主要是单反）的技术性能。（其实还包括镜头的测试对比。）根据这个网站上面的佳能和尼康技术数据，我们可以得到一些显而易见的结论（截止2012年7月20日数据）：

无论高感、色深还是动态范围，全部被尼康产品所包揽；
无论高感、色深还是动态范围，自2010年以来，入门级产品全部是尼康压着佳能，甚至能压制佳能的中端机；
无论高感、色深还是动态范围，尼康基本都是在逐步提升，但其中高感在2007年以前基本上没有怎么动。而佳能基本上是长时间原地踏步或略有进步，除了高端机的高感尚算有明显进步之外；
无论高感、色深还是动态范围，佳能这除了5D及以上的产品外，所有产品的技术性能并没有多少差别，甚至实际上一样。

这么说也许还不够明显，甚至在网站中按品牌来查看，都显得有点凌乱。为了让大家能看明白，我特地为大家制作了这两家产品的技术性能等高线图：
*注意：数据截止2012年7月20日，到目前为止抢先发布的1DX的测试数据还没有出来，尽管5DIII、D4、D800和D800E都出来了。

色深（适用人像）

佳能的色深

佳能的色深最高不超过24位，其中1D/5D系列基本上在22位以上，而比5D要低的中低端系列，基本上略超22位，甚至低于22位。并且可以很明显的看到10D系和300D系，甚至是1000D系基本上是纠缠在一起的。这一档次的产品从2004年起到现在，基本上没有什么大的改变。

尼康的色深

尼康的色深可见基本上在逐步提升。令人吃惊的是，最新的D3200这种最入门级别的产品，其色深都达到了24位以上。在这一个项目上，即便与佳能的最新二当家5D mark III相比，也毫不逊色。甚至从2009年开始，尼康的入门级产品就已经超出22位色深了。在这张图当中，我们可以看到23.5左右的位置有5个点基本平行一致，但随着时间的推移，逐步从顶级产品下移到入门级产品。这种现象在佳能产品中是绝对看不到的，他们家的策略似乎是分为两挡产品，高端的在逐步提升，而中低端的则共用相同性能的感光元件平台。这种明显的差异，我们还会在后面的其它各项技术参数中看到。这张图有一个非常有趣的地方是，D800/D800E这个二当家居然比大当家D4还要强大，这是非常不可思议的。

动态范围（适用景色）

佳能的动态范围

佳能的动态范围，依旧非常的悲剧：自2007年以来，基本上没有太大的提高，从未超越12EV的天花板。图中那条黑色的天花板线画成这种倾斜向上，已经给足面子了。甚至我们可以看到5D mark III的色彩动态范围和上一代相比，不升反降。在11.4EV附近的位置，我们可以看到从2008年起到现在，混杂了各种入门级和中级产品。比如说定位为中端机的60D和定位成入门级的600D，在这个方面完全没有两样。可以认为，就是同样的感光元件，只不过……区别在哪里呢？我相信你一定会发现的。

尼康的动态范围

尼康的动态范围很显然是在不断地提升的，比如说最新的最入门级产品D3200，数值达到了13.2EV。对，你没有看错，在这个项目上，佳能拿不出任何产品可以和尼康最新的最最入门级的单反相匹配。可以这么讲，从2008年中旬推出D700开始，佳能就只能打败最入门的D3000/D3100。而2011年开始，尼康的产品已经全面上升到13EV这一级别以上，佳能已经阻止不了尼康了。当然，这里也有一个很诡异的事情，最新的大当家在这一个方面，不仅比不上上一代大当家，比不上这一代的二当家，甚至连最入门的D3200都比不上。这个除了说明在技术参数上由于没有任何竞争对手，尼康仅对各种参数做了些微调而没有做太大幅度的提升之外，还说明这次尼康对入门级产品的定义，是想要彻底拉开与佳能的差距。而佳能对于这一问题的应对之道，基本上还是拿一些门外汉特别喜爱的东西来对抗，比如说翻转液晶屏。

高感（适用运动）

佳能的高感

佳能的高感仍然能够很明显的看出来1D/5D和其它产品之间的差别。在2007年至2008年推出的四个产品40D/450D/1000D/50D，高感基本上都是在700上下。2009年推出的500D，很可能是在这一个感光元件的基础上做了一定参数调整，因此有小幅的降低的。在2010年至2011年推出的三个产品550D/60D/600D，高感基本上在800上下，而1100D略低的高感，也可能同样是做了一些参数调整甚至限制达到的。当时看到这个图我就很纠结，佳能除了5D系列（及以上）以外，没有任何产品可以大幅超越850的可用ISO。而高感确实是当年我对单反产生兴趣的重要原因：由于很多时候在车上，只能提高快门至1/1000以上来达到清晰成像的效果，其中不少ISO都在500。这样拍出来的照片居然清晰锐利……相对于卡片机来说，于是对高感的重要性有了非常深刻的认识。然而佳能这样的实际情况，除了入手5D甚至以上，没有别的什么好选择。

尼康的高感

尼康高感在2007年以前完全不是佳能的对手，而且就几乎没有长进过。然而2007年推出D3开始，事情开始逐步改变，佳能却相对变得不知进取。尤其是2009年以来，四位数的入门级系列已经完全压制了佳能的中低端单反。然而我们也可以明显的看到，在1300-2900之间存在一个巨大的空挡，这里没有这没有产品占据。事实上尼康的级别是这么划分的：
D3/4大当家
D700/800二当家
D300/D7000第三梯队
D5000/5100/3000/3100/3200第四梯队
可见，在不久的未来第三梯队一定会有新的产品来占据着一个空档位置的，不是D400就是D7100。

关于镜头、双机双镜和全幅半幅

佳能在卡口的设计上由于抛弃了之前老旧的镜头，其EF卡口口径较大，在设计大光圈镜头上面确实占据一定优势。而尼康家由于要兼容旧镜头而沿用了很早以前就设计好的F卡口，因此在制作大光圈镜头上面稍微难一些。但是，如果你看过DXO中关于镜头的评测，就会发现差距也没有那么大嘛。（其实在同等光圈焦距的配置下，可能还会稍微好那么一点点。）不过镜头的性能与传感器的性能相比，评判起来会更困难一些，这个和各人的喜好有关。而且我认为两家镜头间的差距，和各人之间构图等摄影技巧的差距相比，可以说是微不足道。不像高感达不到，很多对快门速度有要求的低光场景是无能为力的。（好吧，光圈大一档，相当于快门可以提升一档，或者ISO降低一档。不过……1.4和1.2相比，只是相当于降低半档。再者说光圈变大会导致景深变浅，并不是所有时候都是需要非常浅的景深的，甚至光圈过浅可能会导致拍摄对象不能够完全进入聚焦范围。）

单反之所以毁一生，是因为不同的镜头擅长于不同的场景，因此需要多支镜头来应对不同的场景。比方说用大光圈来拍人，用长焦来打鸟。但是换镜头总是一件很恼人的事情，比如说在拍人的时候发现远处有一只罕见的小鸟，等你换好镜头可能就啥都拍不到了。而且在野外更换镜头，总是多有不便。于是有一些人就会产生了双机双镜的想法，就是说，用两个机身分别接上不同的镜头。这样，当场景变换的时候，只需要取出不同的相机就可完成任务。这一策略的另一个诱人之处，是可以考虑先买一个入门级的，等到练熟了再买一个高端的单反。万一刚买第一个单反没多久，就发现成为箱底货，那也可以少花不少冤枉钱。

如果你也考虑到这个问题，那就会发现佳能的入门级没有什么好选的，和尼康比完全没有优势，唯一有优势的是大光圈镜头。不过倘若你仔细研究就会发现，一个50F/1.2的镜头要近10000元，而50F/1.4则只要不到3000元。对于刚开始玩单反的人来说，这0.2的光圈实在没有什么意义。就算给你一个50F/0.7的镜头（假设存在吧），估计你也无法拍出惊为天人的照片。

另一个悲剧的地方是佳能的半幅机专用镜头，即EF-S镜头，不能用在全幅机上面。这是因为EF-S镜头最后一个镜片是稍微突出来一些的，佳能半幅机专门为此将反光板往后缩入一些。这样的镜头装在位置相对靠前的全幅机上时，会打到反光板。换句话说，假如你打算以后走双机双镜的路线，那么即便第一台机器入手入门级的650D，对应的镜头也必须选择EF镜头。否则当初买的EF-S镜头，在后来再入手的高级货比如5DIII上面是完全不能使用的。

佳能采取这样的策略，大概是希望区分镜头的价格区间。购买入门级的半幅机，通常都是因为考虑到价格因素。那么为这些机器配置镜头的时候，通常也会考虑价格因素，或者说便宜点的镜头。半幅机所使用的镜头，因为成像区域小，镜片通常可以稍小一些。为了进一步压缩成本，佳能采用的办法就是减少外壳面积，或者说缩短外壳长度。要达到这一目的，其中一种办法就是让后部镜片突出。而购买高端全幅机的用户，通常来说价格因素往往排在第二，甚至更后面。因此针对这些用户所使用的镜头也可以设计的更好，价格设定得更贵。但是，没有人会跟钱过不去的。如果说有一个相对便宜的半幅镜头，其成像质量较同等规格的全幅镜头没有非常明显的差异，此时用户还是会有考虑使用较便宜镜头的可能性的。当然，半幅镜头从设计上其成像区域较小，用在全幅机上的时候四边成像时会有问题的。比如说，暗角，甚至完全无法成像等。

佳能和尼康在这个问题上的策略完全不同，佳能的做法是从设计上就阻止全幅机能使用较为便宜的半幅镜头，而尼康则是采取DX镜头用在全幅机上时自动进行裁切。用更加直白的话说就是，佳能考虑的是如何避免EF-S镜头降低高端用户的ARPU值，而尼康考虑的则是如何保护低端用户原来在镜头上的投资。哪一家更加厚道，就不言而喻了。事实上这在镜头卡口的选择上，两家就有完全不同的历史。最开始大家都是使用莱卡的L39卡口，后来莱卡设计了受到专利保护的M卡口之后，两家就开始走出了完全不同的路线。其中佳能经历了R、FL、FD、newFD、EF卡口的变迁，除了EF卡口外，几乎每隔10年一个变迁，被调侃为“基本上跟施罗德换老婆差不多了”。而尼康则50年都保持F卡口不变，只是在这一接口上进行各种可以互相“兼容”的扩展。尽管实际上早期的F卡口镜头用在今天的中低端尼康单反上面时，可能很多功能如自动对焦、光圈联动等都无法使用，但好歹可以轻松装上去，好歹全手动操作还是能够使用的。也许有人会说，缺乏这么多功能，和不能使用有多大的差别？其实差别就在于是否尽最大可能保护用户的原有投资——设计一个新的、没有历史负担的、更好的卡口，真的那么难么？一点也不难，但是要在旧的卡口上为了实现新的功能而兼容来兼容去的，则不是一件简单的事情。如果感兴趣的话，这里有一个关于卡口历史变迁的介绍，不妨看一下。

还是关于镜头

不可否认的是，佳能的镜头由于卡口的关系，更容易设计成大光圈的。比如说50F/1.2，目前只有佳能有，而尼康截至2012年7月似乎没有这一规格的镜头推出。另一个似乎佳能有而尼康没有的，是STM镜头。所谓STM镜头和普通的超声波马达镜头相比，就是对焦更安静平滑，对于摄影来说更为有利。尽管STM镜头我没有试过，但普通的AF-S镜头则试过，在摄影时如果使用自动对焦，那种骤起骤停的咔嗒音还是非常明显，并且会被录到视频当中去的。不过……单反的主要功能仍然是拍照不是么？

至于说半幅头的性能参数，有人可能直觉上会觉得比不上全幅镜头。其实这从理论上讲，应该正好相反——相对更小的传感器而言，镜片的比例应该更大，在同样的物理尺寸下做出更好的镜头应当是较容易的。或者说，出于用户对价格上的预期，以及厂家的利润空间上的考虑，才没有制作出比全幅要好的镜头。其实半幅的传感器，在同样分辨率下面其像素密度更高，因此更容易出现噪点。这一个问题不仅仅导致高感更差，还会导致分辨能力的下降。比如说同样是Sigma 85mm f/1.4的镜头，在D7000上测试，分辨力是501lp/mm，而是用D4测试则是541lp/mm。此时制约画质的是传感器，镜头再好意义也不大。

即便厂家没有针对半幅相机设计出顶级的镜头，仍然是有一些非常“实用”的镜头的，例如尼康家的AF-S DX 18-300mm f/3.5-5.6 ED VR这支镜头，等效焦距相当于27-450mm，涵盖了广角到打鸟，对于拍照来说可以说基本足够了。

SqlServer数据库性能问题解决实例

2012-06-27T00:33:00.000-07:00

关键字：sys.dm_os_wait_stats, sys.dm_os_latch_stats, PAGELATCH_UP, BUFFER, CXPACKET, EXECSYNC,

在SqlServer 2005当中，引入了不少的系统视图，对系统性能的优化，以及解决具体的问题提供了非常多的帮助。但是，也因为提供的视图太多，新手也许就会无从下手。对于执行语句的性能调优，一般来说只要简单的使用“数据库引擎优化顾问”（Database Engine Tuning Advisor）即可。因此，不在这一篇文章当中进行阐述了。

对于线上系统的性能问题，我们通常会使用下面的几个手段：

查看最近更新的源代码当中涉及数据库查询的改动；
使用Sql Server Profiler对数据进行跟踪；
在Sql Server Management Studio当中，点击“包括实际的执行计划”（include actual execution plan），然后对有怀疑的语句进行执行查看和分析；
通过一些脚本查看是否存在死锁问题。

这几种手段可以单独实施，也可以组合事实。通常来说，上面这些手段基本上已经足矣。其中最为有效的，是使用方法2，找到CPU高，或者Duration高的语句。然后通过方法3去验证，以及根据计划所显示的不正常内容（例如，出现全表扫描），进行相应的处理。例如：

添加索引；
修改查询语句；
修改其它表结构。

对于持续运行的系统来说（比如某些大型的电子商务门户），上面这几种手段的实施难度是按顺序逐步增加的，但效果却不一定同样逐步提高。很多时候添加索引就可以解决大部分的问题，而有的时候在不修改查询语句的前提下，是无论如何也不可能得到任何有价值的提升的。当然，某些特定情况下，修改表结构相当容易，而且效果极为夸张，例如：添加一个自增标示字段，同时添加其为主键。不过，这种情况通常都是基于原来表结构设计不合理的前提之下。

上述这些步骤，基本上就是一个入门级维护人员的基本工具。而在实际的战斗当中，有时候会比较复杂。比如说，有可能因为数据库太大导致性能损失，或者因为IO问题导致性能瓶颈等等。因此，稍微进阶一点的思路还应该包括：

思考数据库是否真的过大（比如，超过500GB），或者处理量过大（比如，性能计数器Sql Server:SQL statistics下的Batch Request/s 达到1000以上）；
思考数据库结构是否存在不合理的问题（比如，数据库当中有image字段，且平均大小非常大，而查询又经常取出这些字段）；
思考是否软件架构本身出现了问题，比如前面提到的这些字段，是否真的需要每次都取出，或者是否应该具有合理的各级缓存手段；
是否存在某些Bug（例如数据库链接没有释放）。

可以看出来，上面所提到的问题，已经不仅仅限于“某条Sql语句写得不好”，或者“数据表结构设计出现严重纰漏”这种方向。在实战当中，甚至很多时候根本就不能够确定问题是否真的和数据库有关。那么，最重要的、首先必须要解决的问题就出现了：到底问题出在哪里？

在这里，我们仅通过一个实际的案例，来看看如何进行一个数据库问题的排出的。（由于某种原因，这里面给出的数据并不真实，仅用于演示其大约规模）

场景：

WEB网站，较典型的OLTP应用，查询多，插入和修改比较少。数据库巨大，比如1TB，且当中个别表（例如3个表，分别简称A、B、C）包含一些二进制类型字段。这些二进制类型字段中的数据总量达到，比如说600GB，平均每一行当中该字段大小比如是10MB。同时这些表的总大小占据数据库的绝大部分，比如800GB。而整个系统的拓扑包含了CDN、前端缓存、负载均衡、Web服务器、数据库服务器以及专业SAN存储设备。

现象：

大量用户报告访问很慢，数据库CPU较高（60%），磁盘IO量巨大（3000tps），Web服务器CPU均较高60%，Web连接数较大（正常时例如200tps，受攻击时可达到比如2000tps）。每到月底销售需要赶任务时，会有大量报告访问慢的情况。而受到攻击的时候，也有类似的反应。Web服务器可见大量的数据库超时日志，而数据库端用Profiler则可见不少1秒以上的操作。甚至在Profiler长期跟踪的时候，会看到不时有一批数据库操作因为超时被服务器主动放弃执行。

解决过程：

首先，通过对数据库的二进制字段表进行一些简单的缓存处理，以及对存储硬件进行升级，解决了一部分潜在可能的IO问题。然后通过进行一些防火墙设置，例如前端缓存对特定状况下的动态内容，进行极为短暂的缓存，避免受到攻击时出现大量攻击涌入后面的Web服务器，进而造成数据库压力。除此之外，通过profiler检验所有CPU或者Duration较高的可疑Sql，并进行优化。

然而在这些措施之后，仅仅是有轻微的改善，无实质性的变化。甚至以较长的时间观测，例如一个月，发现实质趋于严重化：在经过多种改善措施之后，尤其是数据库服务器的CPU升级为原先的5倍以上，仍然CPU高，伴有数据库操作超时的问题。因此，基本上怀疑仍然是结构性问题——也许是拓扑结构的问题，也许是前端代码的问题，也许是数据库查询语句或者结构性问题。在经过对经常被使用的主要表格A、B、C当中的表结构、索引、查询语句乃至程序设计和拓扑结构的反复检查、推敲、验证后，均没有发现值得怀疑的地方（那个很大的二进制字段已经通过缓存来读取，基本上不通过数据库来进行查询）。而通过类似如下的这类语句

SELECT SUBSTRING(qt.TEXT, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(qt.TEXT)
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.total_logical_writes, qs.last_logical_writes,
qs.total_worker_time,
qs.last_worker_time,
qs.total_elapsed_time/1000000 total_elapsed_time_in_S,
qs.last_elapsed_time/1000000 last_elapsed_time_in_S,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY qs.total_worker_time DESC -- CPU time

所查询得到的Sql语句，其执行计划也没有看出任何问题，在结构完全一致的测试数据库当中进行查询，性能均没有任何问题。最慢也就100ms执行完毕，而且这个测试数据库的配置要比线上配置低很多。当时，这个问题基本上已经卡壳无解。

由于有人怀疑可能是系统存在某种Sql事务死锁，或者某种语句执行时间较长导致其加锁不被释放，于是后续Sql语句基本处于等待。因此，我开始转向查找系统自带的dmv。下面分别叙述曾经尝试过的主要视图，并简述其效果和结论。

dm_os_waiting_tasks

这个视图可以显示目前正被阻塞的任务，以及阻塞该任务的来源。通过使用CROSS APPLY dm_exec_sql_text(handle)，通常可以查看出被阻塞和引起阻塞的语句是什么。实际上有不少的脚本，就是通过这一个试图来查找阻塞乃至死锁链条。但实际的情况是，如果并非死锁而是某条语句执行时间较长，并且线上执行语句的吞吐量很大，这个试图是无法看出问题的。原因很简单：如果某个语句出现问题，导致其锁或闩阻碍大量语句的执行，则你查看该视图的时刻，很可能会在该语句已经执行完毕后续语句开始得以执行的时候。这样，你看到的“罪魁祸首”很可能其实是一个受害者。我就是过分相信着一个试图，导致大量的时间消耗在调查受害者上面。

sys.dm_exec_query_stats

这个视图可以看到从本次实例启动开始为止，曾经执行过的语句的统计情况。配合CROSS APPLY sys.dm_exec_query_plan(plan_handle)，可以看到其执行计划。通过这一个视图，可以找到累计执行时间较长的，或者最长时间最长的，或者次数较多的，或者读、写次数较高的语句。但是这一个视图无法显示出这些语句曾经经历过什么类型的锁和闩，换句话说，这只是一个统计。在这一个实战当中，这个试图无法发挥重要作用。因为累计执行时间较长的，也正好是执行次数最多的，而这些语句的平均执行时间都较小。而单词执行最长时间较高的，通常是因为有前面语句阻塞导致当前语句超时的超时时间。

sys.dm_exec_requests

这个视图可以看到当前正在请求执行的语句。一开始我一直认为这一视图对于解决问题的意义并不大，因为这只是显示当前正在执行的语句，既不象dm_exec_query_stats能给出关于各项耗时的统计，又不象dm_os_waiting_tasks那样，可以知道前因后果。再加上不少的脚本，都是通过join这个视图再CROSS APPLY dm_exec_sql_text来获得其sql语句，因此一直以为起作用也就仅限于此，除此以外也就走马观花而已。

sys.dm_tran_locks
这个视图主要是用于解决事务锁的，一般该视图用于解决死锁问题（或者锁过多的问题）。在本次实战当中，并没有发现死锁，而锁的内容不停发生变化，可见并没有出现长期持有事务的问题。因此本表在这一实战当中并没有发挥多大的作用。

sys.dm_tran_database_transactions
这个视图用于了解目前正在进行的事务，作用基本同上。这两个视图在解决事务导致的死锁问题上有很重要的意义。然而一般来说大家都会想到这一点，很快便能排除，因此这里也不做叙述。

sys.dm_os_wait_stats
这是一个对于性能而言至关重要的视图，也是在本次实战中起到启发作用的表。该视图显示了从实例本次启动（或者上一次清零）到现在为止，因为何种原因导致了等待，其总时间、总次数、最耗时一次所用时间等分别是多少。根据最耗时一次所用时间通常可以找到值得怀疑的等待原因。关于各种等待类型，请参考这里的官方说明。其中需要注意的是，某些类型的长时间等待也许是正常的，例如：
SQLTRACE_BUFFER_FLUSH、BROKER_RECEIVE_WAITFOR等。在本实战当中，早期就已经发现有大量的最大等待类型时间超出10秒，尤其是一个叫做LCK_M_IS的锁。但是当时没有执行清零重新进行统计，因此这一统计其实体现的是自上一次启动以来的情况，并不真实。基于这一步真实的观测结果，所进一步进行的排查，仍然没分析出所以然。后来仔细查看帮助，发现这个试图（以及下面提到的dm_os_latch_stats），是可以通过下面这个语句清零的：

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);

在访问高峰期进行清零之后，很快就能发现主要的可疑wait类型有下面这几个：
PAGELATCH_UP
MSQL_XP
LCK_M_X
SOS_SCHEDULER_YIELD
CXPACKET
EXESYNC

其中最值得怀疑的是后三者，其中SOS_SCHEDULER_YIELD的含义是，正在等待调度器将当前已经可以执行的语句调度到CPU当中进行执行。换句话说，就是CPU忙于处理某种任务，导致后续的查询在等待。其实在之前经过简单的搜索，发现可以通过安装这一个报表来查看详细的性能问题。这个报表就提示SOS_SCHEDULER_YIELD占总等待时间的22%以上，正是因为这一提示，我才再一次尝试查询本视图。而这一篇文章当中的“CPU Bottlenecks”一节，以及这篇博客中的“SOS_SCHEDULER_YIELD Explanation”当中均提出，SOS_SCHEDULER_YIELD占比较高的话，可以通过下列语句进一步排查：

SELECT scheduler_id, current_tasks_count, runnable_tasks_count, work_queue_count,pending_disk_io_count
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255

实际上这个语句的执行结果，相当于各个CPU当中正在执行的任务数量，可以执行（但正在等待）的任务数量，以及正在等待IO结果的任务数量情况等。其中后者提到了，如果大部分CPU长时间出现2位数的runnable_tasks_count（就是可以执行但还在等CPU的任务数量），就表明任务负载过高。本文一开始所引用的脚本，就是该篇博客中后续提到的进一步方法。（然而很可能你和我一样，用这个方法找出来的都是一些正常的语句。）

而CXPACKET的含义是，要执行的SQL语句正在被分割成多组，发往多个不同的CPU进行执行。而EXESYNC则是并行计算完成时，等待多个不同CPU上的计算结果全部结束。根据这里提到的手册（简称手册A）说明，发现一般来说OLTP的应用不应该出现长时间这样的锁（甚至根本不应该出现）。如果出现这种情况，则说明SQL语句或者数据库结构出现问题。同时，这个手册中还提到一个叫做“get_statements_in_waiter_list”的存储过程，可以找到当前正在执行的语句当中，存在指定等待类型的SQL语句是什么。这一个存储过程可以在这里搜索到，实际正确的名称叫做“get_statements_from_waiter_list”。通过执行语句

Exec get_statements_from_waiter_list @wait_type = 'CXPACKET'

立刻找到了等待类型为CXPACKET的语句，这个语句大致长这样：
select row_number() over (order by xtime) as rownum, * from messages
inner join message_comment on
messages.messageId = message_comment.messageId
where
messages.userId=1000 and
... and
rownum between 100 and 110

由于使用了row_number（以及很可能还有另一个原因，下面会提到），其执行计划被设定为进行并行计算。而实际上经过检查发现，messages表没有做userId相关的索引，同时message_comment也没有做messageId的索引。尽管这两个表非常的小，分别只有比如30MB和6MB，然而由于需要进行全表的检索，外加并行计算占用了所有的CPU，因此几乎所有的查询都必须等待该查询执行完毕才能得以进行。而且似乎该闩之后，还需要对缓存进行操作，会进一步引起一些PAGELATCH_xx类型的闩处于等待状态，而PAGELATCH_xx这种等待，却不知因何原因在dm_os_waiting_tasks视图中显示为没有阻塞来源，仿佛都是因为这个闩本来就需要这么长的时间。然而实际上仔细分析，却觉得不太可能，因为这种闩本来就是对内存当中的缓存数据进行操作，这种闩如果不是因为被其它任务对相同的闩进行了锁操作，不可能需要这么长的时间仍然需要等待。就目前看到的情况推测，很可能CXPACKET引起的等待，不会被显示在dm_os_waiting_tasks的阻塞来源字段中。

通过改善这一个表的索引状况，CPU占用率很快从60%以上下降到10%左右，网站的访问速度也迅速提升恢复。将dm_os_wait_stats清零之后重新观察，发现除了那些正常的长时间等待类型之外，所有的等待类型的平均等待时间，例如SOS_SCHEDULER_YIELD、LCK_M_X、CXPACKET等，已经下降到100ms以下，甚至10ms以下。至此，问题已经得以解决。

总结

在某种特殊状况下，通过使用常规的Profiler分析很可能找不出原因。例如：引起问题的语句执行时间非常之长，并且出现频率并不高，同时又进行了并发计算，而且这一查询还锁住大量的资源。此时由于该语句引起大量其它语句执行时间变得非常长，这些被迫等待执行的语句本身并没有问题，所查询表格的结构与索引也没有问题，恰巧罪魁祸首又不会通过dm_os_waiting_tasks显出原形。甚至在使用Profiler的时候，可以看到几乎所有的Sql语句，甚至极为简单的根据主键找一条记录的一个简单字段这样的Sql语句，其执行时间也较长，并且是时快时慢。如果你遇到这样的状况，甚至在另一台无负载的机器上重复执行各种被怀疑的语句，仍无法复现查询缓慢的现象时，你可能就需要查看视图dm_os_wait_types，看看是否存在什么不正常的长时间等待了。

这个实战告诉我们，一个并不怎么经常会用到的、共不超过35MB的两张表，因为结构上的问题，外加特殊的查询语句的共同作用下，导致一个1TB数据库近乎无法访问，并且几乎无法找出原因。

最后多嘴两句：
1、除了dm_os_wait_stats，还有一个成为dm_os_latch_stats的视图，用于对闩（Latch）的原因进行分类分析。如果你的wait类型主要集中在xxx_latch的时候，可以参照这里面提供的信息进行一下分析。这一个视图也同样可以通过DBCC SQLPERF来清零；
2、本文当中提到的文档和资料，一定要仔细阅读，对于SqlServer一类的问题排查非常有价值。

iTune真狗屎

2012-06-06T19:27:00.001-07:00

最近买了一个新笔记本，一切都很好，直到想起来要转移iTunes的问题。需要说明的是，我写这个的时候还没有进行尝试，但是一想起来我就头痛。

之所以觉得头痛，是因为iTunes在不同的机器上进行同步，会抹掉数据。这个真是一个挺白痴的设计，我一直就没有搞清楚什么时候会抹掉，所以对此感觉非常恐惧。而且在另一些情况下，会将我手机上同步下来的程序，装到别人的iPod上，所以别人的iPod要在我机器上充电，我也感到恐惧。

我不知道这玩意儿是怎么设计的，不知道是否以搅坏别人大脑，以及实施恐怖统治作为其根本出发点的……

ConcurrentDictionary的性能问题

2012-05-25T02:20:00.000-07:00

最近在写一个小玩意儿，有并发的要求，并且吞吐量巨大，因此需要使用.NET 4出现的并发库，其中最常见的莫过于ConcurrentDictionary这个类了。但是在使用的过程中发现存在一些潜在的并发问题，这类问题会导致系统性能急剧下降。

我们在使用ConcurrentDictionary的时候，可能会有类似下面的代码：

// users的key是用户名（字符串），value是该用户的复杂信息对象。

// 其中用户名如果以"vip:"开头，则是vip用户。

// 于是我们可以用这样的代码获得所有vip用户的用户名。

var vipUserNames = from userName in users.Keys

where userName.StartsWith("vip:")

select userName.Substring(4);

在上面的这段代码里面，Keys属性的访问会导致并发性能问题。该属性是通过调用一个GetKeys()函数来获得的，而GetKeys函数则会首先通过AcquireAllLocks来锁定内部的所有锁，然后在这一锁的保护下，取出所有的Key值。正是这一个操作导致了一定程度的互相竞争。要阐明该问题及其原因，需要首先简单的说一下ConcurrentDictionary的并发设计思路。

一般而言，如果我们自己写并发字典，可能会尝试通过简单的使用lock来在读写的时候进行同步锁定。然而这种实施方式会导致在大并发的时候出现互相等待的情况，甚至最终退化成单线程处理的状态。稍微好一点的ReaderWriterLockSlim，在读操作的时候共享读阻塞写，而写操作则阻塞所有操作。这种设计在大量读少量写的时候也不失为一种不错的设计。但是不可避免的是，每一个线程的操作都会导致一次锁请求，而且说不定就会被阻塞。甚至面对大量写操作的场景，则会ReaderWriterLockSlim对写操作的排他性而互相等待，最终退化成单线程处理的状态。那么ConcurrentDictionary又有什么高招呢？

ConcurrentDictionary是这么设计的：通过将桶进行分组，每一组使用一个单独的锁对象。这样，在大量的写操作面前，也会因为写操作对象的不同而进入不同的组，互相之间被锁定的可能性就大为减少了。另一方面，其读操作被设计成为多线程操作下无需锁同步也是安全的，因此读写之间不需要互相阻塞，也不需要获取任何的锁。于是，其吞吐量通常会较一般设计要好得多。

然而，Keys属性的设计却导致并发性能的降低。因为AcquireAllLocks会锁定所有的锁，这个时候所有的写操作都会被阻塞。可是为什么要AcquireAllLocks呢？于是有人会猜测：之所以需要锁定，是因为任何的写操作都可能修改内容，导致最终结果和那一瞬间的情况不一致。然而这类的想法其实是错误的，因为：

1、线程安全问题是指，在多个线程同时操作的时候，程序不能出错（死机死循环或者什么也不干），数据一致性不违反你的期望（比如你的操作是增加，但实际上没有，甚至变成清除所有）；

2、在高并发的情况下，“某一瞬间”的定义还真不好说清楚，因此仍然只能够从逻辑上来说是否违反你的预期。

如果你仍然无法接受上面那两句话，那可以继续考察一下ConcurrentDictionary的枚举操作，这一操作依赖于GetEnumerator返回的枚举器。如果你真的去看，就会发现ConcurrentDictionary所返回的枚举器并不会加锁。它实际上和普通的TryGet没有什么两样，是一种不需要锁的线程安全写法。于是，最开始的那一段代码，用下面的方式来写，就不会出问题了：

// users的key是用户名（字符串），value是该用户的复杂信息对象。

// 其中用户名如果以"vip:"开头，则是vip用户。

// 于是我们可以用这样的代码获得所有vip用户的用户名。

var vipUserNames = from userItem in users

let userName = userItem.Key

where userName.StartsWith("vip:")

select userName.Substring(4);

嗯……真的没有问题了？其实还是会有的，比如说，如果我需要按照用户名来进行排序：

// users的key是用户名（字符串），value是该用户的复杂信息对象。

// 其中用户名如果以"vip:"开头，则是vip用户。

// 于是我们可以用这样的代码获得所有vip用户的用户名。

var orderedUserNames = from userItem in users

orderby userItem.Key

select userItem.Key;

你猜现在会调用AcquireAllLocks吗？看上去会使用ConcurrentDictionary.GetEnumerator，实际上不然。其实orderby会根据待排序的对象是否为一个ICollection而区别对待，如是，则调用ICollection.CopyTo(array, 0)，否，则使用IEnumerable.GetEnumerator()然后MoveNext()。如果你直接orderby，由于ConcurrentDictionary存在ICollection接口，于是会调用CopyTo，而CopyTo也和Keys对象一样，会存在一个AcquireAllLocks的调用，类似的地方还有Values属性。

除了上面的这些问题外，ConcurrentDictionary还有另一个会造成死循环的场景，不过这不是本文的主题了，留待以后再谈。

关于南航CZ3525航班急坠失重乘客受伤的猜测

2012-05-15T23:33:00.000-07:00

近期南航CZ3525发生一起准事故（不是只有解体坠毁才算是事故，按照这里的解释，需住院48时人数达10人及以上就算一般事故），新闻中并未详细说明受伤人数及程度。仅仅提及有9名乘客受伤，其中2人骨折，其余7人擦伤。另外似乎至少有一名乘务长，和一名刚入职不满一年的乘务员受伤，前者腰部损伤轻重不详，后者貌似轻微擦伤。

在这一起准事故中，据分析称当时高度7000-8000米左右，尚未进入平流层。并且当时天气晴朗，事发突然。根据分析中的说法，这叫做“晴空颠簸”。有旅客说，自由下落数十秒，这基本上不太可能，属于过度夸张。要知道20秒自由下落可以下降近2000米，30秒则可达到近4500米。以本人乘坐飞机时遇到的接近失重2秒经验，部分旅客已经开始尖叫。若失重10秒，估计会各种心脏病，狂哭直至旅途结束。有旅客质疑是否机师操纵不当造成，分析中的专业人士则指出：“飞机在空中飞行的大多数时间都是通过自动驾驶完成，并不是人工操纵。因此，颠簸的感觉和程度跟飞行员自身的技术并没有太大关系。有人举例说，空气和海水一样都是流体运动，飞机遭遇的颠簸与行船中的颠簸道理一致。”要了解这个问题的真实答案，可能需要先了解一些“专业”知识。

首先是“晴空颠簸”，其实这个是一种晴朗天气下的“下击暴流”。所谓下击暴流，就是一种向下（地面）垂至吹出的气流，在遇到地面之后向四周吹去，并形成涡流（像蛋卷一样一层层向内卷），如下图所示：


触地阶段	外吹阶段	翻起阶段

当飞机从外围超下击暴流中心飞行并穿越的时候，就会出现不平稳甚至引发严重事故的飞行状态。刚开始的时候因为接触的是上下翻滚的乱流，可能会出现一些上下振动颠簸的情况，此时可能并没有明确的单一方向运动。然而在接触到平吹的风时，由于风向从机头吹向机尾，相当于飞机相对于空气的速度增加了，此时获得的升力也会提升。这时候你应该会感觉到一小段时间是像坐电梯上行时那种被往下压的感觉，这时候你应该尽快帮好安全带，尽可能抓好未被固定且可能导致伤害的物体，例如iPad。这时因为很快这股气流就可能开始从水平方向发生向下的偏转，直至垂至向下。在偏转至垂至向下之前也就是以某角度斜向下时，会出现向下的力量和水平逆风引起的升力相抵消的情况，在这一刻风所引起的垂直力（或者说加速度）为零，也就是感觉“平稳”。但这种平稳是瞬间的，因为此后风向会继续偏转直至向下，也就是说此后将会感受到向下的加速度。

根据风阻公式：

其中

为阻力

为流体密度

为流体相对于物体的速度

为阻力系数，为一无因次的参数，像汽车的阻力系数约为0.25至0.45

为参考面积

按照波音777的数据推测，其投影面积大概为800m²左右，微下击暴流的速度可以达到270km/h以上（75m/s），而7000米处高空的流体密度(第16页）大致为0.59kg/m²。由于飞机投影面积中的一半为近乎平板的机翼，另一半为近乎圆柱体，因此阻力系数取0.95，于是阻力约为1,261,125牛。

而根据升力公式：

其中

L 为升力,
ρ 为流体密度
v 是空速,
A 为翼面投影面积
是在特定攻角，马赫数以及雷诺数下面的升力系数

这里A大概为400m²，巡航速度v则为905km/h左右（约250m/s）。而则比较难获知，在此高度与巡航速度下，并且假设下降气流没有导致翼面气流分离的问题，则可能的升力系数猜测为0.5左右，因此L=3,687,500牛。但是实际上如果要保持平飞，则不需要如此高的速度。此时所需要的相对空气速度为688km/h（191m/s），若此时吹75m/s的逆风，则此时只需要大约116m/s的速度即可。实际上飞机并不会减速这么多，而是同时通过调整翼面降低升力来保持平衡。

由于不知道该飞机的具体型号，很难算出准确的重量。根据广州飞上海这个信息提示，可以知道不需要携带太多燃油，估计重量约为220吨，也就是大约2,156,000牛。换句话说，当时的极限升力足以应付自身重量和下垂气流的合力。在这种时候为了保持平飞，大约需要886km/h（240m/s）的相对空气速度。由于前面经历了逆风阶段，飞机的自动驾驶系统为了保持飞行平稳，会减少引擎输出推力，并且通过调整飞行面来减速。此时相对地面速度，比如说已经减至160m/s，于是可见离所需速度相差不少。速度并不是瞬间就能够提上去的，因此更多的是通过调整攻角、襟翼等参数来提高升力。

但是不需要太久，就会从中心区穿出到达顺风区（微下击暴流的影响范围直径也就3至4公里，中心区直径也许就几百米的直径，大概就3至4秒就会穿出）。此时如果保持普通平飞参数，则需要266m/s。由于实际速度尚无法提升至足够的水平，即便通过调整攻角等参数来提升升力系数，也不能保持足够的升力，于是就会出现向下加速的情况。

暴雨天气的下击微暴流

正是因为如此，一般飞机遇到不稳定气流，都会尝试绕过。而这种气流的发现，可以通过对雷达反射的水气进行相对运动分析得到，而一般则是直接避开云层。但是对于晴朗天气状态，没有可以反射的水气，于是会无法提前预知，而经历必然的颠簸过程。需要注意的是，一般飞行电脑都会尝试通过调整升力系数和引擎输出来减少这方面的波动，所以一般应该比手动驾驶为舒适。实际上如果您遇到过乱流，一定会听到引擎在这个时候是提高输出而不是减小输出的。换句话说，在进入逆风区遇到乱流的时候，并不会选择降低相对地面速度，而应该是提高，同时通过调整升力系数来减少升力。

而如果是手动驾驶，再遇上经验不足的飞行员，则可能在进入逆风区的时候因为看到空速大幅攀升，而选择减小引擎输出并降低空速来减少升力，就会在后面遇到升力因为空速关系严重不足的情况。比如前面如果真的将相对地面速度减少到116m/s的话，即便在中心区加速至175m/s，在后面进入顺风区时，空速仍然直接下降至不可思议的100m/s，直接就失速了。一旦时速，必须压低机头，通过重力势能重新建立足够的速度。而如果继续勉强拉高机头，不但提升不了升力系数，反而会因为翼面的气流分离导致升力系数骤降，下跌更加严重。同时拉高机头导致的风阻增加，也会阻碍速度增加。最后严重的会进入螺旋或者尾旋，失去挽救的机会。航空界曾经有过不少这样的案例：华航有一架飞机就是机师拉机头导致失速坠毁的，实际上如果松开拉杆由飞行电脑控制，则会自动压低机头提高空速恢复足够的升力。但是压低机头这种方式会导致快速的下降，也就是失重。

微下击暴流实景

至于此航班当时的操作状态，现在并不清楚。但是我们可以假设这几种情况：
飞机自动驾驶，没有限制空速（油门），同时机师不进行任何干预，则如果飞行电脑程序没问题，应该会选择加速减升力，最后顺风区时空速应当足够，不会长时间处于向下加速的状态；
飞机自动驾驶，锁定油门，同时机师不进行任何干预，则可能会颠簸严重一些，顺风区空速相对前一种情况会低一点，顶多是下降时间长一些，也不会太严重；
飞机自动驾驶，在顺风区由于显示空速较低，同时升力不足，机师选择加速拉机头，可能会导致速度增加较慢，恢复平稳所需时间变得更长；
飞机自动驾驶，在逆风区由于显示空速较高，机师选择减少油门并减少空速，最后会在逆风区遇到空速严重不足，此时所需时间就会变得很长，如果再加上拉机头，后果可能会很严重。

当然了，前面的分析基本上可以当我胡诌，因为本人非专业人士。但是有一点可以确认，如果你遇到突然往上升的感觉时，说明已进入乱流甚至微下击暴流得影响区域，赶紧系好安全带是一个保本的选择。毕竟你不知道机师会如何选择，比如降速、拉机头，千万别到了后面抛起来了才后悔。

思想的代沟

2012-05-13T20:06:00.000-07:00

--- 前传 ---

本来不想这么早聊这个话题的，总觉得不合适。可是今天看一微博，说某市名牌中学择校费过亿，校长控着，还说这是一个没有底线、没有道德、没有责任、没有监管的黑企业，就这么教育着我们的未来下一代。这个说法有点问题，比如说择校费也不完全校长说了算，再比如监管当然有——这么肥的差事，能少了教育部一份？记得以前看过一篇文章（按照国内说法，这是一个谣言，嗯，你懂的），这作者传说是某市重点中学的一财务，控制着择校费的小金库。后来因为和校长不和，黑了这笔钱偷偷移民走了。因为这个小金库建立的时候，官方还没有注意择校费的事情，所以不能报官，当然也更不能让民众知道。后来这“择校”的词语成为非常流行的词汇，官方一算发现好大一块肥肉，于是后来打着监管的旗号，要求到官方那边交。学校肥肉没了怎么行，于是又换个名目叫做择班费，原来多少还是多少。当然，这是个传言，我信不信不重要，关键是会不会有人信。

可是这些问题对于不同年代的人想法会全然不同，比如祖父辈的就曾跟我说：千万不要到外面乱说话！后来等我三十而立的时候，这句话的背后含义才向我揭开：那个年代少有不慎的就会被斗死，更何况像那两位老者，一家是乡下大地主，另一家则是城里大地主，在某某滩还小有名声。就这样的背景，在那个年代没有被斗死，就已然是个奇迹了，而他们居然没有被批斗过。当然，他们什么都不敢跟下一代说，于是有一天要填身份的时候问老者，老者答“干部”，结果被那时候的学生追问什么干部？老者再一次给出了神奇的答案“学生就是干部”。然后是写身家背景材料，照样是写得滴水不漏。下一代这时候这才明白是多么恐怖的事情，而她之前还在向往着革命，向往着保卫领导人，向往着打倒一切。这个红色的小卒想要拱过河，杀将那头想象出来的黑帅。结果这时他才明白，这某国象棋里面还有一个游戏规则是红色的车马还可以吃红色的子儿。简直就是走偏一步就会被自己人杀害，然而之前一点也不知道这盘棋会这么危险。当年说这话的老者，已经走了。

我的另外两个老者显然没有那么的明智，导致的结果是我的上一辈还在娘胎里面的时候，就跟着母亲蹲监狱，一出生就分开。最后折磨十多年后，阴阳两相隔，其后还被乱葬。时隔数十年后，终于挑了个良辰吉日，重迁吉地。当时，我上一辈人描述，有七彩云霞飘然而知，盖过漫天烈日。于是整个过程在清凉爽快的环境下完成，仿佛上天有灵。我的上一辈从未有明显的信教历史，更多时候的言辞似乎是无神论者。然而这一描述却无法超脱中国传统的神怪幻想，但于我仍是可以理解的。这两位老者中，得以苟活的其实是当年某纵队的一不小官员，后当某地重要领导。说其苟活，不是肉体遭罪而是精神摧残。记得本人考取大学前一日，他在梦中乱吼乱叫：你个某某党狗贼……我问为何如此，家人告知他一直觉得有特务在追杀，所以从来不透露其生日，到现在大家都不知道他星座为何，这日梦魇大概类似。另一位早已仙逝的，家为乡绅，从未做恶。与此相反，加入革命的红旗时，亲自说服其长辈，亲自取出家中所有金银财宝全部献给党。后来还将除了祖屋和一亩三分地之外的所有地产，全部分给乡民。他是当地加入红旗的第一人，而后来等待她的后果居然是如此不堪。

最近又和另一位无任何血缘的开店长辈聊天，席间我说到近期看到的一个微博，说国内的教育无底线，因为学校本身就没有底线，并深表认同。然而此长辈则表示不认同，他觉得国内是有底线的，并笑称当年他的想法如我一样，现在则转过弯来了。他说，其实对于当官的，最重要的是不能丢了其工作，否则就没有生活来源了。因此对于政府来说，搞到像他那样的企业完全没有必要。虽然他也承认办个企业也有很多不合理的事情，比如税控机的一群人会来揩油，比如说各种的莫名其妙的监管和认证。但他坚持认为，搞这些事情的人，是为了不要出乱子，影响了他的前程。而且再说了，将所有企业都搞死了，钱哪来？所有人都丢掉就业机会，不都会找其算账么？而我却坚持认为，也许不会大面积的主动把企业搞死，但是这证明不了他不会莫名其妙的搞死个别企业，或者说在这个国度里面，这种灾难会不会降临到自己头上，是完全无法预测的。于是他非要我举一些例子，我只好搬出西南某市的例子。他面带威色的说，那些企业一定和某些势力参合在一起了，不是这边就是那边，言下之意是那是他们活该的。我只好笑称“是是”，然后像个办法圆场过去了事。

显然，这位长辈的思想就是和我有极大的代沟。一个可以和金钱纠缠不清的官府，一个可以为钱分裂两派的官府，一个可以不按法理（也就是规矩）出牌的官府，怎么可能对无钱无权的老百姓，突然就不纠缠金钱了，突然就爱民惜命了，突然就法治了？他的不会搞死企业理论，用糙理来说就是：宰相为了自己爽，会随便乱搞天下所有女人。当然，不会都搞死，不然他到哪里去爽呢？再说了，大家都被搞死了，所有男人都来问罪他也受不了。言下之意就是，宰相他来搞搞你的女人，只要不搞死，你就配合一下，说不定还赏你一点钱。只要你女人不死，你还是能爽的。这样的逻辑我是完全无法认同，即便是在你没有能力保全自己，做出强硬的反抗时，你也应该从道义上保护你的女人，还有别人家的女人不受侵害。你可以退一步，表面配合，暗地里弄得宰相很不舒服但又说不出来。如果智商到不了那个地步，你可以再退一步，携家带口离开这个地方。总之，不能让这样的宰相有爽的日子过，至少不能让他这么容易就爽了。配合宰相？我真心做不到，且不说他是不是我的杀父仇人。

其实在这样一个官府里面，我猜只有两种人存在，一种是官府以外的杀父仇人，另一种是认贼作父的不要脸的小人。

以上为纯小说，描述的是苏联时代的某个人。嗯，你懂的。

---- 后传 ----

和长辈聊天的时候，还提到了许多事情，比如移民，比如食品安全，比如教育。他以过来人的身份说了以下几个论点：

如果有识之士都走了，谁来救国；
出去之后发现，那是人家的地盘，为什么只有人家地盘才有；
出去之后还发现，国内挣钱国外花，几乎没有存下钱；
国内食品安全也没有想象的那么严重。

论点1立论不错，如果他说，我们就是要在这样的环境中，如何如何改变宰相的行为，那我尚且可以认为算是有胆有识之士，可以佩服之。可惜后来一拐，居然拐到如何配合宰相爽的论述过程中去，显然和论点立意矛盾。这让我无力吐槽；

论点2立论也比较有意思，可惜同样的，后来全然没有讨论为什么，也没有讨论如何让这里有，只是在维护着宰相的爽权，替宰相说话。这也没什么好说的；

论点3立论就已经比较偏颇邪乎了。没错，有很多人出去之后是呆不住的，但也有呆住的。我的亲戚有不少就只身闯国外，移民了。以他们当年的文化水平，能力水平，尚且可以生活，何以今日我们就一定不行？况且他还犯了这么个错误：国内挣钱，让老婆国外花，让后代上那边的私立，这自然是存不下多少钱。除非你能力真的很强，这当属凤毛麟角。可是国外的生活一般都是国外工作国外花，当一个平凡而又尊严的人，而不是家产万贯却以舔脚为生。为何非要私立，为何非要荣归故里？平凡而惬意的度此一生不也是一种生活么，不更应该是绝大多数人应该起码享有的权利么？也许前路会有坎坷，但我真无法面对国内的生存环境，我无法想象让后代生活在这种无时无刻不在的恐惧中，也就是他的论点4。

论点4基本上我完全无视，况且他自己也承认空气确实很差。我不知道一个空气很差，还遮遮掩掩，找茬赖美帝国主义的官家，如何能大大方方承认食品的问题，然后认认真真地整治。基本上国内的所有处理这类问题的思路，都是：先盖着，然后再盖着，实在盖不住了，终于盖着了。从某种典型性疾病，到各种轻度追尾，大头娃娃，某种捐献体液卖钱然后得了某种病而严重威胁整村人生命的事情……我都懒的提起，大概会被选择性的屏蔽。最近又有药壳子时间（包括果冻、某种酸奶……），基本上我们已经基于麻木而“免疫”了。

他说：吃那么一点不会得癌症，自己注意一点到卫生一点的地方就餐，没事的。你看，那么多外国人在中国，他们不也没事么？

啊，这是多么“强大”的论述啊！那咱先说说自来水的问题，自来水不合格都知道吧？那再说说特供食品的问题，如果说一般食品不存在问题，为何要搞昂贵的特供？再说说老外的问题：你难道是说要我们赚老百姓的钱，吃老外价格水平的东西？国内货币如果按照住房价格参照，相当于澳大利亚元的1/2.5（同样工种，国内300个月税前可买一套住房，澳大利亚则是120个月），参考其它非食品因素基本也不相上下。而澳大利亚在外就餐，一顿饭人均约30已是相当好的了，按照前面的购买力平价，大约相当人民币75元。在国内吃个稍好一点的，人均50-60很常见。可我真心不知道，那些50-60的餐厅会否有地沟油，谁可以保证这一点？或者你一顿多少钱可以没有地沟油、重金属、毒农药、染色剂、工业明胶？75？那我还不如去澳大利亚生活呢。

关于癌症，那真是站着说话不腰疼。癌症这玩意儿以目前的科技，根本无法预测，但是肯定和环境有关。据说某市有很多个环，越往里癌症率越高。有一次我参加某饭局，局中一人做保险，谈及这些数据，大家都瞠目结舌。然后还说到认识的某A如何癌症挂掉的，某B又是怎样在怀孕的时候发现得癌症，小孩出生没一个月就走了，以后这个小孩体内有原癌细胞会很高等等。最后这个话题以尴尬的平静，以及突然的转移话题而结束。谁都不愿意提这样的事情，因为大家都知道自己中招几率有多高。本人也曾经腹部不适，虽然目前诊断说是没事，但当时的恐惧可以说是空前的。你不得不思考，这样的饮食和消化道癌症有多大的关系；你不得不思考，这样的空气与呼吸系统的癌症有多大的关系；你不得不思考，这样的工作环境与其它类型的癌症、心脑血管疾病有多大的关系；你不得不思考，我怎样能够降低这样的概率，尤其是你小孩遇到这种问题的概率。

如果说，前传谈到的是无耻者无畏，后传则是无知者无畏，合起来就是无耻无知者大无畏。

当然了，后传说的是英格兰某时期的事情。嗯，你，也是懂的。

那都是些什么牛人啊……

2012-05-08T22:35:00.000-07:00

终于翻译完狭义相对论发现史了，共计约117kb……

物理学这玩意儿还真不是一件容易的事情，你不仅仅要懂物理，还需要懂数学的一堆乱七八糟的东西：从流形到群论，从平面到立体然后N维，什么标量适量，欧几里德空间，非欧几里德空间……而且你还要有足够的想象力：为毛光速就是恒定的呢？光速恒定，且光速不取决于光源速度，那么时间会发生什么样的变化。

关于相对论的建立，我们来回来的看到的都是一些巨人，他们从我们这个莫名其妙的世界中寻找出各种线索，然后猜测假设以至最后给出了正确的公式。他们是：麦克斯韦、洛仑兹、庞加莱、朗之万、索末菲、普朗克、闵可夫斯基，以及大名鼎鼎的爱因斯坦。

之所以说物理学这个玩意儿不容易，还有一个原因是，我们可以看到有一些已经参与相对论类似理论研究的物理学家，却因为种种原因一次又一次的提出了错误的理论，甚至这些理论最后是自相矛盾的、不完整不一致的，比如说亚伯拉罕。在翻译的过程中，一次又一次的看到他的出现，不过几乎每次都是跟着一句话“……错的”。唉，感情基本上在这里充当了绿叶或者龙套的角色，就是要衬托出前面那些人的强大。

翻译过程中印象最深刻的是这三个人：洛仑兹、庞加莱还有闵可夫斯基。实际上爱因斯坦的广义相对论，包括之前所有人对这一类似理论的所有尝试，都是在讨论如何让洛仑兹发明的洛仑兹变换符合（伽利略提出的）相对性原理，而庞加莱则是在爱因斯坦出现之前，所有提出类似理论的人当中，最为正确的一个。事实上，庞加莱的公式基本上已经和相对论没有多大差别了，只不过有这么两个问题：
太过执着于电磁世界观，导致没有想到这是一个真实世界的运动学问题；
没有放弃以太概念，导致仍然有“真实的”和“表观的”数据量之分，同时静态以太这种概念也导致了特殊参考系的问题，对于解释相对性原理不利；

其实，爱因斯坦只不过在他们的基础上做了很简单却很关键的那么几件事情：1、坚持相对性原理而放弃了以太；2、假定光速对于任何观测者而言都恒定。剩下的部分可以看作把庞加莱的x'、x、t'、t等两组概念，合并成x、t等一组概念。可以说庞加莱和爱因斯坦之间的成果，从数学形式上说差异真的很小，可最后的结论却是由比较大的差异。（我都感觉为庞加莱唏嘘不已。）

至于闵可夫斯基，其实真的很牛，他把这个物理理论彻底的从电磁学的范畴解放出来，转变成一种时空概念，比如世界线之类的。实质上狭义相对论确实是一个时空上面的问题，通过几何的方式来展示确实是更加直观和更加有效的，也更加贴近这一理论背后的真实含义。连爱因斯坦最后都不得不承认其工作的重要性，甚至他后来的广义相对论也是在闵可夫斯基的时空模型，及其相关的数学工具的基础上进行的。可惜闵可夫斯基属于数学空间方面的专才，对于物理意义的理解尽管也算一等一的高手，但和超一流高手之间就还是有那么一点差距。尽管他也提出了一些一统理论，但最后广义相对论的奖牌最终还是被爱因斯坦拿去了。

看那个时代的历史，真是感觉太壮观了，那么多的物理界高手在那么短短的半个世纪内发展出这么强大的理论，以至于所有后续的理论基本上都在这一基础上前行。说到这里，不得不提一个非常出名的照片：

第三排：奥古斯特·皮卡尔德、亨里奥特（en:E. Henriot）、保罗·埃伦费斯特、爱德华·赫尔岑、顿德尔（en:Théophile de Donder）、埃尔温·薛定谔、维夏菲尔特（en:E. Verschaffelt）、沃尔夫冈·泡利、维尔纳·海森堡、福勒、里昂·布里渊，
第二排：彼得·德拜、马丁·努森、威廉·劳伦斯·布拉格、亨德里克·安东尼·克雷默、保罗·狄拉克、阿瑟·康普顿、路易·德布罗意、马克斯·玻恩、尼尔斯·玻尔，
第一排：欧文·朗缪尔、马克斯·普朗克、玛丽·居里、亨德里克·洛伦兹、阿尔伯特·爱因斯坦、保罗·朗之万、古耶、查尔斯·威耳逊、欧文·理查森1927年第五次索尔维会议参与者，摄于国际索尔维物理研究所

这里面的人都是一群什么样的人呢？这里面的一共有29人，其中的17人获得了诺贝尔奖，17人……或者可以这么说，如果当时正好一个炸弹落在会场，估计我们今天就活在20世纪30年代了。没有网络，没有计算机，没有液晶显示器，没有……

狭义相对论发现史翻译有感

2012-05-04T02:01:00.002-07:00

最近因为看了一期NGC的Beyond the cosmos，再次对相对论、量子力学等一系列知识产生了兴趣。尤其是想到这些理论中的内容是多么的违反直觉，同时却又有无数的实验证明它们是对的，于是又整天开始想这些无聊的问题了。

关于电磁波

记得高中光学讲电磁波的时候，估计都会听过波粒二相性的说法，当时听课的时候真的不知道怎么去理解。当然，现在算是知道了，其实科学界早已抛弃这种说法，转而支持“几率波”的说法。或者说，光波并不是一种机械波，而是光子到达某处的概率有多少的一种几率波。所谓波粒二象性，只是当时人们无法脱离机械波的条框来看到光波所造成的幻觉：一方面双缝实验证明光具有波的特性，另一方面又存在胶片上面确实可以录得诸如一个光点这样的事实。正是因为这种错误的假定，使得人们开始寻找光“机械波”的载体——以太（当然，还有其它的原因）。事实上，后来发展出来的量子力学便是基于“几率波”这一假设，然而根据该假设所推导出来的众多理论，是非常的违反直觉的，比如量子纠缠。当时这个现象让爱因斯坦一度对量子力学嗤之以鼻，他认为这只是一种数学幻觉。没错，除了相信量子力学这个“邪教”的一小撮“不明真相的群众”之外，大部分人都无法理解这一个学说，或者说无法接受。甚至还有人因为无法接受这种理论，而去设计一些实验来尝试证明量子力学是错的。这些实验最后无一例外的得出了非常让人高兴的结果——量子力学是对的。（操，有什么值得高兴的，应该沮丧才对吧。不，因为目前为止没有比量子力学的能够更加准确预言世界的物理理论了，证明它是失败的才让人沮丧呢。）其中一个实验就是证明量子纠缠的，关于这个实验的解释，回头再补充吧。嗯，重要的是，当时爱因斯坦说过一句话：“上帝不会掷色子”，而波尔回应道“不要再告诉上帝他应该干什么”。而这场纠纷最后居然是波尔赢了。没错，伟大的爱因斯坦，搞出相对论和核弹的爱因斯坦，居然输了！真让我感到悲伤。

关于光速

说到电磁波，就不得不说光速了。这个玩意儿太神奇了——“对于所有观测者而言，不存在任何物体的速度能够超越光速”，基于这一个假设，后来推导出了更多违反只觉得东西：运动物体的时间会发生膨胀（无论方向如何），长度会收缩（在运动的径向上），质量会变大（在运动方向的横截面上）。后面的推论就算了，光是想下面这个问题，我就表示无法想象结论为何：
一个位于地球1光年外的X星球，以近乎光速的速度靠近地球，上面的X星人朝着地球发出一个近乎光速的电子。请问，最后地球人与何时，分别遇到了哪一个时刻的X星球和X星人发出的近乎光速的电子？

发现历史

其实，这些发现也是一步步搞出来的。就拿牛顿的三大定律来说，对于今天的我们来说，这太容易理解了，可对于欧几里德那个时代的人来说，就非常的违反直觉：物体不施加力不久是应该最终会停下来么？所以物体要保持匀速运动，就必须持续施以恒定的力。我们普通人今天对于相对论等问题的困惑，无意于此。甚至对于当时参与这些理论发现过程的神级人物
来说，其懵懂的程度不见得比我们好多少。

最近我在翻译英文维基百科上关于狭义相对论的发现史（传送门在这里，以后翻译完成后的正式地址应该是这里），里面所描述的各种大牛几乎都曾有过错误的认知，作出过错误的假设，得出错误的结论。这些大牛包括庞加莱、洛仑兹、爱因斯坦……当你们看他们这些人认识世界与思考过程的历史资料，你心里面就有这么一个感觉：好大一座山啊！我还想到了另一个词：屎山。

我之所以想到后面那个词，是因为如下的几个事实：

有个经典的高数笑话，高数课可以用如下两句话描述清楚：这他妈是个啥？这他妈又是个啥？
连这些大牛们都弄出很多错误的想法来；
通常搞不懂或者搞砸了的时候，老外用shit，也就是“屎”这个词来表达他们的心情。

有意思的是，爬这座屎山的我，居然感到无比的激动。

最后

中国人对于知识的渴望程度，无论用总量还是人均的口径来衡量，都是个效果。比如在5月2日时，维基百科上面的条目数中文位居12，后面跟着个越南。越南是什么货色，居然有资格紧随中国……如果说日本的人均拥有词条量是中国的20倍可以用人均GDP落后来解释，越南人均拥有维基百科词条量是中国人均数的10倍，我不知道还能怎么解释。功夫网？好吧……我表示不想找这种借口，尽管我也表示对于功夫网及其发明人和接班人的无比鄙视。

（5月2日不知因何原因，中文维基百科疯长了1万个条目，于是乎瞬间超越瑞典语。就像以前有人跟我说，其实我们比阿三同学还是好不少的那样，我很想说咱们能不这么低标准么？不过鉴于我们连越南相比都有点吃力，这句话当时就咽下去了。突然想起来，光程兄如何了？貌似越南现在都不搞这一套了。）

喜剧了，D800完胜5DIII

2012-04-27T23:41:00.000-07:00

D800一发布，3600万像素就相当震撼了，挑战了135传感器的像素面积极限。当时其实我蛮不爽的，因为我一直认为高感对于抓拍很重要。之前用过一次7D，被那个垃圾级别的高感给震撼了，昏暗的室内拍出来的照片基本上和明亮场景下的卡片机一个级别。这么小的像素面积，高感估计不会很好。以DXOMARK的过往记录，用D700的可用高感推算，如果技术没有改进的话，D800的可用高感估计只有1400左右。当时我就想：啊！废了！

接着5DIII发布了，像素没有质的提高，看来是要拼高感了。当时估计5DIII的高感表现怎么着也会比D800要强，于是相当郁闷。因为考虑到佳能的机器，只要是5D及以下，高感表现完全一样——800左右，这个数字已经维持了至少4年以上了！再加上人家告诉我，佳能低端机器没有色彩曲线，对焦如何烂，测光对焦如何不能联动之类的。未来要是想要双机双镜，佳能简直是……尽管镜头卡口规格有优势，可也经不起这么个糟蹋法。

可后来看的各种测评图片，喜剧效果就开始显现了。先是发现D800比D700的高感还要好，无论是同样的尺寸下面，还是同样的放大比例下面。然后又发现，D800和5DIII比，在ISO1600及以下全面优胜，3200及以上，只要D800有那一档，基本上和5DIII一样的表现。关键是，5DIII涂抹太他妈严重了。我记忆很深刻的是一张对比图，右上角有一个黑色的纸标牌，这个标牌其实不平整，有一些稍微亮一点的折痕。当时是四款机器对比：5DIII vs D800 vs 适马的某型号 vs 845D，其它三个都看到折痕，唯有5DIII是一抹黑。还有很多不那么明显的细节，也是被抹掉了。

再后来，dxomark出来了d800的测评，ISO居然2853！尼玛怪兽啊，怎么可能？这一项有史以来排第三（第一是怪兽级的D3s，第二是后继者D4，D4像素多出33%来，略降一点正常）。而且此机器居然Landscape得分排第一，动态范围高低意思就是亮部暗部的细节会非常好。更变态的是色彩位数，居然在135里面排第一，即使拿120一起比，也拍第三。可以说，这基本上是有史以来最强悍的135电子单反。

即便是这样，我还是以为5DIII出来之后高感会让人吓一跳：毕竟5DIII的像素密度比D800低很多，就算高感没有强太多，也至少要和D800一个等级吧？结果让人失望，居然只有2293。好吧，这也是一个不错的数字，怎么也比5DII的1815好不少。可是……居然败给了像素密度比它还高将近一倍的D800，我这不知道到时候拿什么来宣传这个机器了。是说5DIII的比D800高感好呢，还是像素少呢？我仔细想了一下，比D800有利的地方恐怕只剩下：

不追焦的情况下连拍数稍高一些；
对焦点数稍微多一些；
设想能够连续拍摄超过30分钟（好吧，如果有这么高的要求，估计HDMI直出更有诱惑力吧？；
镜头潜力；
广告和营销；
也许会出现的价格优势，也许；
也许产能会好一些，也许。

这些优势几乎和技术无关，基本上未来4年佳能的套路只剩下：

加大广告和营销的投入；

加大产能，确保在尼康断货期间确保足够的供货；

降价；

出一个升级版；

出一些个变态镜头。

还有吗？没有了。现在要不是大面积断货，估计都要忍不住入手D800了。

SqlServer 2005如何改善datalength计算的性能问题

2012-04-15T21:37:00.001-07:00

假设数据库中有一个表photo，其中包含2个key组成联合主键，分别名为userId和photoId，以及一个image类型的字段stream。此时有两种不同的思路，一种是在保存的时候进行计算，并存入第三个字段dataSize，另一种是每次都直接使用以下语句进行计算：
select sum(datalength(stream)) from photo where userId=@userid

第一种方法一般来说都挺不错的，但是有那么一个不那么完美的问题：很难确保数据一致性。假如某一次更新中的代码新添加了一种对stream进行修改的特殊代码，但很遗憾忘了修改dataSize字段。更新之后，程序不会表现出明显的异常，有可能会跑了很长一段时间之后才会发现。而发现之后，就需要专门的小程序来重新修复。并且修复之后，以我的经验，一定会有用户不认可发生的变化。也许有人会说，图片不都是只插入不更新的么？那我们就再来想另一个场景：这是一个类似Evernote的应用，用户在里面保存的文字数量也是限量的，同时也是需要修改的。有人还会说，修改stream的代码不应该都在一起吗，不应该修改的时候都会修改dataSize吗？问题是，应该的事情总有不发生的几率，而小概率事件则必然发生。

第二种方法则保证了每一次都是准确的，也不需要代码进行相应的计算和更新，于是就没有了前面的一个问题。这种方法在每个用户的数据量较少的时候问题不大，但是在数据量巨大的时候，会面临非常严重的性能问题。这是由Sql Server的数据存储结构所决定的。

在SqlServer当中，数据库每8K为1页（Page），8页为1片（Extent）。而一行数据中的定长数据通常都存在一个页当中，而不定长数据如varXXX一类，只要这一行数据没有超出8060字节，也会存在于当前页中。上述的数据成为行内数据（In_Row_Data）。而对于一行超出8060字节的情况下，不定长数据会存入超长数据页（Row_Overflow_Data）。而类似Image、text等类型的数据，则会保存在大对象数据页（Large_Object_Blob，简称LOB）当中。关于这些知识的解释，请参见此处的官方说明。

可惜的是，上述说明中并没有详细解释超长数据和大对象是如何在行内数据中记录的。对此，我们可以通过下述方式进行分析。

首先，我们需要通过下属语句找出保存数据的某一页：

select first_page from
sys.system_internals_allocation_units as u inner join
sys.partitions as p on u.container_id = p.partition_id
where
p.object_id=object_id('photo') and p.index_id=1 and u.type=1

这一个语句会得到一个类似如下的数据：
0x876543210500
这个16进制数据实际上分为两个部分：0x21436587是页码，而0x0005则是文件号码。注意，这两部分都需要对原始数据进行一个颠倒，有点类似BigEndian和LittleEndian的颠倒过程。

得到这两个数据之后，我们进一步将页码部分转换为十进制558065031，将文件码也转换成十进制，然后输入如下的命令：
dbcc traceon(3604)
dbcc page(databasename, 5, 558065031, 3)
dbcc traceoff(3604)

这一个命令会在消息中输出具体的存储信息，我们在里面首先找到这么一行数据：

stream = [Textpointer] Slot 0 Column 5 Offset 0xab Length 16

请记住这个偏移量0xab，然后在这一行往上找第一个Memory Dump，比如：

Memory Dump @0x0000000024A9C060

0000000000000000: 30008d00 653e0500 02000000 80000000 †0...e>..........
0000000000000010: 00000000 16640000 00ecf496 00749800 †.....d.......t..
0000000000000020: 00000000 00e52001 00000000 00000000 †...... .........
0000000000000030: 00ffffff ffffffff 60000000 00000000 †........`.......
0000000000000040: 00000000 0000f03f d0000000 00ecf496 †.......?........
0000000000000050: 00749800 00000000 00000000 0013f8fe †.t..............
0000000000000060: f1000000 0000f03f 00000000 0000f03f †.......?.......?
0000000000000070: cd000000 00030000 00000000 01000000 †................
0000000000000080: f89e015d 4a49ab3f 00000000 002f0000 †...]JI.?...../..
0000000000000090: 009c0370 7b0600ab 00bb80cb 00cb00cb †...p{...........
00000000000000A0: 00ef0001 4f1a4ecb 4ecd7e00 00f2fef8 †....O.N.N.~.....
00000000000000B0: 13000010 00000005 00010020 20202020 †...........
00000000000000C0: 20202020 20202020 20202031 64616130 † 1daa0
00000000000000D0: 6230332d 62313866 2d343462 302d6231 †b03-b18f-44b0-b1
00000000000000E0: 62302d35 64353739 38366164 623037††††b0-5d57986adb07

途中高亮部分就是刚才偏移量所指出的16个字节的数据。根据观察，后8个字节10000000 05000100 和堆数据的行定位数据结构（row locator）非常相似。而该结构的含义如下：
页码（4字节）文件号（2字节）槽号（2字节）

需要注意的是，这是Little Endian编码格式。经过转换，页码为16，文件号是5，槽号为1。然后我们再次执行dbcc page命令如下：

dbcc traceon(3604)
dbcc page(databasename, 5, 16, 3)
dbcc traceoff(3604)

我们在消息输出中，找到槽号（Slot）为1的位置，就可以看到如下的数据：

Blob row at: Page (5:16) Slot 1 Length: 4900 Type: 3 (DATA)

Blob Id:21960150089728

而上面的二进制大对象块（Blob）编号21960150089728的十六进制值为0x000013f 8fef20000，正好是上面高亮部分十六个字节的前8个字节。换句话说，这个字段的大小并非存在行内数据当中，而是存在于大对象页当中，也就是上面的黑体字所显示的地方。

因此，当我们执行类似select sum(datalength(stream)) from photo where userId=@userid 这样的语句时，数据库系统再怎么优化，也需要读取这些页，而不是只需要读取行内数据即可。由于大对象通常都很大，其数据密度是相当低的，通常一页当中只有3-4行对应的字段值。除此之外，大对象的保存顺序和聚集索引不同，和数据的增删改的顺序有关，而与聚集索引本身的顺序无关。于是，我们基本上可以根据如下的方式估算一次上述查询所需要读取的数据量：

行数= select count(*) from photo where userId=@userid

读取次数 = 行数

读取数据量 = 行数 * 8K

也就是说，当用户数据达到1000行时，读取的数据量可能会达到8M，而且还是随机读取。而用两块普通15krpm的SAS硬盘做镜像，随机读取能达到4MBps就不错了。因此每次查询将会消耗2秒的时间，其它的查询只要内存中没有缓存，都注定需要等待。

那么，是否只能够退化到添加一个静态字段，然后通过代码来更新的境地呢？其实还有另一种方案：添加计算字段并对其做索引。这种方案对于查询远多于修改的系统来说，是一个很不错的选择，方法如下：

首先，在数据库的属性中，修改算术终止已启用（ArithAbort）为是（True）。这一步非常关键，否则当你完成后面两个步骤之后，将会无法对数据进行更改。然后用下列语句添加一个计算列：

alter table photo

add dataSize as (datalength(stream))

然后再通过下面的语句添加一个索引：

CREATE NONCLUSTERED INDEX [IX_photo_datasize] ON [dbo].[photo]

(

[userId] ASC,

[photoId] ASC

)

INCLUDE (

[datasize]

) WITH (STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = ON, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)

需要注意的是，上面的ONLINE一定要设置成ON，这样可以让系统不要锁柱整个表（仍然会短暂锁住，但几乎感觉不到）。而datasize一定要设置成包含列，因为这一列基本上不会用于检索，出现相同值的可能性也非常低。而是否应该添加其它的列（包括包含列），例如photoId，则需要根据根据实际情况分析处理。

这三个步骤完成之后，再执行查询select sum(datalength(stream)) from photo where userId=@userid，你会发现执行任务计划已经使用了IX_photo_datasize了！注意，你连sql查询语句都不需要修改，SqlServer会自动识别出datalength(stream)等同于datasize字段，而datasize字段存在于IX_photo_datasize索引。很先进吧！

看到这里，有人就会问了：为啥不直接添加一个持久化的计算字段呢？这是因为一旦设置为持久化，将会导致行内数据的结构发生变化——多了4个字节的数据嘛。于是，这将会强迫数据库系统对已有的数据进行修改。对于数据量较小的库来说还好，而对于数据量巨大的库来说，将会导致系统长时间锁定该表而无法正常提供服务。这在互联网应用上，通常来说会导致用户的强烈反应。当然，你也可以采取复制一个数据库，并且设定为只读的方式，让服务在只读状态下运行，于此同时则修整真实数据库，修整完之后再切换回来的办法。但是，为什么要采取一个这么复杂的步骤，来获得几乎相同的效果呢？

不过，需要注意的是，以下情况会导致索引失效：

查询中的函数不是计算字段中函数的一部分。比如说，查询字段设置成了IsNull(datalength(stream), 0)，而查询却为select datalength(stream) ……
查询中包含了某种导致索引失效的情况，比如：
select sum(streamsize) from
(
select row_number() OVER (order by userId, photoId) as rowno,
datalength(stream) as streamsize
from photo
where userid = @userid
) t
where rowno between (1, 1000)

对于第一种情况，你需要修改查询字段，而对于第二种情况，则必须修改sql语句，比如说改成如下所示：

select sum(datalength(stream)) from photo as p inner join

(
select row_number() OVER (order by userId, photoId) as rowno,
userId, photoId
from photo
where userid = @userid
) as t on p.userId = t.userId, p.photoId = t.photoId
where rowno between (1, 1000)

上述的方法有如下几个巨大的好处：

即便前期规划出现问题导致数据库结构不包含stream大小的静态列，也可以后期修改；
修改时服务不需要下线维护，同时也不会导致明显的服务阻塞感；
几乎不需要修改任何程序，即便需要修改，程序修改和数据库修改也没有严格的先后顺序，在同时修改完成之前，性能几乎没有明显的下降，服务连贯性非常好；
数据一致性非常好，不会受到程序设计、更新等人为失误的影响；
性能提升非常明显，由于数据密集度很高，甚至比静态字段效果还要好。

当然了，硬币的另一面是：

你需要修改数据库的默认行为（ArithAbort要改成True，一般影响不大）；
对于select * from photo where ...这样的查询，在执行计划中将会比原来多出一个计算datalength(stream)的步骤。不过由于stream本来就必须从文件中读取出来，因而计算datalength基本上不会增加可感觉到的运算时间；
存储空间和写入次数都比静态字段稍多一些。其实是多出2倍以上（假如索引去掉PhotoId列的话），但是因为每一行的数据量其实很小，因此通常可以忽略不计。比如对于1亿行的数据的表使用上述方法，可能会多出至少400MB的数据量。而对于有着1亿行数据的表来说，本身的数据量就不会少于2.4GB（4字节userId+4字节PhotoId+16字节stream的row locator），这还没有算上stream部分占用的空间。因此，基本上可以忽视其空间上的影响。

怎样，这个方案不错吧？

坚决捧庇

2012-04-10T21:09:00.000-07:00

2012年4月10日，在神奇的大地上发生了一件里程碑一般的事件：西南王被正式立案调查，原因是其家属涉嫌谋杀一个英国公民。有意思的是，也是用屁眼想也知道会发生的是，当晚开始，报纸电视媒体铺天盖地的出现了“坚决捧庇中央的决定”。我改了一下字眼，捧庇这个词在报纸媒体上对应的是拥护。拥，其实搞不好就是捧，捧臭脚的捧；护，搞不好就是庇，包庇的庇。

“这不是挺好的嘛？该处理的就处理，没有包庇啊，难道不应该拥护吗？”搞笑的是，3月30日至4月3日还来了个轰轰烈烈的微博禁止评论，集中处理谣言的行动，甚至据传抓了很多人。奇怪了，都传什么谣言呢？现在不正在变成中央文件了么？感情原来是“朕还没发话呢，尔等则能泄露天机”！跟曹操似的，杨修，该杀。

这种堵塞大众口耳的自欺欺人行为，实在是一种猪头作为。其后果自然是有能力的人可以通过强力行动，将其违法行为遮蔽、消除，并迫害知情人使其无法透露真相。除此之外，还可以通过各种渠道，强行发布美化、神化其形象地位的谣言。这不是捧臭脚是什么？这不是包庇又是什么？

有意思的是，3月9日还信誓旦旦声称对其亲属的诋毁是谣言云云，时隔一个月零一天就被公布亲属涉嫌谋杀外国人。这是多么的讽刺啊！而这个家人谋杀藏尸的说法，在之前的微博上就已经被流传。我最早好像是在杨海鹏在上海的微博中看到的，当时没有提外国人，昨日听说后感觉甚是突然。而3月底4月初清洗微博，我也曾经想过那位杨先生是否已经被抓。前几天一翻微博，发现过的好好的，还说了“我只不过提前十来天说了中央要说的话，又不是谣言，怎么会不安全呢？”诸如此类的。现在看来，果真如此。

而现在这个消息的官方，又可以琢磨出许多味来：

首先是薄熙来的狂妄自大，不学无术，自作聪明，最后玩火自焚。之所以这么说，是因为这显然是一个国际事件，这么大的事情，居然以为可以瞒天过海。以为可以漫天过海就算了，居然还以为有永远的朋友（估计自己洗别人脑洗惯了，自己都相信永远的忠诚了）。以为有永远的朋友就算了，居然在已然发生背叛的时候，还以为这事情能继续隐瞒下去。以为可以隐瞒下去就算了，居然忘了王立军去过美领馆。如果没有忘记，那就是居然以为美英会不知道这事，会以为不会给施加压力，会以为全部中央高层还有他的靠山都是他的伙计会为他抵挡乃至当炮灰。
其次也知道了为什么王立军能够笃信去美领馆一定能成。这是因为单单就这一件事情，就足以让整个高层不敢隐瞒真相。否则最终英国会不干，世界会哗然，多年以来包庇腐朽权力的公开秘密，就彻底变成公开的知识了。而公开则导致“立功表现”，同时成为“国际新闻”之后，最终开脱死罪的可能性就相当的高了。
最后，如果现在复盘事件发生开始的那一刻——王立军投奔美领馆，也许渝牌装甲车奔袭包围真是一个下下策。或者立刻软禁王立军家属，同时发短信告知“家属在我处，一切安好，你为我做贡献力保你无事。若有事，共进退”，会是更好的选择。而实际上事件的进展实际上是进入了囚徒困境：薄熙来先弃子搏自己的高升，而王立军则弃身份搏自己不被最严肃的方式处理掉。最终结果就是两者都没有好果子吃。

实际上现在的结果基本上是必然发生的，其必然性可能可以追溯到薄一波的父母那一代，至少可以在薄熙来那一代找到原因。一波同志没有教导好自己的小孩，居然发生儿子毫无底线批斗父亲，甚至到重庆后仍然重复着当年那些显然的错误。而这种教育缺失的问题，很可能是一波的父母就没有重视。而这种对后代不负责，乃至赞扬后背不负责任的精神，在某次对瓜瓜的采访中也可以看到。具体已经不记得了：大致是说瓜瓜很叛逆，父母觉得很可爱很特别之类。年代久远，有错勿怪。

而新闻内容更有意思：薄谷开来（薄熙来妻子）及其子曾经和被害人关系良好，后……。薄谷开来和张晓军（薄家勤务人员）有重大作案嫌疑。咦，为啥后面就没有“其子”的关系了呢？不好说，现在不知道。也许随着案情进展会变得更加有趣，因为现在已经彻底进入囚徒困境了：谁坦白谁从宽。而薄的倒台进程已经进入了不可逆的阶段，完全没有任何保其家的意义，外围的猢狲及其靠山，也没有任何必要进行保护，兴许踩上两脚才有利。于是张晓军还会爆出些什么，就真不好说了。至于其子，我胡乱猜测一下，兴许是有目的的保护，有人做出了极大的牺牲。（比如说，大包大揽。）

一个“唱红大黑”的演员最终倒在了“黑贪”之下，比当年“潜伏”的演员是逃犯还有具有戏剧性。

下面是一些链接：
http://www.iask.ca/news/china/2012/0410/128738.html
http://www.aboluowang.com/news/2012/0325/%E5%8F%97%E5%91%A8%E6%B0%B8%E5%BA%B7%E5%8A%9B%E6%8C%BA%E8%96%84%E7%86%99%E6%9D%A5%E4%BA%A2%E5%A5%8B%E9%80%BC%E5%AE%AB%E2%80%9C%E5%BC%95%E7%81%AB%E7%83%A7%E8%BA%AB%E2%80%9D14%E5%9B%BE-147838.html
http://www.aboluowang.com/news/2012/0215/%E7%8E%8B%E7%AB%8B%E5%86%9B%E5%AE%B6%E5%B1%9E%E5%9C%A8%E9%87%8D%E5%BA%86%E3%80%81%E5%8C%97%E4%BA%AC%E8%A6%81%E4%BA%BA%E5%9B%9E%E5%A4%8D%E6%98%AF%E2%80%9C%E6%97%A0%E5%8F%AF%E5%A5%89%E5%91%8A%E2%80%9D-144981.html
http://opinion.dwnews.com/news/2011-06-13/57801786.html
http://www.aboluowang.com/news/data/2012/0411/article_149041.html
http://beyondfirewall.blogspot.com/2012/03/319_22.html
http://www.wenxuecity.com/news/2012/04/08/1714907.html

.NET应用非托管内存异常的简单排查

2012-04-09T19:16:00.000-07:00

我们知道.NET应用如果出现问题，在Windows操作系统上面可以使用Windbg来查找问题所在。通常来说，.NET应用的问题会出现在托管部分。此时，只要我们的WinDbg在加载完CrashDump，或者附加上进程之后，就可以使用以下命令开始查找问题：
>.loadby sos clr
或者
>.loadby sos mscorwks
或者
>.loadby sos coreclr

其中第一个是.NET 4.0版本所使用的命令，而之前的其它桌面版需要使用第二个，最后一个是SilverLight 3/4所使用的版本。然后，我们就可以使用!eeheap/!dumpheap/!dumpobj之类的命令来进行内存问题的排查。

但是，有的时候问题并非在托管部分出问题。比如说，当我们输入：
>!eeheap -gc
之后显示：

……
------------------------------
GC Heap Size: Size: 0xa0ec288 (168739464) bytes.

而这个Dump显然有大几百兆甚至1GB以上，此时就需要考虑非托管部分的问题了。首先，你需要输入：
>!address -summary
这一个命令可以给出地址空间的使用情况，这时候可能你会发现地址空间被字体占用光了，或者如这里所显示的那样，可能被非托管代码所占用了：

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free 382 7fe`61d74000 ( 7.994 Tb) 99.92%
2825 1`8c91f000 ( 6.196 Gb) 95.75% 0.08%
Image 1986 0`103e2000 ( 259.883 Mb) 3.92% 0.00%
Stack 174 0`014bd000 ( 20.738 Mb) 0.31% 0.00%
TEB 58 0`00074000 ( 464.000 kb) 0.01% 0.00%
NlsTables 1 0`00033000 ( 204.000 kb) 0.00% 0.00%
ActivationContextData 5 0`0000d000 ( 52.000 kb) 0.00% 0.00%
CsrSharedMemory 1 0`00009000 ( 36.000 kb) 0.00% 0.00%
PEB 1 0`00001000 ( 4.000 kb) 0.00% 0.00%

--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_PRIVATE 2290 1`8affa000 ( 6.172 Gb) 95.37% 0.08%
MEM_IMAGE 2716 0`11529000 ( 277.160 Mb) 4.18% 0.00%
MEM_MAPPED 45 0`01d59000 ( 29.348 Mb) 0.44% 0.00%

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 382 7fe`61d74000 ( 7.994 Tb) 99.92%
MEM_RESERVE 1685 1`4709a000 ( 5.110 Gb) 78.96% 0.06%
MEM_COMMIT 3366 0`571e2000 ( 1.361 Gb) 21.04% 0.02%

--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READWRITE 1513 0`4427a000 ( 1.065 Gb) 16.46% 0.01%
PAGE_EXECUTE_READ 342 0`0d3e9000 ( 211.910 Mb) 3.20% 0.00%
PAGE_READONLY 906 0`03837000 ( 56.215 Mb) 0.85% 0.00%
PAGE_WRITECOPY 306 0`01978000 ( 25.469 Mb) 0.38% 0.00%
PAGE_EXECUTE_READWRITE 147 0`006b8000 ( 6.719 Mb) 0.10% 0.00%
PAGE_EXECUTE_WRITECOPY 74 0`0020a000 ( 2.039 Mb) 0.03% 0.00%
PAGE_READWRITE|PAGE_GUARD 77 0`0010a000 ( 1.039 Mb) 0.02% 0.00%
PAGE_EXECUTE 1 0`00004000 ( 16.000 kb) 0.00% 0.00%

--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
Free 5`16fea000 63d`67e66000 ( 6.240 Tb)
0`80be1000 0`1f40f000 ( 500.059 Mb)
Image 644`23535000 0`0125a000 ( 18.352 Mb)
Stack 0`00a40000 0`0007c000 ( 496.000 kb)
TEB 7ff`ffe82000 0`00002000 ( 8.000 kb)
NlsTables 7ff`fffa0000 0`00033000 ( 204.000 kb)
ActivationContextData 0`000b0000 0`00005000 ( 20.000 kb)
CsrSharedMemory 0`7efe0000 0`00009000 ( 36.000 kb)
PEB 7ff`fffdb000 0`00001000 ( 4.000 kb)

如果怀疑是非托管堆上面的内存泄漏（或者过度占用）问题，则需要继续进一步使用下面的方法来进行排查：
>!heap -stat
该命令将会输出当前存在的堆都有哪些，分别都有多大。比如，你可能会看到：

_HEAP 0000000009040000
Segments 0000000b
Reserved bytes 000000003ff80000
Committed bytes 000000002f5cb000
VirtAllocBlocks 00000000
VirtAlloc bytes 0000000000000000
_HEAP 00000000000c0000
Segments 00000004
Reserved bytes 0000000000800000
Committed bytes 0000000000706000
VirtAllocBlocks 00000001
VirtAlloc bytes 0000000004de0000
……
这样的输出，比如上面黄色高亮的部分，就显示已经提交的内存有794MB之多，显然不是托管堆169MB所能承载的。此时，你就需要进一步进行分析了。

等会儿，刚才的命令是否还有类似这样的输出呢：

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: ntdll!_PEB ***
*** ***
*************************************************************************
嗯，这时因为WinDbg还没有正确的配置上符号文件的路径。请点击File菜单中的Symbol File Path，并且在弹出框中填写如下路径：
SRV*d:\symbols*http://msdl.microsoft.com/download/symbols
并选择上Reload（或者关掉重开WinDbg），否则你将无法使用Google到的很多命令，比如：
>!heap -a 9040000
（会显示上面那一大段内容，外加“Invalid type information”这样的提示。）

如果你实在不想使用微软的远程Symbol服务器，或者因为网络原因无法使用，也可以在!heap命令后首先添加-p来试试看。比如说，将上面的命令改成：
>!heap -p -a 9040000

具体可以使用那些命令，还是建议大家使用!heap -?来查看。同时，上述临时方法输出的信息格式，与前一条命令的输出格式稍有不同，但基本不影响使用。

在使用上述命令之前，建议先针对较大的堆使用如下的命令进行分析：
>!heap -stat -h 9040000 -grp A

>!heap -stat -h 9040000 -grp B
>!heap -stat -h 9040000 -grp S

这几个命令按照不同的分类方法，对这一个堆进行分析，分别输出：
单次分配最大的几个分配；
哪几个大小的块的分配次数最多；
哪几个大小的块的总分配数量最多。

当你能确定某种大小的分配，其数量或者大小比较不正常，可以用以下命令进行查看：
>!heap -flt s 8000
这就可以打印所有大小为32K的分配情况，包括地址，输出可能类似如下：

……
   0000000009042cd0: 02010 . 07c20 [01] - busy (7c10)
000000000904a8f0: 07c20 . 07c20 [01] - busy (7c10)

0000000009061d50: 07c20 . 07c20 [01] - busy (7c10)
0000000009069970: 07c20 . 07c20 [01] - busy (7c10)
0000000009071590: 07c20 . 07c20 [01] - busy (7c10)
00000000090791b0: 07c20 . 07c20 [01] - busy (7c10)
0000000009080dd0: 07c20 . 07c20 [01] - busy (7c10)
00000000090889f0: 07c20 . 07c20 [01] - busy (7c10)

……

上述的输出可能会很大，甚至超出了WinDbg命令缓冲区的大小。因此，你可以通过下面的方式，将整个输出写入到一个日志文件当中：
>.logopen "c:\logfile\heap.log"
>!heap -a 9040000
>.logclose

针对怀疑有问题某一个堆上分配，可以使用如下命令查看其内容：
>db 90889f0
……
>d
……

如果这些内容是很容易辨识的文本内容，或者你对於这里面的二进制内容比较熟悉，就可以很容易知道大概会是些什么东西，可能是什么地方出现问题。但是，多数情况下是看不出来的，或者因为内容太多不可能注意筛查出有价值的内容。此时，我们可能需要查看这些堆上内存分配的调用栈情况。

要实现调用栈的分析，首先需要修改系统的一些设置，使得针对你当前这个应用的Dump会包含申请该堆的时候，调用堆栈的情况。也就是说，如果你不做如下的更改，将不知道这些内存是怎么分配出去的。修改的方法有三种：
1、运行命令"gflags.exe /i YourApplication.exe +ust"，这个gflags是WinDbg安装附带的工具之一，就在WinDbg所在的目录中；
2、在开始菜单中，WinDbg所在的位置还有另一个应用，就叫做gflag。这时一个图形化界面。在Image File的页面中输入你要调试的应用程序名称，例如YourApplication.exe，并且按一下TAB键。接着在下面的Create user mode stack trace database上面打一个勾，然后确定即可；
3、或者，你可以直接修改注册表。在“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\”当中添加一个YourApplication.exe的结点，然后在其上添加一个名为GlobalFlag的双字类型的值，值等于0x00001000（4096）。
上面这三种方法可以参见这里以及这里。

修改完之后，你需要重新在出现症状时做dump，因为之前dump的时候因为没有以上设置，是不会包含申请Heap时的用户空间堆栈情况的。而当你Dump完之后，记得用上述方法将之前的修改设置恢复原状。（我没有尝试过，不知道对于高负荷的线上系统，是否会造成很大的影响，最好谨慎一些。）

针对新做的dump，你需要再次使用上述方法，找到有问题的堆，再次执行如下的命令：
>!heap -p -a 90889f0

此时的输出可能就会如下所示：
address 000a6ca0 found in
    _HEAP @ a0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        000a6ca0 0b2b 0000 [00]   000a6cb8    05940 - (busy)
        Trace: 2156ac
        7704dab4 ntdll!RtlAllocateHeap+0x0000021d
        75c59b12 USP10!UspAllocCache+0x0000002b
        75c62381 USP10!AllocSizeCache+0x00000048
        75c61c74 USP10!FindOrCreateSizeCacheWithoutRealizationID+0x00000124
        75c61bc0 USP10!FindOrCreateSizeCacheUsingRealizationID+0x00000070
        75c59a97 USP10!UpdateCache+0x0000002b
        75c59a61 USP10!ScriptCheckCache+0x0000005c
        75c59d04 USP10!ScriptStringAnalyse+0x0000012a
        7711140f LPK!LpkStringAnalyse+0x00000114
        7711159e LPK!LpkCharsetDraw+0x00000302
        77111488 LPK!LpkDrawTextEx+0x00000044
        76a4beb3 USER32!DT_DrawStr+0x0000013a
        76a4be45 USER32!DT_DrawJustifiedLine+0x0000005f
        76a49d68 USER32!AddEllipsisAndDrawLine+0x00000186
        76a4bc31 USER32!DrawTextExWorker+0x000001b1
        76a4bedc USER32!DrawTextExW+0x0000001e
        746051d8 uxtheme!CTextDraw::GetTextExtent+0x000000be
        7460515a uxtheme!GetThemeTextExtent+0x00000065
        74611ed4 uxtheme!CThemeMenuBar::MeasureItem+0x00000124
        746119c1 uxtheme!CThemeMenu::OnMeasureItem+0x0000003f
        74611978 uxtheme!CThemeWnd::_PreDefWindowProc+0x00000117
        74601ea5 uxtheme!_ThemeDefWindowProc+0x00000090
        74601f61 uxtheme!ThemeDefWindowProcW+0x00000018
        76a4a09e USER32!DefWindowProcW+0x00000068
        931406 notepad!NPWndProc+0x00000084
        76a51a10 USER32!InternalCallWinProc+0x00000023
        76a51ae8 USER32!UserCallWinProcCheckWow+0x0000014b
        76a51c03 USER32!DispatchClientMessage+0x000000da
        76a3bc24 USER32!__fnINOUTLPUAHMEASUREMENUITEM+0x00000027
        77040e6e ntdll!KiUserCallbackDispatcher+0x0000002e
        76a51d87 USER32!RealDefWindowProcW+0x00000047
        74601f2f uxtheme!_ThemeDefWindowProc+0x000001b8

有了这些信息，就基本可以确定这些内存是通过什么样的途径分配出去的了。至于说为什么没有被释放，或者如何才能释放，只能自行查看自己的代码了。

2011年IT界工资摘要

2012-04-06T03:15:00.000-07:00

在这里有人给出了一个关于亚太地区五国（澳纽港新日）的IT界调查与分析，纯英文。我简单的摘要和再分析如下：（澳大利亚以悉尼为样本进行分析，毕竟主要工作机会在悉尼。）

亚太地区中，澳大利亚、新西兰以及香港的IT环境前景相对较好，其中香港最好，而新加坡的呈中性，日本变差；
日本、香港和澳大利亚的IT工资排列前三，而新加坡和新西兰的工资水平与前者有一定差距；
除了日本以外，其余四国的工资都是整体向上，日本加薪的少，减薪的多；
无论哪个地区，减薪的首要原因都是失业（以及换的工作比原来更低端）所致，但对于日本来说，经济状况导致减薪占比最高，而新西兰和新加坡在“其它”一项的选项显著增高。由于不知道“其它”代表什么，无法分析，个人猜测可能是转行或者自己决定休息一下等。日本选择其它的非常少；
对于加薪来说，几乎所有国家的主要原因都和“我表现很好”有关，尤其是新西兰。但这里值得注意的是，对于澳大利亚来说，升职导致加薪是首要原因。新西兰几乎不会同时涨工资和奖金，日本则涨奖金的比例显著高于其它国家（也就是说每年收入浮动机会更高）；
认为收入合理与不合理的，在所有国家几乎都差不太多，除了新加坡以外。新加坡有半数人认为自己的薪资不合理（这一点很意外，我原以为是日本，因为薪资下滑最多。也许是期望越大，失望越大）；
在认为收入满意和不满意的问题上，多数人都认为满意，除了日本以外。日本认为不满意的人数高于满意的，这点比较合理，说明日本收入下滑严重。有趣的是，新加坡认为不满意的比例和日本一样高，只不过因为非常不满意和不确定的部分较少，导致满意的略高于不满意的（我听说有不少澳大利亚的PR甚至入籍的人士，近年来选择去新加坡。看来是不知道听说了什么样的传说过去后，发现可能生活成本照样不低，而收入却没有提高甚至下降。）；
认为通过跳槽来提升自己在薪资上陶家花间的能力，在所有国家中都受到大多数人的认同。其中比例最高的是香港，最低的是新西兰；（说明新西兰人的生活真的好安逸，这是他们的价值观，后面还会看到）
对于认为薪资得到提高的最重要原因这个问题，所有国家的大多数人都认为首先是个人的能力表现和态度。其次则是达成一个正面的结果，除了香港之外（他们认为排第三重要）。而第三则是公司的成功，除了香港之外（他们认为第二重要）。这也解释了为什么香港人那么注重跳槽。换句话说，工作的结果如何不重要，如果想对于这个公司是否是一个大公司来说。日本也有类似的趋势，但没那么严重；
在什么理由可以让你接受较低工资的问题上，各国之间的差异比较大（列出的原因按照比例进行排序）：

澳大利亚人注重生活质量：在家办公、弹性工作时间、地点较近，以及更多的假期；（如果你享受生活，可以考虑这里，因为你的这种想法在当地很主流，不会受到质疑。）
新西兰人也很注重生活质量：弹性工作时间、更多假期、地点较近，以及在家办公；（可见新西兰的堵车问题没有澳大利亚那么严重，他们共喜欢有更多的自由时间，更多的享受生活。如果你享受生活，同时钱多钱少无所谓，新西兰真是天堂。）
香港人比日本人更努力赚钱：有更好的职业发展（一半人）、在家办公、更多假期以及企业文化；（即便那么注重职业发展，在家办公和更多假期看来还是人类的共同追求。同时不要看有半数人看重职业发展，就以为香港人不懂得生活，那就错了。他们还是很会享受生活的，不然满记这种甜品店怎么生存，更不要说出名了。只是他们的买房压力比北京上海更大，其压力对于香港IT界初级职员来说，估计基本可以等价于北京一个普通文职人员的压力。）
新加坡工作生活较为平衡，同时注重创新或者激情：弹性工作时间、在家办公、更好的职业发展、有机会为一个有魄力的领导工作；
日本人也比较平均，但更注重稳定：在家办公、弹性工作时间、企业文化以及更多假期；（很惊讶，因为职业发展在日本排在第六，在工作地点之后。似乎对他们来说，职业发展是顺其自然不可强求的事情。）

几乎所有国家的大多数人都会每年和老板商讨一次薪水，除了新加坡之外，他们近半数人从不讨论薪水。也就是说，如果你想要做打工皇帝，去新加坡可能不是一个好的选择。因为当你一讨论“哎呀老板，去年就没有给我加薪，今年是不是给我加点”，就会遭鄙视，因为你这绝对不是主流的想法。而新西兰则每年讨论加薪的比例最高，达到65%。换句话说，这才是当个打工族的天堂（也是享受生活的天堂）。另一个值得注意的是，除了每年讨论薪资占大头之外，从不讨论占二头，两年及以上讨论的几乎属于小众。所以，要么你属于鼓起勇气年年问工资的，要么就属于从不过问的；
对于所在公司会有所增长的信心问题上，大多数人都认为有点信心，所有国家无一例外。香港和日本在非常有信心这个选项上的比例，显著较其他国家为少。尤其是日本，完全没信心的比例接近三分之一。有点信心和非常有信心加起来最高的新西兰，占87%，其次是新加坡的85%。（这个结果很令人意外，我的解读是，新西兰人心态真好，新加坡真心认为自己要创新了。）
东家对于明年因为优秀雇员跳槽导致效能下降的问题，总体上还是有点担心的。大多数国家的分布呈现纺锤形，多数是有点担心，很担心和完全不担心的较少。但澳大利亚真是个特例，两端的比例较其他国家显著增加。可能是调查方法的问题，也可能是其国民有“非黑即白”的思维倾向，个人倾向前者。
对于明年打算雇人，雇什么级别的人这个问题上，各国表现差异很大（按比例从高至低）：

澳大利亚：职员、高级工、入门学徒，以及不雇人。特点：不雇人比例是这五国最高的；（12年看来不容易啊！）
新西兰：职员、高级工、入门学徒，以及管理人员。特点：对初级工的需求比例异常高，近一半；
香港：职员、高级工、管理人员，以及不雇人。特点：前三者比例基本均匀，综合为五国最高（102%，因为可以多选）；
新加坡：职员、高级宫、执行官，以及管理人员。特点：执行官这一级别的比例显著高于其他国家，想做CXO的可以去那边试试；
日本：管理人员、高级工、职员，以及执行官。特点：唯一一个对管理人员需求比例高于其它的，也是唯一一个职员需求比例不是最高的（第三）。（我个人解读为，此地喜欢按部就班，注重管理。）

对于每周工作时间的问题上，各国还是有一定的差异的，但可以简单分为这么两组：

大洋洲国家：新西兰和澳大利亚都显著的集中在45小时以下。尤其是新西兰，非常规范，显著集中在每天工作8小时这个法定认知上，其超时工作比例最低。澳大利亚也不赖，虽说超时比例稍高，但是工作时间在38小时以内的比例也是各国当中最高的；
东南亚国家：香港，新加坡以及日本，在这方面的表现不太理想。39-45小时，以及46-55小时这两组的比例基本相同，甚至有15%-19%的比例是每周工作超过55小时的；

对于加班压力的表述上，所有国家的大部分人都认为有时候会有，其中新西兰比例最高（我真晕了，应该解读为Kiwi对此问题比较敏感）。而日本人的比例分布较为平均，总加班以及一直加班的比例也是最高的，香港紧随其后。同时日本的从不加班的比例也是最高的，与澳大利亚并列。而香港和新加坡生成从不加班的比例最低。偶尔加班、很少加班以及从不加班的比例加起来，则数新西兰最高，澳大利亚紧随其后。（结论，如果你不喜欢加班，希望有更多的私人时间享受生活，请考虑新西兰。当然，新西兰钱少，如果你在意这个，可以退而求其次选择澳大利亚。）
对于“你认为什么样的培训对你的职业生涯最有帮助”这个问题，所有国家都认为最主要是“领导力和管理技能”，但在排第二的问题上面就有一些分歧了：

澳大利亚：项目管理技能；（新西兰紧随）
新西兰：技术和软件训练；（澳大利亚紧随。这两个国家似乎都不认为沟通是个问题，很可能还是亚洲国家人际关系过于复杂造成的差异。）
香港：沟通技巧；（日本紧随，然后新加坡。为什么？为啥亚周国家都认为沟通最重要？还是说这些国家天生不会沟通，或者太注重人际关系？）
新加坡：项目管理（技术和软件培训、沟通技巧紧随其后）；
日本：比较平均的分布在技术和软件培训、项目管理，以及沟通技巧上。其中沟通技巧比例是除香港外第二低的（香港重视技术吗？心存疑虑）；

关于调查对象的性别构成，都是男性占绝大多数；
关于调查对象的年龄构成，青春饭啊：主要集中在25-45岁这一个区段，往后减少较明显。其中日本46-55岁之间比例显著偏高，25-35岁之间的比例显著偏低，个人怀疑可能是抽样方法问题造成的；
关于工作经验的问题，抽样结构显示主要集中在6-19年的区段，日本的部分仍然看到20年以上比例显著增加。总之，看到这样的比例很欣慰，说明国外IT的黄金时间显然比国内长；
关于是否拥有相关专业学历，大部分国家对此的重视程度只能说Soso，除了新加坡，后者3/4的人拥有相关学历；
关于是否长期全职问题，所有国家大部分都是的，但澳大利亚在临时/合同工的比例上是显著高于其他国家的，占了1/3。兼职工作也是澳大利亚比例最高；
关于行业细分：

澳大利亚、新西兰、新加坡以及日本主要是IT软件技术业，其次是金融业；
香港金融业占了近2/3；

另外，由于该分析主要针对澳大利亚的分析，还有一些各大城市的具体职业细分薪资情况。这里做一些简单的摘要：

悉尼收入最高，墨尔本次之，剩余的差别不太大；
实际上超过5年的.NET开发人员，各地差异都已经不太大，可以认为是各地生活成本的差异。但是5年内的.NET开发人员，差异非常大；
.NET开发和Java开发的收入几乎无差异；
做开发做到15年可能基本到头，后面的收入增长空间很有限。可以考虑转岗，比如当个Manager。不过对于华人来说，语言文化关这个坎很难。当然，拿到10万每年以上，已经在当地很有高度了；
如果这个调查是真实的，如果你去悉尼，就算你经验很少，能力soso别太懒，按照现在的汇率，税前年收入30W人民币，那是撒撒碎啦。

话说澳大利亚税还是比较重的，不过和中国的比起来，个人猜测可能并不会高太多。尤其是税高了，痛苦指数却可能会下降。比如你只要一想，我再也不会喝到三聚氰胺奶，或者皮革奶，或者地沟油，顿时你就幸福了。同时你也会知道你的税都用来干什么，尤其大部分不是用在查不出来有多少的三公消费上面，顿时你就又感到幸福了。还有，当你自己开个小公司的时候，只要交3位数的钱就开了，也不会有什么人来强制你购买什么税控机，请吃饭什么的，顿时你就又感到幸福了。

当然了，那个地方都有不幸福的东西，看你怎么想了。尤其要想想，哪些是你可以努力避免的（比如住一个好点的区，少遭抢），哪些是你压根无法避免的（比如呼吸点PM2.5很高的空气）。

昨天大吃后随感

2012-04-02T03:57:00.000-07:00

昨天老婆突然想吃香喝辣，于是忽悠了一群前狼烟同学小聚。愚人节忽悠人有时有意思，都不知道该不该相信好。

席间大家谈到一个近期的出名事件：大陆微博被禁止评论了。这个事情我倒是知道的，之前就在推上看到类似的信息，再加上有人给我转了个东西，结果我只想评论而不得。因为不太关心这件事情，所以自然也不知道后续还抓了很多“造谣”的人，据说有1000多。这个数字我倒是觉得稍微有点吃惊——抓这么多人能增加GDP呢，还是能够填平社保的账面窟窿呢？

其实除了稍稍有点吃惊之外，我已不太在意。中国政府就像一个满脸长满了G点的妓女，别人随便扫一眼她脸上任何地方，她就高潮了。高潮就算了，还强迫所有路人甲乙丙丁全部脱光衣服给她检视，好强行给你提供为你好的服务。如果再变本加厉一点，估计真要开始满大街的强暴人了。

席间又聊到腾讯，原来挺憎恨该公司的同学居然说现在没那么憎恨了。记得以前他说过，他师兄原来给腾讯做过珊瑚版，刚开始腾讯还给予支持的，但过了两年就转手告人家侵犯版权。是不是陷害我就说不清楚了，但从这个公司的各种山寨来看（比如近期山寨人家的Draw something），真是没有什么底线。他说他之所以不那么憎恨腾讯，是因为从这个公司能够看出政府是什么样的，人民是什么样的。说的也是，国民本身的素质就不算高，政府的行为更是没有任何底线。有这样的人民和政府作后盾，又如何能够做事情有点底线呢？要是你有底线，别人没有底线，而政府有不惩罚没底线的甚至保护他，你如何玩得过人家？

聊到这个公司，就说到消费的问题。因为这朋友的朋友做微游戏，同样的游戏在新浪销售收入只有腾讯的1/10。原因在于用户群的差异：新浪都是上班的白领，偏向80以后；而腾讯的多是尚未工作的小毛孩，以及刚工作的90后。而白领通常的不愿意在这种无法增加其自身价值的事情上多花一分钱，倒是愿意在穷三代的单反上面投入一些。而90后则据称毕业后两极分化非常大，不是高富帅就是爱穷丑。前者不是有很多零花钱，就是挣来的钱也不需要买房买车之类的；而后者则挣得很少，少得可能一辈子都挣不来一套房，于是挣来的钱对他们来说也是没用的。于是这两者都不约而同的在腾讯的各种钻、服饰、游戏上面浪费钱，或者是到酒吧等地方消费。这种现象甚至很明显的在iphone上购买各种应用上也是如此。

也许有人解读为90后的消费观和我们有极大地差异，而我却宁愿认为中国正在形成一个垮掉的一代，并且没有任何自然人、法人乃至政府国家有意愿或者能力去改变。一个巨大的车轮沿着历史的轨迹飞速前进，碰到了现代文明这堵墙的后果，就是Off road——不上道。

分享一个很久以前的前公司的例子

2012-03-30T22:47:00.001-07:00

俺过去曾经啥都干过，包括开发、排查Bug、数据库部署维护、服务器采购、机房迁移，乃至公司的电话机布线和程控机的编程……好吧，事情是杂了些，但不代表不专业。

不过销售为主导的公司，一定会发生一件事情，就是在技术上销售比技术还要牛叉。在以前的公司就曾经有这么一件事情发生在我身上：

某天开始，服务器每天都会时不时的速度很慢，然后就突然无法访问。该问题长时间排查都找不到原因，现象倒是挺明确的：不存在数据库连接泄露，某种偶然情况下Web进程内存占用会突然缓慢持续增加，当到达接近1GB时会突然崩溃，日志显示内存不足。

这个现象很不好理解，因为：

并非必然发生，而是阵发性的；
网络带宽只占用了30%-50%左右；
内存并没有占用满32位操作系统的用户内存空间上限，甚至连一半都没有用到，怎么就内存不足呢？
代码拉网筛查，以及跑profile也没有发现任何内存泄漏；
按道理来说，.NET托管内存是不可能存在泄漏的，而Web应用很少会有大量对象长期生存，也不可能占用内存至内存不足。

无论原因如何，也不可能是网络带宽的原因。可是搞笑的是，销售的一个头头居然大发雷霆，发邮件短信说技术反应迟钝不作为，这么久都不增加带宽。当时真是非常无语，尽管之前已经通报过情况，也说明不可能是带宽的问题。但既然已经惊动老总，只好按照其要求将带宽翻倍。可想而知，该现象依然如故，于是就没话可说了。

此问题非常棘手的主要原因是现象1，导致你只能一直远程并盯着内存量，当发现开始增长并持续一段时间之后，就要果断做Dump。可是，有可能你正好手头有事或者谁跟你说一件事，这个现象就错过了；又或者做Dump太晚了，导致CPU已经开始大量占用无法启动Dump程序；又或者Dump了半天快结束的时候进程被IIS自动Kill掉了；又或者Dump的太早什么都没有Dump出来。

经过很长时间的联系，终于熟练的抓到了一个Dump，结果发现实际内存占用量非常少，大约只有300M左右，但是内存提交量却达到了2G。最后实在没辙了翻查GCHeap，结果找到少量极其巨大的string对象，比如20MB。这些string对象指向了一个位置：日志。原来在系统中有一个数据库表的字段，是用来存放最后一次某些特地操作的。按照设计，这个字段应该只保留最后一次，但实际情况是该字段不知道为何被改成一直累加。于是乎，一些频繁访问的用户就会累积出这种巨大日志记录。只有当这些用户频繁访问的时候，才会造成系统崩溃。这很好的解释了前面所说的5个现象，尤其是阵发性。

也许有人会问了，那GC不应该回收么？对，GC会回收，但是GC回收会有一个副作用，就是CPU占用会变高，导致系统变得很慢。此外，还有一个无法在32位操作系统中很不好解决的问题：由于.NET设计上将大于85kb的对象放在一个特殊的Large Object Heap（LOH），而这个Heap和普通的GCHeap有一个明显的不同，就是GC发生时并不会进行对象拷贝（也就是碎片整理）。最后，连续的内存地址将会全部碎片化，此时如果需要分配大对象的时候，将会再也找不到任何连续地址用于存放此对象。虽然所有空余空间加起来远远超过几百兆，你也可能无法分配一个30兆的内存空间出来。于是才有了明明内存占用很少，却报告内存不足。

你看，这个问题挺技术的吧。可偏偏有那种什么也不懂的人，跑出来很技术的要求增加网络带宽。从这个事情上，我明白到合作的事情，你必须相信你的伙伴在他的领域内是专业的，不要傻了吧唧的在那里指手画脚。如果你不信任，那你就应该立即换人，并同时承担看错人的成本（包括新人和旧人）。否则，指手画脚除了显示出你的不专业，搞坏团队气氛之外，不能带来什么好处。除非，你认为以飞机失事的概率成功解决一件事情能算是成功。

哦，对了，这种事情从来不会停止发生。比如说上面说的那个销售老大技术真是完全不懂，否则根据我在通告中说明的“内存不足”异常，可以在带宽倍增无效之后，继续要求给服务器增加1TB的内存，然后再增加100个CPU和600个网卡。最后实在不行了，还可以赖.NET不如Java先进，要求更换至Java平台然后使用Oracle数据库。至于操作系统嘛，可以换成EXASOL EXACluster OS……

Linux撞鬼集4之IFS

2012-03-30T21:42:00.002-07:00

前阵子自建CDN，因为有攻击导致某地点某IP不可用。在屏蔽攻击后重新需要给用户重新分配IP地址，但是分配之后一直都没有成功。通过查看配置文件，我们确实配置成新的IP地址了，并且确实已经“成功”的重新启动bind服务。但是用户持续报告不可访问，我们直接找ip地址发现实际上仍然是旧的。

一开始我们怀疑可能是不是TTL错误，或者什么别的原因导致用户访问的DNS服务器没有刷新新的解析记录。经过一阵紧张的nslookup和dig之后，还是没有能成功找出问题所在。最后修改named.conf当中的日志级别为debug，重新启动之后发现实际上有一个区域的解析记录并没有成功加载。日志大概意思如下：

unknown type "xxx.xxx.xxx" for record NS （大概这意思吧）

打开配置仔细一看，原来该区域下面应该有一个NS解析记录，原本应该是：

NS xxx.xxx.xxx

结果变成了：

NS xxx.xxx.xxx

这一条解析的意思是，当前要解析的域下面的域名服务器是xxx.xxx.xxx。但是由于前面的空格去掉了，结果按照空格划分，第一个表示二级域名的字段从空变成了NS，而记录类型则从NS变成了"xxx.xxx.xxx"，而第三个表示解析结果的字段则从"xxx.xxx.xxx"变成了空。于是这一个域名解析记录加载失败，这也导致了后面更改了的解析记录实际上从未被正确加载。之所以域名服务器仍然返回旧的IP，是因为过期时间比较长，在得不到我们的正确解析时，其它的DNS服务器将沿用原来已经有的域名解析结果。

那么，这个空格为什么消失了呢？如果是某个人手动修改的，其手动意图又是啥？经过调查之后发现，原来有人写了一个修改解析地址的脚本，正是这个脚本造成的问题。而之前就已经发现有此问题，解决的办法是通过运行脚本之后手动添加空格来解决，而这一次却忘了。

具体造成问题的脚本命令是read，这个命令十分神奇，会自动根据IFS来分割字段，然后将字段重新组合成一个字符串。用C#来描述，就是：

return string.Join(IFS[0], Console.ReadLine().Split(IFS, StringSplitOptions.RemoveEmptyEntries));

解决的办法很简单，就是将脚本改写成：

while IFS=""; read LINE

# something

done < afile

关于IFS在while上面赋值，我想了一下，原因应该是这样的：

如果在独立一行修改，则导致从此之后的运行环境发生改变，会影响并改变后续所有命令的默认行为。而如果在while上面赋值，则因为是folk一个子进程，并且在子进程中运行修改的缘故，并不会导致外部（当前脚本）环境的变化，也不会改变后续命令的默认行为。

这种环境变量影响程序行为的问题，在Windows算比较难以注意到的。一般也就是PATH之类的变量会导致能否找到可执行程序，但很少会影响程序本身正常行为的。对于read来说，默认按照IFS分割并重组输入，确实让初学者难以注意到。

一句话

2012-03-30T19:53:00.002-07:00

人生就是一砣砣屎等着让你吃，你要么找别人替你，要么就在吃下一口之前赶紧大喘气。

都掉钱眼里了，就别跟我谈什么理想梦想的。

不要将自己的无能怪罪到别人头上，尤其别人是在帮你的时候。

在说别人没有XX的时候，最好先看看自己有没有。（XX=卵、智商、情商、能力……）

话不要随便乱说，因为朋友的敌人的敌人，可能同时是你的敌人和你朋友的朋友。

沟通是倾听，是从别人的视角看问题。

凡是使用外部归因法的，都是懦夫、侏儒、智障。

有问题的永远是我自己，别人永远都是没有问题的，这样才能做好事情，会做人。

技术宅分析养老金

2012-03-29T21:42:00.000-07:00

据说是郎咸平的文，至于是不是，我没有考究，我关心的是里面数字的计算：
继续工作20年，退休活命20年，当前平均工资4000，退休后保持生活质量需要243万，实际养老金只有37万。

首先说我的结论，那就是赶紧移民吧。且不管里面别的地方是否正确，但是有那么几点是一定正确的：

公务员退休保障是普通人的好几倍，已经形成公务员阶级和屁民阶级。未来某个点上面肯定要达到势不两立的地步；
最低收入者需要交的保险比例比寻常人高也是不争的事实（北京貌似按照1600的最低基数交，就算你只拿1200的工资）；
各类社保亏空是不争的事实，未来一定会通过增发货币进行账面名义值弥补，但一定会引起持续的高通胀，乃至超高通胀（乃至引发爆点）；
各种不明不白是一定的：比如你移民，公司交的那部分就没了；跨地区也是被截留一部分；
公积金账户年利率似乎只有0.36%这种级别，至少不是一年定期的利率。可是大家都听说过社保基金入市吧？那么用我们的钱赚出来的利润怎么就被侵吞了呢？如果亏了呢，算谁的过错，最后又是谁来买单？（答案：没人负责，我们通过货币增发补充账面亏空-〉通货膨胀-〉货币实际价值下降-〉生活质量下降的路径来买单。）

实际上我一直认为，如果这些钱如果发到每一个人的手上，全部存1年定期，也比放在政府账户要有更高的保障。如果政府真心为我们好，那就不要交什么社保费，直接动用税收给我们发钱就好了。当然，如果是每个人一个独立账户，清清楚楚，那也可以考虑。

之所以现在大面上大家都没有反应，那是因为传统文化中的“国〉家〉个人”的部分作怪，个人权利意识从未真正觉醒。尤其对于底层的群众来说，经常不自觉认同可以为了大家的利益牺牲个人利益这种扭曲的观念，只有当被强拆的时候才会发现周围的人是那么的冷漠。如果放在西方，这种社保制度早就上街抗议了，因为个人利益受到了极大的损害，而且不明不白。

扯远了，咱还是扯数字。上面那几个数字在其假设上面是正确的，计算方式如下：
令G = 4000, k = 1.03, 则有
G20 = G*(k^20) = 7224.45 (20年后的月工资）

因为每年增加3%这个数字比较小，可以认为近似线性增加，于是20年工资总和为（略小于）：
T20 = (G+G20) / 2 * 20(年) * 12 (月) = 1,346,933.39

令p = 8%+20% = 28%，则有实际保险名义值 J20 = T20 * 28% = 377,131.35，约38万。

20年后至40年后这段时间，如果每个月都需要现今的4000元，则此期间名义货币值总需求量是T20_40 = (G40+G20) / 2 * 20 * 12，其中
G40 = G * (k^40) = 13048.15，因此
T20_40 = 2,432,711.53，约243万。

从计算结果看基本吻合，但是实际上这里面有几个比较大的漏洞：

大部分人将工作38年，而不是20年；
现在开始工作的人，其人均寿命是68岁；（注意，2012年的人均寿命是指预期2012年出生的这群人的平均寿命，而不是这一年死亡人口的平均寿命。）

也就是说，今年刚工作的本科毕业小鬼，将会干38年的活，然后活8年。于是：
G38 = G*(k^38) = 12,299.13
G46 = G*(k^46) = 15,580.17
T38 = (G+G38) / 2 * 38 * 12 = 4,451,375.98
J38 = T38 * 28% = 1,246,385.27，约124万。
T38_46 = (G38+G46) / 2 * 8 * 12 = 1,338,206.82，约134万。
也就是说，账面缺口大约10万。于是差距已经小了很多，此外考虑实际账户资金是存在一定的利率的，比如存1年定期，这10万的差距基本上是可以找回来的。

呃，如果这样的话，为什么还要考虑移民呢？因为：
如果你不幸寿命没有达到60岁，那么……
目前有一大批的退休人口，实际上在过去是1分钱的保费都没有交。或者更准确的讲，是那些计划经济时代的老一辈，政府就没有专门的账户和预算来应对养老的事情，基本上算是比糊涂账。这部分的内容才是目前账面亏空的根本原因；
还是那句话，不清不楚，随便侵吞个人权益。于是你贡献的时间越长，损失可能就越惨重。比如说，未来如果出一个规定，说必须回原籍才能拿养老保险……

当然，如果你维权，就会遇到一个强大的政府，完全不按照法律行事。比如我就听过这样的对话：
屁民：按规定应该可以办的。
领导：（一拍桌子）规定！我打开这个抽屉里面的文件有一个规定，打开另一个抽屉里面的文件又有另外一个规定，我想要什么样的规定还不简单！

我国立法形式基本上就是形式，完全无视宪法，宪法也只能代表装精神一下。比如没有宪法法庭，也没有违宪救济途径。所以你既可以说有法有天，也可以说无法无天。

几个简单常用的Linux命令——日志分析篇

2012-03-29T20:19:00.000-07:00

同事说能否分享一下linux日志分析的心得，尽管我也只是初学小菜，不过既然问到了，那就献丑了。

linux里面有那么几个常用的命令，在大部分日志分析场景里面都会用到：

cut 按照特定分割符分成若干列，取出其中的某一列。
-d" " 表示用空格作为分割符默认好像是逗号；
-f8 表示取出第8列。

sort 按照特定的分隔符分成若干列，按照某一列进行排序。
-d" " 表示用空格（默认应该就是空格），-f1,2表示用第1、2列输出；
-g 表示按照数字进行排序；
-r 表示逆序；（默认从小到大）；
-k8 表示根据第8个字段进行排序；（默认只根据第1列排序，可以通过设置IFS来指定分隔符）
-k1,3 表示根据第1至3个字段之间的内容进行排序；
-u 表示相同的元素只输出一次。

uniq 如果下一行重复则消除。
-c 表示统计出现次数（重复一次计数为2）。

head 输出最开始的几行。
-n8 表示输出头8行。（无参数时默认10行）

tail 输出最末尾的几行。
-n8 表示输出尾8行。（无参数时默认10行）

wc 输出指定文字出现的次数。
-l 表示输出出现该文字的行数而不是次数。

grep 输出包含指定文字的若干行。
-i 表示大小写不敏感；
-e 表示使用正则表达式；(等同于egrep命令）
-v 表示输出不等于制定文字的若干行；
-m8 表示指定文件中的输出前8个；
-a 表示如果是二进制文件，则仅对比里面是文字的部分；（比如要找squid缓存文件当中记录的，与该文件对应的uri时就特别有用）；
-r 表示递归搜索所有文件夹中的指定文件；
-H 在每一行输出中均包括文件名；（搜索单个文件时默认不输出）
-h 在每一行输出中均不包含文件名；（搜索多个文件时默认输出）
-l 仅输出有命中的文件名；
-L 仅输出没有命中的文件名；
-B8 输出命中该行之前的8行；
-A8 输出命中该行之后的8行；
-c 仅输出命中次数。

上面这个命令组合通常就可以进行大部分的日志分析工作，下面举例说明。

我们假设日志名称为squid.log，格式如下所示（有点像Squid，但实际上不是真实的日志格式，只是为了便于说明）：
- - [2012/1/1 04:23:44] 223.33.54.123 "GET /pages/head.htm HTTP/1.1" {www.fix.com|http://www.google.com/search} 200 - - TCP_HIT:NONE "Mozilla/4.0"

例1 查看最后若干个访问"/pages/head.htm"的IP都来自哪里：
grep -i "/pages/head.htm" squid.log | tail -n20 | cut -d" " -f5
注意：

日期和时间当中有一个空格，因此是两个字段，而不会因为方括号而认为是一个字段。同样的，单引号双引号也不会影响以空格为分割符的分割；
如果文件非常大导致明显非常慢，可以尝试用tail作为开头进一步限制，如：

tail -n1000 squid.log | grep -i "/pages/head.htm" | tail -n20 | cut -d" " -f5

例2 统计最后若干个访问"/pages/head.htm"的IP的次数：
grep -i "/pages/head.htm" squid.log | tail -n1000 | cut -d" " -f5 | sort | uniq -c | sort -g
备注：这里的技巧是，先要sort，然后再通过uniq -c来统计次数，然后再通过sort来进行排序。这是因为对于uniq命令来说，之比较上一行和下一行，而不会考虑交错的情况，例如对于文件tmp如下：
A
A
B
B
A
A
C

用uniq -c tmp来检查，输出如下：
2 A
2 B
2 A
1 C

而实际上我们希望的输出类似如下：
1 B
2 C
4 A

于是只能够通过sort先将相同的内容放到一起，然后再用uniq来统计。sort命令当中的-u参数并不会统计处数量，于是必须使用uniq命令。同时uniq输出的顺序是原始文本出现的顺序，而不是根据数量进行排序的，因此最后还需要用sort进行排序。

例3 统计最后若干个访问"/pages/head.htm"的IP中，出现次数最多的前三名以及其次数：
grep -i "/pages/head.htm" squid.log | tail -n1000 | cut -d" " -f5 | sort | uniq -c | sort -gr | head -n3

例4 统计后端返回状态为503的访问次数：
cut -d" " -f10 "/pages/head.htm" squid.log | grep 503 | wc -l

例5 统计后端返回状态为200，且访问"/pages/head.htm"的HIT和MISS的情况（日志中TCP_HIT:NONE的那一列）：
这一个需求比较复杂，我们需要动用上面没有介绍到的另一个命令：awk

awk 对每一行按照指定分隔符进行分割，并根据指定的条件输出指定的内容。
-F" " 表示输出以空格作为分割符。

完整命令格式如下：

awk [条件] ['指令'] [待分析文件]
之所以指令是可选的，是因为参数中还有一个可以指定指令文件的参数；而待分析文件可选，是因为可以通过管道提供待分析文件。

其中的指令部分比较复杂，完整的这里就不介绍了，请自行谷歌之。这里介绍非常简单的几个常用部分。
$1 表示第一个字段
$1>2 表示第一个字段是数字且大于数字2
$1>"2" 表示第一个字段大于字符2，也就是说"12"<"2"
$1==$2 表示第一个字段等于第二个字段
&& 表示与
|| 表示或
a { b } 表示如果前面的a部分匹配，则执行b部分
print 表示输出整行
print $1 表示输出第一个字段
; 表示两个指令之间的分割

于是
$1==200 { print; }
就是说第一列等于200就输出整行。

对于本示例，将需要使用如下命令：
awk -F" " '$10==200 { print; }' squid.log | grep -i "/pages/head.htm" | cut -d" " -f13 | sort | uniq -c | sort -g

例5 统计UserAgent的情况，但前面的访问路径处可能包含不定数量的空格，比如某些访问没有发出HTTP/1.1，于是只有"GET /pages/head.htm"。

这个问题很容易想到：啊，如果能够忽略双引号中的空格多好啊！嗯，这种思路应该也是可以的，但是比起下面这种思路来说，有的时候真的太复杂了。
cut -d\" -f4 squid.log | sort | uniq -c | sort -g

“……靠，还能用双引号做分割符，咋就没想到呢？”好吧，再提示一下：每一个命令可以考虑使用不同的分割符，而不需要每一次都用同一个分割符。

Linux撞鬼集3之$()内嵌加管道（尚未解决）

2012-03-28T03:37:00.003-07:00

由于自己比较菜，写linux脚本的时候总遇到一些很撞鬼的事情，比如说：
$(echo "echo hello")

这个的执行结果是：
hello

但是执行下面这个命令：
$(echo "echo hello | more")

结果你以为仍然一样，结果却是：
hello | more

嗯？为啥是这样的呢？抱歉，我不知道为什么。从我目前的认知来说，我以为$(xxx)的意思是执行xxx命令，并且再次执行该命令的输出。用第一个例子来描述，那就是：
echo "echo hello"

将会输出：
echo hello

而执行 echo hello 的结果，将会是：
hello

也就正好可以解释第一个例子的执行结果。可是到了第二个例子，我们推测
echo "echo hello | more"

的执行结果是：
echo hello | more

而上述语句的执行结果应该是
hello

这是因为该输出只有一行，more不会起任何影响。但是实际上第二个例子的结果却等同于：
echo "hello | more"

嗯，这就奇怪了，bash怎么会如此识别呢？如果说是自动根据IFS来添加双引号/单引号，那也应该是等价于下面这样的命令才对。
echo "hello" | "more"

好吧，我假定$()操作符将会根据输出结果按照IFS分割成两列，第一列作为命令，剩下的都作为参数，这样倒是能解释结果。可是，我要如何写才能得到等价于hello | more的执行结果呢，或者说达到这一个目的呢？

……呃，这个，非常抱歉，google这个玩意儿对于学习linux脚本编程天然鄙视。比如搜索“$()”，结果是木有啊木有，更不要说搜索“$() |”这样的玩意儿了……（泪奔ing）

P.S.:
$(echo "echo hello" | more)这个是可以的，但是这两者其实并不等价。比如说有一个有3行文字的文件a，执行cat a | head -n 1，现实的是一行。但是执行$(echo "cat a" | head -n1)，却把所有文字都显示出来了。为啥？不知道，GOOGLE不告诉我……