项目事故和安全语言

我不做web，没有玩过php.

看到robbin 一只提linux,我特意写了一个linux 下不释放内存的的deamon,run了一阵子，kill掉进程后，内存没有什莫泄漏。我用的是federo 3,稍微有点老，呵呵。

干嘛，坐而论道呢？

自己写个简单的 下不释放内存的的deamon，试一下，不就知道了吗？

我写了段C程序，malloc内存不free，试过了，确实进程退出就内存释放了。但是这种简单案例不足以说明问题。

robbin， 我和你的观点正好相反，验证某个概念的时候，只要模型能保证你要验证概念的完整性，那末，模型越简单越好。要做的只是focus on 你关注的，其他的干扰越少越好。

另外想起来补充一点：

服务器在托管之前，我使用ltp进行了连续24小时压力测试。以ltpstree.sh这么极其野蛮粗暴的测试，如果kernel有内存管理问题，当时就会暴露出来。ltp对于Linux的测试是非常充分的。

成本低->数量多->精品比例下降->精品绝对数量多.
成本高->数量少->精品比例上升->精品绝对数量少.

文革八个样本戏,各个是精品. 目前电视剧烂片横飞.
你喜欢哪一种情况.

这就是所谓项目事故和安全语言之间的关系.

我的看法：根本没有什么内存泄漏。只是free和top显示的有差别而已。top是直接给人参考价值的，free在某种程度上“欺骗”了管理员。那3G到底是怎么回事不清楚，可能要很长一段时间后才能有个思路。
理由：
1 机器没有真正的出现内存不足。
2 linux内存管理和其他unix完全不同，里面涉及的概念估计要到10个以上，至于32位和64位的差别也极有可能直接影响对内存是否即将耗尽的一些经验和直觉。

单纯程序内的内存泄漏，对操作系统不会有太大影响。
问题是，大多数程序需要跟外部环境交互，需要访问外部资源。
假设这样的内存泄漏：
分配一个内存块，然后释放了内存块，但是指针没有清空，
程序申请外部资源，分配了内存，地址与前面指针指向的有部分重合。
程序按前面的指针改写数据，导致外部资源的处理出错……

另外，C/C++程序需要使用动态连接库，动态连接库的内存泄漏。在无法完全释放动态链接库资源时，也是会对操作系统造成影响的。

不是free和top那么简单滴～，恐怕你还不知道很多Linux用来监控和排错的命令吧？ 你以为我们两个老鸟会连这么基本的问题都会犯错误？我也就罢了，第一次用Linux x86_64,我的朋友那给很多行业的关键应用做咨询的(电信，邮电，网游，甚至还有最机密的部门部署过n多x86_64)，会被这么个命令给迷惑吗？

那PHP的程序，访问量也不大，每天也就2万多PageView，一天下来，4GB物理内存大部分用光不说，连swap都开始用上了，我能不重起吗？换成ruby之后，内存吃的厉害多了，网站访问量也翻番了，每天4万多PageView，可是连续运行两周下来，不要说swap，空闲内存都在1GB以上，怎么解释？

房间里面有鬼，是鬼杀的。

你们再这么争论下去，也争论不出什么来。开始学习学习怎么配置Linux Kernel Debugger吧。

这个是典型的密室杀人案，最后一个离开的嫌疑最大。但是按照套路，通常结果会让人大吃一惊
突然有个问题，那个php4.4是编译成32位应用跑在64位平台上，还是直接编译成了64位的应用.
还有一个问题，只要进程还活着，它占用的内存(不管是不是泄漏了)，都会被内核跟踪到(系统并不管这个指针是不是已经是free了这个应用级别的问题)，所以要确认是不是进程惹的祸，肯定要在进程级别的内存信息才行,如果所有相关进程都不能显示出来分占了消失的3G的一部分，只能说内核的嫌疑更多一些。但如果是内核的问题，除了架LKD没有别的办法可以确认。
至于内核的成熟度，应用的越广自然越成熟，但是n多unix操作系统都在隔三差五的打补丁(不仅仅是安全补丁)，尽管其装机数巨大，也说明其还存在bug.