人品爆发

周五下午，作为年终的一系列活动之一，CPC 和 NO 在一起举行一个小小的抽奖仪式。结果抽中一个睡袋，结束 N 年以前抽奖不中的记录.. 不过真正的人品爆发是下班前的一件事情：

不知道为什么，临下班的时候内部网络出现故障，结果导致 MySQL 连接过多，too many connections，当时也没有可用的 mysql client 连接，无法去 show processlist 看看都发生了什么。心急如焚，这得影响多少网民啊；另一个心急如焚的原因是偶要赶晚上8点13的火车去天津，票都已经买好，如果为了不被网民以及上级骂死而耽误火车，势必会被老婆骂死。

终于在一个偶然的机会，mysql 连接了上去（很快连接又被占满了）。看了看 processlist，一堆的 unauthenticated user 在试图 connect/login

我立刻想起就在昨天赵宏威在 MSN 上问我同样的问题，当时偶也觉得这个事情比较诡异，但没有帮他找答案，没想到第二天同样的问题就碰上我了。赶紧在 MSN 上问他最后是怎么解决的故障，说是启动的时候加 --skip-name-resolve 参数就好了。

赶紧告诉 DBA 重启，果然问题消失。然后感叹人品之坚挺——出的问题正好是别人刚碰到的，而且他又正好来问我，真是幸运啊幸运。

重新探讨故障原因，应该是 MySQL 的安全模型里面进行用户认证和授权的过程中，除了对 IP 地址做校验之外，还包括了对 HostName 验证的配置。因此所有的用户连接进来以后都需要做一次反向域名查询，然后根据 IP 和 HOST 来进行授权。这样如果因为网络故障导致反向域名解析很慢的话，就会让一个连接很长时间也无法完成...

由此引申开去：
一、MySQL 是否能处理的更好一些呢？相关的 BUG 在 2005 年就有人报告。我觉得在执行反向域名解析之前，至少可以先判断一下来源 IP 是否已经在策略表里面存在，如果存在的话就可以直接做用户认证了

二、标准 C 库(glibc)能不能想法降低做反向解析的时间？比如执行查询之前可以设置一个超时时间？因为反向解析而给用户带来困惑我已经见过好多好多回了

三、我们使用的连接池程序(据说是 resin 自带)是否有问题？当然我不是 Java 程序员，而且这次故障原因和 Java 没有任何的关系。可是明明有连接池限制怎么还会出现 too many connections？看起来是因为 mysql 连接迟迟没有响应，导致连接池程序开始后继的尝试。做新的尝试没有问题，为什么不去 close 以前的连接？？或许是写这个连接池的人对 GC 过于自信了？很难想象一个有本事写连接池的 C 程序员会犯这样的失误。嘻嘻，腹谤一次 java

最后虽然有些赶时间，但还是坐上了开往天津的火车。我很严肃的思索了一下为什么今天会有如此之好的人品——结论是周五我做的唯一和以往不同的事情就是偷偷使用了老婆的保湿水和面霜，看来美容活动得坚持下去啊...

以前听人说：女人三十岁前的模样是天生的，三十岁后的模样是自己给的。我补充一下，男人三十岁前的模样是天生的，三十岁后的模样是老婆给的。