周六，对于上班族来说是多么好的日子，能在家里享受自由的无拘无束的生活而且不用担心第二天的工作，应该说是一周中最没有压力的一天。六点半起床，慢慢喝下一杯225ml左右的凉白开（保健医生说20-25摄氏度的凉白开比较适宜作为起床后的第一杯水），套上运动短裤和上衣，打开MP3播放器，塞上耳机，出门在园区内慢跑。昨晚下了一场雨，所以园区早上的空气很好。耳畔酷玩乐队的“Viva La Vida”让我跑起来很轻松，30分钟的有氧慢跑能让我的大脑和心脏获得足够的氧气，心情也变得更好。最后绕着园区走上一圈结束锻炼。

回房间后，舒舒服服的冲了个热水澡。简单的吃过早饭后就回到了本本前，本来计划解决一下本周五发现的一个GB2312转Unicode码的问题。但此时远在南方某省的技术支持人员打来电话，说我们的产品又出现问题了。这个问题早有端倪，曾先后引起客户总部的投诉、当地一些客户的投诉以及计费部门的投诉。前些时间在查这个问题时一直很迷惑，同样的机器和配置在其他省就没有问题，为什么唯独在该省问题严重。而且从业务量上来说，该省虽然业务量上比其他省高出一些，但按照目前我们产品的处理能力来看，还是完全可以满足要求的。在没有找到根本问题前，本周一直在做一些程序部署上的优化以及参数调整，希望能通过这些手段来缓解问题的严重程度。

本周五刚刚完成了一些I/O上优化，周六却又出现了问题，而且这次是客户集团总部的投诉。前方的技术人员已经是火急火燎，但是查问题也不是一蹴而就的事情，还是需要细心、耐心和稳定的心理的，不能头脑发热。

所有问题的查找都只能从已出现的问题现象着手。今天问题的现象是：我们的产品作为Server端时无法及时收消息并回应答，导致客户端异步发送窗口中的消息超时并重发该消息，而这条重发的消息因与前一条消息有着同样的消息ID而被我们的产品拒绝。还有一个现象就是：我们的产品作为Client端向一内部的鉴权子系统发鉴权请求，因未能及时收到应答而导致我们自己的异步发送窗口中的消息过期而直接进行了下一个环节的处理，这样一来这些消息在用户体验和计费上都会出现问题而导致投诉。

试着调整一下两端通信的参数以及一些队列的缓存参数，生效后也仅仅缓解了一段时间就再次出现了类似的问题，严重时双方居然因为socket阻塞而导致链接断开。这时技术支持同事提到主机I/O特别高。I/O高倒是很好的解释了socket未能及时被读取的问题，但是本周明明做了些I/O优化，为什么I/O还是这么高，而且此时该省的业务量相当的小，基本排除因业务量过大而导致I/O高的可能了。但是又是什么导致阵列I/O高呢？甚是疑惑！

究竟是什么问题导致大量磁盘操作呢？无意间在产品运行环境里发现一个Core文件，如果只发现一个core文件倒不足意外，但是发现这个core文件有上G的容量，而且一直在不断被刷新。难道就是这个core的不断刷新导致了I/O特高？遂尝试写了个脚本每个2秒尝试rm一次该core文件。果然经过这一处理，I/O降了下来，上面的问题也不再出现了。停掉脚本，I/O又攀升了上来，上面的问题就又出现了。“罪魁祸首”终于找到了！

虽然使用脚本可以临时解决问题，但是这样解决问题显然是不负责任的。到底是什么导致Core的出现呢? 停掉脚本，让程序产生core，对core文件进行分析。通过pstack和gdb打开core文件，core文件输出的信息很少，很多信息都成了“???”，似乎栈被破坏了。不过可以获得出core文件的进程号以及dump core的接口函数名字。通过进程号和程序日志共同定位，发现出core的进程都是在处理同一个客户端提交的消息。让技术支持同事封掉该客户端的IP，果然再没有Core产生，看来是我们的程序在处理这家客户端提交的消息时出了问题。

到目前为止已经大有收获了。继续！利用snoop工具获得了该客户端提交的消息包的信息。经过对比分析发现，该客户端提交的包信息与协议中定义的格式不符合。但是我们的程序居然没有发现这样的非法格式包，进一步结合代码、包信息和core信息进行分析，终于定位到了问题所在。原来是我们的程序的一个函数实现逻辑有误，而这种错误在处理正常格式包时是不会发生的，但是处理这种非法格式包时，会导致严重的栈上缓冲区溢出，直至进程运行混乱，dump core并退出。

