2009年七月月 发布的文章

巴萨·2009-2010赛季看点

明天凌晨三时,西甲“三冠王”巴萨将迎来自己2009-10赛季季前赛的第一场热身比赛,客场在温布利球场挑战托特纳姆热刺队。巴萨作为上个赛季的三冠王,其风头最近被在转会市场呼风唤雨的皇马主席弗洛伦蒂诺抢去了不少。与皇马在转会市场的风光无限比起来,巴萨似乎有些沉寂:先是拿下了国米弃将马克斯维尔,再又签下了巴西年轻射手凯里森,今天上午媒体爆料埃托奥和伊布的交易即将成功,只是官方还未证实,而且针对这笔交易大家也是各抒己见。那么这支巴萨还能否重现上赛季的辉煌呢?这个没有定论,但是新赛季新巴萨还是有几大看点值得球迷期待:

1、卫冕“三冠王”
这是梅西的愿望,也是所有巴萨球迷的愿望。历史上似乎没有哪支球队卫冕过“三冠王”。巴萨能否成为历史NO.1,这的确最值得大家期待。

2、夺取六冠
除了已经揣入囊中的冠军杯、西甲冠军和国王杯冠军之外,巴萨还有三个延续性的奖杯可以去夺取:西班牙超级杯、欧洲超级杯和世俱杯。哈维的愿望是夺取“六冠”。

3、新“三叉戟”
2008-09赛季,梅西、埃托奥和亨利组成的三叉戟在欧洲赛场所向披靡,其中典型的比赛包括5:2屠里昂和4:0屠拜仁。不过最近的埃托奥和伊布的交换可能让新赛季的三叉戟有了新的改变- 梅西、伊布和亨利,到底这次交换成功与否,就要看新赛季新巴萨三叉戟的发挥了。

4、青训“妖人”
巴萨青训系统近几年的崛起,让巴萨球迷对现有青训体系下诸多适龄球员充满了期待。比如:天赋于梅西十倍的盖伊.阿苏林和普队替身穆捏萨等,本赛季这些拉玛西亚出品的妖人能否在一线队有上佳表现,还需时间来证明。

5、巴萨梦三 vs 银河战舰2
巴萨用三冠王的荣誉向世人宣告了“巴萨梦三”的启航,而皇马则在用金元招来了C罗、卡卡和本泽马后向世界宣告银河战舰2的重组,新赛季西甲必定更加好看,因为有梦三和银河战舰2的对决,到底鹿死谁手让我们拭目以待。


微博:@tonybai_cn
微信公众号:iamtonybai
github.com: https://github.com/bigwhite

周末“捉虫”记

周六,对于上班族来说是多么好的日子,能在家里享受自由的无拘无束的生活而且不用担心第二天的工作,应该说是一周中最没有压力的一天。六点半起床,慢慢喝下一杯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的输出与今天处理的情况几乎相同。想必是一个问题。因为出问题的函数是很久以前的代码了,而且是复用库中的一处代码。估计所有复用了该库的产品都要做一次升级了。

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

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats