最近都在写 秋色园技术原理解析 文章,今天就写一篇散文,简述一下服务器内存太小引发的命案。
以前写文都排版,这篇就当散文了...写完就这样了,当然加黑加红还是给加了。
首先,我先上2张秋色园服务器当前进程及内存的图片:
1:进程
2:物理内存剩余
看完这两张图片,啥感觉?内存穷紧张!!!!
穷紧张不打紧,打紧的是比紧张还紧张的情况发生了,什么情况?
出事故了,应用程序池要产生回收动作了!!!!
先看一下应用程序池什么情况会产生回收动作?
出事了,出事了,出啥事了?
还不是内存穷紧张那点破事,为了演示一下什么事,我决定回收一下应用程序池给大伙截图!!!
这里本机示例回收了,大伙知道咋回事就可以了,哈哈:
看到了吧,两个进程,这是什么情况?
IIS启用了新的进程来接收新的请求,同时旧的进程请求会保留继续处理之前的请求队列,直到处理完所有之前的请求才结束。
大体就是这么一回事了,问题就产生在这一瞬间:
本来就没内存了,旧的进程不回收,新的进程又出来,一出来就喊着要内存,可是系统又给不了内存,于是就卡在那里,还造成CPU百分百的情况。
就在这个小间间,网站访问就卡住了,打不开了,给人一种速度超慢的感觉。
什么时候你感觉打开了,估计就是旧的进程光荣退休了。
好了,升级时候的情况并不多,应用程序池也设置了半夜才回收一次,理论上回收也不多,这种小瞬间产生的机率并不多。
可是网站不稳定的情况才出现的挺频繁,似乎超出我设置的时候和升级的频率。
就在这些天,我发现我基础有点差:
web应用程序产生“错误”,进程终止,引发应用程序池重启。
以前都没怎么注意,现在发现了,代码写的不好,异常不处理好,应用程序池就会经常性重启,也是引发你网站慢的一个原因。
给大伙截一张图:
大伙到自己服务器上看这事件,如果看到一堆错误及警告,说明你和我一样基础差。
这些日志是怎么产生的?
其实就是系统未被捕获的异常的,然后最终一路过五关,最后就跑这来了,跑到这来,基本上你的应用程序池就变的很不稳定的说。
下面就随意扯扯异常这事情
首先一点就是:
在.NET 2.0中,主线程或线程的错误,都会导致进程的中止,引发应用程序池回收。
1.1版本的时候,线程的错误是不会引发主进程中止的。
PS:还记得我上篇文章“秋色园QBlog技术原理解析:性能优化篇:用户和文章计数器方案(十七)”说到的内置线程吧,
其实隐藏说的就是这问题,线程的访问冲突,经常性的引发了主进程中止,导致应用程序池重启。
再说一点的就:
先把日志上的警告和异常给处理了。
最后一点的就是:
全局捕获未处理的异常,然后作掉它,
不让它跑到这来危害应用程序池重启
。[补充:作掉它并不能避免应用程序池重启]
基础不好,很多天了,才偶然发现这么点代码:
一:AppDomain.CurrentDomain.UnhandledException 事件
PS:在web中发现这家伙似乎不起作用,没深入纠结它,而且它阻止不了异常往上报,只能是收集信息用。
二:HttpApplication.Error事件
这里其实要说的就是app.Server.ClearError(),为了发现这一行代码,我纠结了好多个小时,最后很偶然才发现它,[虽然发现了它,但是作用似乎不大]。
补充:
在楼下网友:长河落魄 的疑问声中,我测试了一下,得到以下结果:
1:主线程中产生的“错误”,只要不是致命的,系统日志中仅是“警告”级别,它不会引发应用程序重启。
2:内置线程中产生的“错误”,系统中产生的“错误”级别,它会中止进程,而且,上面的全局语句并不能捕获到异常。
当然,这里还有几个疑惑:
1:应用程序池是不是只遇到“错误”级别的,才会引发终止,重启?
2:主线程中一般的错误都是“警告”级别,那有没有可能会产生“错误”级别的错误呢?如果产生了,是不是一样可拦截?这上面的清除异常的代码,是不是就有效了?
3:多线程中的异常,没有全局捕获的事件了?如果有,你在哪呢?
好了,现在基本上错误都被记录,一步一步对着日志一个一个消灭了,现在基本上应用程序池很稳定不乱重启了,安稳了许多。
其实总结还是一句:内存太小,伤不起啊!