这时想起周五同事发来的一封邮件，说的是我们的另一个产品在另外一个省也遇到了类似情况，core的输出与今天处理的情况几乎相同。想必是一个问题。因为出问题的函数是很久以前的代码了，而且是复用库中的一处代码。估计所有复用了该库的产品都要做一次升级了。

解决完问题已是日落时分，虽然身体感觉一丝疲乏，但是心情还是不错的，一天的努力终于有了成果，程序员的成就感就是由此而来的。

一年一度的公司福利体检结果刚刚出炉不久，与去年相比，我今年身体状况有些“不妙”：体重超重、血压有些偏高，另外谷丙转氨酶也略高于正常值。今天中午公司委托体检机构安排一名老医生给我们说说体检结果。老医生针对从全体员工体检结果中统计出的TOP3问题状况给出了具体的讲解和预防/缓解措施。这三个常见身体状况是：超重/肥胖、高血脂/血糖和脂肪肝，相信不仅我们公司的员工有这些问题，大多数做IT的人都或多或少有类似的情况。医生的讲解让在座的同事们不时发出“惊叹之声”。如何摆脱这些身体问题，老医生给了我们一个大家可能都熟知的“六字真经”：管住嘴，迈开腿。其实真经大家都知道，但是能否坚持做下去，这个却不是每个人都能肯定的。关于谷丙转氨酶略高的问题，医生的答复是：“可能与体检前一阶段的睡眠不好、压力过大等等有一定关系，问题不大。不放心可一段时间后去复查一下”。听了这番解释，我悬着的心才放了下来。

随着产品的集群化，产品部署的服务器越来越多，维护的时候一台主机一台主机的跳转起来越来越麻烦，效率很低，浪费了很多时间。近期将之做了改进，利用“基于SSH密钥对的自动登录”方式来做改善。大致的方法就是：在客户端主机利用ssh-keygen生成密钥对，如果采用rsa方式，则默认生成一个私钥文件id_rsa和一个公钥文件id_rsa.pub，将id_rsa.pub的内容copy到服务端主机的.ssh/authorized_keys中即可。authorized_keys中可保存多个客户端主机的公钥内容，每个公钥单独一行即可。这样在客户端主机使用ssh username@host_ip即可自动登录到服务端主机。如果你将'ssh username@host_ip'定义为一个alias，那就更加方便了，那时你仅需要敲入几个字符，回车后就会登录到另外一台主机上了。

Safari，苹果公司的桌面浏览器。两年前曾经安装过Safari，版本是多少我忘记了，但是那时的Safari连中文都不支持，试用了一段时间就卸载了。昨天得知Safari4已经于6月份Release，而且这次有了中文版。在网上搜了一下对Safari4的评价，还不错。对苹果公司的产品一向还是比较向往的，遂下载了一份，安装程序20多M，安装很快。启动后界面简洁、酷！试打开一个网页，Wow，快就一个字，IE就不用比了，比Firefox还要快，直观上就能感觉出来。在网上搜了一下网友对Safari4的评价以及Safari4自身的产品说明，“快”可是其最大卖点，第一印象不错。但是光是快还不够，我还希望它能稳定的运行而且能兼容访问大部分我平时常上的网站，特别是公司内部站点以及无障碍访问一些我们自己产品的WEB页面。经过测试在兼容性上Safari4没让我失望，Safari4对公司内部站点以及我们产品的WEB页面的兼容性很好，这点要好过Firefox，甚至是IE。用了一整天，页面没有布局混乱以及无法打开链接的情况。但是稳定性还是有一些小瑕疵的：白天在公司通过代理上网，时间长了，发现Safari4动不动CPU就上来了，磁盘I/O似乎也高，弄得我无奈将之关掉。但是回到家中，打开Safari4，持续几个小时也没有任何问题，直至目前还未找到原因。

Safari4的绝大部分快捷键都与Firefox相同，所以从Firefox转移到Safari4很平滑，唯一让我遗憾的是：我尚未找到如何设定默认打开一个新标签页而不是打开一个新窗口。另外Safari4的地址栏搜索匹配速度似乎没有firefox快。