挖井

类库大魔王的挖井日记

挖一口属于自己的井


Relay Bugs

Relay在线上时不时报些bug,不但客户和公司的人怨言颇多,我也苦不堪言。每次出现问题的时候,美国的PM都会在邮件里说Relay是个very important的东西,万万不能出问题,可是我怎么没看出公司对Relay有very important的重视和投入呢!整个项目除了web前端页面,其他的几乎是我一个人在开发和维护,而且我全职投入也就不到一年时间,后面就重心放在其他项目了,特性仍然在加,bug仍然要改,投入时间却是越来越少,直到现在每个月都不能保证有一二十个人时在上面。前些天一个QA说Relay的bug最多了,这时另一个开发帮忙说是因为投入时间太少。虽然说的是实话,但仍让我感到很惊讶,总算还有人知道实情。可是那些PM,Director之类的却不知是真不了解情况还是故意视而不见。

前天又一报了一次某个流出不来的问题,美国的support把web截图,日志以及netstat情况都发给我。从中可以了解到的是,流有进没出,netstat看出口有700多个CLOSE_WAIT,日志上没有任何有关出口异常的记录。昨天跟协议实现的原作者讨教了一番,再自己review了几遍代码,我觉得这次发现了一个可能性非常大的root cause,每次select只有5ms超时,如果返回0就没有任何动静退出流程了,考虑到那么多CLOSE_WAIT的情况,我觉得这个可能性很大啊。

改进的方法至少有两种,一是不用select,用epoll,但这样就失去了可移植性,二是select前加入FD_SET的socket都先判断一遍,不正常的都不加并关掉,这个方法的问题在于是否有可靠的判断socket正常的方法,getsockopt也许可以,也许不可以。还有个问题是,怎么搞出那么多CLOSE_WAIT来。

昨天还发现一些其他问题。一个root的进程重启后打不开了其他普通用户进程创建的shared memory,于是后面的逻辑就不正常了,这真是没预料到的事,难道shared memory只能用同一个用户创建的进程打开吗。进程退出的通知的漏掉的,我是用netlink实现的进程退出监控,为此还特别要求进程要root启动,可是后来发现有漏的。当初每启动一个子进程都会有个线程一直等它结束然后waitpid,后来换了netlink我没有注册子进程退出信号,就把子进程的父进程改成init了,于是好像不那么可靠了。

这些问题隐隐约约都觉得不是很难改的问题,但真要动手做又觉得有点棘手呢。

本文地址:

https://minidump.info/blog/2014/12/relay-bugs/

上一篇

对Go不够熟练

虽然使用Go语言写东西已经有一段时间了,但仍然不是很熟练,一些常见的用法仍然要不停地翻官方文档和搜以前写过的代码。前些天用Go的zlib包对数据进行压缩再传输,发现小数据量,比如4MB以下,总是压出结果只有2字节,这是明显有问题,实际上大点的数据量,比如5MB或更多,虽然压出的结果不是2字节了...…

Go 全文阅读
下一篇

websocket程序开发

之前提到过在公司的一个项目里用了websocket,client侧用C++开发,选了libwebsockets,使用的过程中遇到一些问题,这一个星期都是在不停地解决各个问题,好在现在终于基本上都搞定了,现在记录下来。我们的Client是统一由C++写的底层core,运行于多种上不同的平台之上,...…

Job 全文阅读