之前已经实验出linux内存管理上的确存在弱点，但是对于为什么内存耗尽后不能重启应用服务象oracle，甚至不能重启系统，也不能杀死已经无效的应用进程感到不解。这次在dep服务器上在极少的内存环境中运行旧系统，看看极限可以承受到什么水平。这个系统在512M内存和PiiCPU，比一般的桌面机还要弱，但运行了包括oracle/java/web/等多个吃内存的老虎，撑到第三天终于挂了，在处理过程中发现导致上面不能重启是由于vfs在 flush/iupdate时由于内存耗尽不能完成进程，和超块死锁造成的。
把重启测试服务器应用的cron脚本中止后，第三天，终于看到这台服务器exhausted，这再次证明linux对内存（处理上的弱点）。随后做第二个实验，恢复每小时一次的脚本应用重启，但不让服务器两天一次重启，看看可以支撑多长时间。......还没完，那台服务器重启应用后完全不能响应，而打算重启服务器本身居然也不能关机。检查看有的进程，看来用光一次后，整个系统就象特级残废一样无法恢复正常了。（十分钟以后）在让管理员硬性重启后，系统仍然没有恢复正常，报告是需要手工Ctrol-D进行fsck操作，这也是题中应有之意。但到机房进行操作，顺便加上一两G内存时，却碰上了意外的情况。
首先是不同的内存条（频率是一样的）冲突，不知为什么，却是反应为scsi硬盘寻不着道，换成同一品种后故障消失了。随后在识别几十个mount点时碰到困难——我是很讨厌那种不是使用设备标识符而使用label的fstab的，不得不一个个地查那个label对应那个标识符。最后完成后启动，ls却发现 "/"所有文件都不见了。badblock也找不到坏区，似乎是ext2链表乱了。在这个问题上翻天下地弄了差不多两个小时，默驴技穷，看来如果不是强行 fsck 根目录，就得重装根目录，然后再重整旧文件，不过这是非常危险的操作，八成等于系统重装。正在没有辄的时侯，发现dir却是有响应的：莫非是显示器没有能够显示目录色彩所以隐形了？抱着最后一丝希望把另一辆小车上的显示器推过来一接，咳，就是。瞧，显示器的质量也是可以害死人的，差点让我把一个还算是好的系统重装了。
回顾这次和以前若干次在另外的主机上的同样尝试，表明一旦 linux的内存用光后，除了新的应用请求分配内存需要等待外，更重要的是，会造成vfs进入死循环等待。估计是由于kflush以前形成高速缓存时由于没有请求到新的内存，所以锁死的某一个超块始终不能释放；其他要访问类似超块的进程也只好干等待；另一方面由于不能最后完成flush写入，进程也不能清空。这时，对于系统来说，就是原有的IO进程没有完成，这样，linux就会忽略所有的kill signal 6重启信号，等这些进程完成。这样就进入我已经重复出来的一旦内存 exhausted后不但所有应用不能恢复，就算把部分进程杀掉清出内存，也没有看出该死锁释放的迹象；或者下一次我应该多等一段时间。问题是，目前我没有找到很好的在实验室重复这种极限状态的方法，每次碰到都是在工作系统高峰时，这时侯总是急不可待要恢复系统。
某个角度看，这说明linux系统在考虑这种极端状况时vfs内存保护上做得不够，它或者应该象oracle一样申请一个全局内存区，确保vfs内存专用，不多占也不允许共享，宁愿为此承受读写性能的损失而确保系统可靠性。反过来，这样也可以简化它与其它应用分配内存时的复杂程度和可能出现的意外死锁条件的出现。也许实际上在内核安装升级时是有这样的配置的，只是我没有注意到。相比之下，windows/fat没有考虑这种高速缓存-搜索相近存储块的机制，（NTFS有类似的机制，但实行了保护内存），以承受硬盘存储块渐渐碎片化的代价避免这种极限状况下对系统的损坏。虽说windows死一次机就按一次reset可以沦为笑柄，但反过来每次硬重启都是相对健康倒也不见得不是一种优点。
我仍是推崇使用linux，原来并不是因为它的技术比windows/nt系列先进，linux实际上就是x86上的unix，基本架构产生于三十多年前，而windows则是只有十年历史，从基本架构的考虑的先进性来说，windows无疑要比 linux先进。使用linux是因为它是可控的，而且作为功能单一的服务器，比windows的平均性能比要高得多，只要不是在上面跑多种应用，它是稳定的，本人工作系统最长的uptime是 459天；这在windows是不可能做到的。
(T114)
