花开的地方

　　这一段，忙。
　　从别人那里接过来的系统，想一下子弄明白真有些无从下手。好在备份和日志重新过了一遍，全部用自己的方法实现，心里有一些踏实了。
　　但是仍然惶恐，我明显的感觉到我需要做职业上的适应转变。原来撑握的东西要么用不上，要么就是不够精深，要么就是用到的时候不够熟练。总之是不像以前那样如鱼得水，轻车熟路了。压力很大啊！
　　有压力对我来说是好事吧？
　　但是我遇到另外的许多问题。比如与同事如何相处，这其实不是个问题，我自认人品没有问题，只要不是太过分的侵犯，对我来说都可以顺受。
　　好在，我终于修练得已经不是那么十分地在意别人怎么看我了，这对我来说是一个重要的进步。
　　学习上，我好像总是在提醒自己要不断学习，却似乎又没有实实在在地学到什么东西。学习方法有问题。以前是漫无目地的收集信息，现在应该是有目的的学习了。
　　车大人带过来一本《精通正式表达式》，一直没有花时间去仔细地学习正则。这个月就在做好工作的同时，仔仔细细地把这本书看完吧。希望自己能够对正则表达式的理解和认识有一个质的飞跃。
　　上海的生活实在是没什么新意，除了工作就是工作。好在已经有几个相当不错的朋友，会叫我去打球，督促我锻炼身体。而且我也确确实实地发现，每次打玩球回来，心情就会舒畅很多。
　　还好，这周未要去见两个美女。唯一的盼望？
　　上周因为工作紧迫，压力大，周未用来加班学习了，本来计划好的碰面约定只好往后推迟。
　　其中一个是在大学生运动会上认识的MM，六年多没见了，上上周在QQ上联系上，居然也在徐家汇附近，异乡遇故知，怎么也得见上一面吧？不管怎样，离这么远能认识就是一种缘份。

　　另一个就是我们的阿紫同学了，上周没去看成你（怎么别扭呢？河南话，大家都能看懂吧？），实在是情非得易啊，明天下了班就开始准备，这周肯定去看你和你的学校。

　　Linux系统上对每一个用户可使用的系统资源都是有限制的，这是多用户系统必然要采用的一种资源管理手段，试想假如没有这种机制，那么任何一个普通用户写一个死循环程序，用不了多久系统就要“拒绝服务”了。

　　今天我遇到了tomcat日志报的错误信息”too many open files”，第一意识就想到了是ulimit控制的”open files“限制。然而问题来了。我在/etc/profile里加入了 ulimit -n 4096保存之后，普通用户登录的时候均会收到一条错误信息ulimit: open files: cannot modify limit: Operation not permitted。然后普通用户的open files限制还是默认值1024。

　　然后开始在互联网上搜索关于ulimit的信息。互联网果然方便，信息铺天盖地。大家也可以搜一下试一下。其中我了解到两个以前不知道的相关内容。
　　第一个是内核参数　fs.file-max  ，影射为 /proc/sys/fs/file-max
　　第二个是配置文件 /etc/security/limits.conf

　　其中大部分的信息中提到 将 /proc/sys/fs/file-max的值设置为4096和ulimit -n 4096是相同的效果。对此我很怀疑，为什么呢？首先ulimit 是一个普通用户也可以使用的命令，而fs.file-max只有root有权设置。其次，很明显fs.file-max是一个全局的设置，而ulimit是一个局部的设置，很明显的是不相同的。

　　带着疑虑，又在网上搜索了许久，未果（实际上是我搜索的关键字不够准确）。
　　最后终于在内核文档/usr/src/linux/Documentation/sysctl/fs.txt里找到下面一段话：

file-max & file-nr:
The kernel allocates file handles dynamically, but as yet it doesn’t free them again. The value in file-max denotes the maximum number of file-handles that the Linux kernel will allocate. When you get lots of error messages about running out of file handles, you might want to increase this limit.

The three values in file-nr denote the number of allocated file handles, the number of unused file handles and the maximum number of file handles. When the allocated file handles come close to the maximum, but the number of unused file handles is significantly greater than 0, you’ve encountered a peak in your usage of file handles and you don’t need to increase the maximum.

　　这两段话的大致意思是：
　　内核动态地分配和释放“file handles”（句柄）。file-max的值是内核所能分配到的最大句柄数。当你收到大量关于句柄用完的错误信息时，你可以需要增加这个值以打破老的限制。
　　file-nr中的三个值的含意分别是：系统已经分配出去（正在使用）的句柄数，没有用到的句柄数和所有分配到的最大句柄数。当分配出去的句柄数接近最大句柄数，而“无用的句柄数”大于零时，表明你遇到了一个“句柄”使用高峰，这意为着你不需要增加file-max的值。

　　看完这段话，相信大家都明白了。file-max是系统全局的可用句柄数。根据我后来又翻查的信息，以及对多个系统的查看求证，这个参数的默认值是跟内存大小有关系的，增加物理内存以后重启机器，这个值会增大。大约1G内存10万个句柄的线性关系。

　　再回过头来看这两段话，不知道你意识到了没有，文中只提到了file-max的增加，而没有提到了该值的减少。那些在操作ulimit时同时操作了file-max的哥们儿，估计无一例外地将file-max设置成了4096或者2048。但以似乎也没有因此而导致系统无法打开文件或者建议连接。（实际上，我将file-max的值设备成256，然后使用shell编写用vi打开500个文件角本运行，并没有得到任何错误信息，查看file-nr的值，系统当前分配的句柄值已经远超过了后面的最大值。所以我猜想对于file-max的任何减少的操作都是毫无意义的，姑且不去管他。实践中需要减少file-max的时候总是不多见的。 ）实事证明我犯了一个致命的错误。我测试的时候使用的是root用户，而当我再次使用普通用户测试的时候，预料中的错误信息出现了：”Too many open files in system”。可见，file-max的减少对系统也是影响力的。前面的结论“所以我猜想对于file-max的任何减少的操作都是毫无意义的”是错误的。

　　然后便是/etc/security/limits.conf文件，这个文件很简单，一看就能明白。

　　于是我按照注释中描述的格式两个两行：

*　　soft　　nofile　　4096
*　　hard　　nofile　　4096

　　恐怖的是，网上居然有人说改了这个设置是需要重启系统的！实在是让人想不通啊，鼎鼎大名的UNIX系统，怎么可能因为这么小小的一个改动就需要重启系统呢？结果当我再次以普通用户登录的时候，那个”ulimit: open files: cannot modify limit: Operation not permitted”提示没有了，查看ulimit -n，果然已经变成了4096。

　　凌晨三点儿，我发觉bus失踪了。
　　我找遍了公司的每一个角落，只有blog躺在椅子下面，四处不见bus的踪影，唤了几声，没有动静……刚才外面雷电交加，大雨倾盆，可怜的bus不知道会被折磨成什么样子。  

　　 ……