• 服务器内存太小,伤不起![异常与应用程序池引发的连锁命案]


    最近都在写 秋色园技术原理解析 文章,今天就写一篇散文,简述一下服务器内存太小引发的命案。

     

    以前写文都排版,这篇就当散文了...写完就这样了,当然加黑加红还是给加了。

    首先,我先上2张秋色园服务器当前进程及内存的图片:

     

    1:进程

    2:物理内存剩余

    看完这两张图片,啥感觉?内存穷紧张!!!!

    穷紧张不打紧,打紧的是比紧张还紧张的情况发生了,什么情况?

    出事故了,应用程序池要产生回收动作了!!!!

    先看一下应用程序池什么情况会产生回收动作?

    1:IIS应用程序池里的“回收”里的配置就不说了,这些是你自己定义的。

    2:你手动执行“回收”,以重启应用程序池。

    3:你升级dll到服务器中,新升的升级会引发应用程序池重启。

    4:web应用程序产生“错误”,进程终止,引发应用程序池重启。

    5:临时想不出来......

    出事了,出事了,出啥事了?

     

    还不是内存穷紧张那点破事,为了演示一下什么事,我决定回收一下应用程序池给大伙截图!!!

     

    这里本机示例回收了,大伙知道咋回事就可以了,哈哈:

    看到了吧,两个进程,这是什么情况?

    IIS启用了新的进程来接收新的请求,同时旧的进程请求会保留继续处理之前的请求队列,直到处理完所有之前的请求才结束。

    大体就是这么一回事了,问题就产生在这一瞬间:

    本来就没内存了,旧的进程不回收,新的进程又出来,一出来就喊着要内存,可是系统又给不了内存,于是就卡在那里,还造成CPU百分百的情况。

    就在这个小间间,网站访问就卡住了,打不开了,给人一种速度超慢的感觉。

    什么时候你感觉打开了,估计就是旧的进程光荣退休了。

    好了,升级时候的情况并不多,应用程序池也设置了半夜才回收一次,理论上回收也不多,这种小瞬间产生的机率并不多。

    可是网站不稳定的情况才出现的挺频繁,似乎超出我设置的时候和升级的频率。

    就在这些天,我发现我基础有点差:

    web应用程序产生“错误”,进程终止,引发应用程序池重启。

    以前都没怎么注意,现在发现了,代码写的不好,异常不处理好,应用程序池就会经常性重启,也是引发你网站慢的一个原因。

    给大伙截一张图:

    大伙到自己服务器上看这事件,如果看到一堆错误及警告,说明你和我一样基础差。

     

    这些日志是怎么产生的?

     

    其实就是系统未被捕获的异常的,然后最终一路过五关,最后就跑这来了,跑到这来,基本上你的应用程序池就变的很不稳定的说。

    下面就随意扯扯异常这事情

    首先一点就是:

    在.NET 2.0中,主线程或线程的错误,都会导致进程的中止,引发应用程序池回收。

    1.1版本的时候,线程的错误是不会引发主进程中止的。

    PS:还记得我上篇文章“秋色园QBlog技术原理解析:性能优化篇:用户和文章计数器方案(十七)”说到的内置线程吧,

    其实隐藏说的就是这问题,线程的访问冲突,经常性的引发了主进程中止,导致应用程序池重启。

    再说一点的就:

    先把日志上的警告和异常给处理了。

    最后一点的就是:

    全局捕获未处理的异常,然后作掉它,不让它跑到这来危害应用程序池重启。[补充:作掉它并不能避免应用程序池重启]

    基础不好,很多天了,才偶然发现这么点代码:

    一:AppDomain.CurrentDomain.UnhandledException 事件

            public Window1() {
                InitializeComponent();
                AppDomain.CurrentDomain.UnhandledException 
    += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
            }

            
    void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
            {
                
    throw new NotImplementedException();
            }

    PS:在web中发现这家伙似乎不起作用,没深入纠结它,而且它阻止不了异常往上报,只能是收集信息用。

    二:HttpApplication.Error事件

            public void Init(HttpApplication context)
            {
                context.BeginRequest 
    += new EventHandler(context_BeginRequest);
                context.Error 
    += new EventHandler(context_Error);
            }

            
    void context_Error(object sender, EventArgs e)
            {
                HttpApplication app 
    = (HttpApplication)sender;
                Log.WriteLogToTxt(app.Server.GetLastError());
                app.Server.ClearError();//把错误消灭了,不让它往上抛
            }

    这里其实要说的就是app.Server.ClearError(),为了发现这一行代码,我纠结了好多个小时,最后很偶然才发现它,[虽然发现了它,但是作用似乎不大]。

     

    补充:

    在楼下网友:长河落魄 的疑问声中,我测试了一下,得到以下结果:

    1:主线程中产生的“错误”,只要不是致命的,系统日志中仅是“警告”级别,它不会引发应用程序重启。

    2:内置线程中产生的“错误”,系统中产生的“错误”级别,它会中止进程,而且,上面的全局语句并不能捕获到异常。

     

    当然,这里还有几个疑惑:

    1:应用程序池是不是只遇到“错误”级别的,才会引发终止,重启?

    2:主线程中一般的错误都是“警告”级别,那有没有可能会产生“错误”级别的错误呢?如果产生了,是不是一样可拦截?这上面的清除异常的代码,是不是就有效了?

    3:多线程中的异常,没有全局捕获的事件了?如果有,你在哪呢?

     

     

    好了,现在基本上错误都被记录,一步一步对着日志一个一个消灭了,现在基本上应用程序池很稳定不乱重启了,安稳了许多。

    其实总结还是一句:内存太小,伤不起啊!

  • 相关阅读:
    odoo开发笔记 -- 后台代码什么时候需要注意编码格式
    mysql添加类似oracle的伪列及查看表信息
    windows10升级系统后,无法远程桌面连接服务器
    时间管理
    odoo开发笔记 -- odoo仪表板集成hightcharts
    odoo开发笔记 -- odoo10 视图界面根据字段状态,动态隐藏创建&编辑按钮
    odoo开发笔记 -- odoo源码下载地址(非官方)
    odoo开发笔记 -- 异常信息处理汇总
    macbook 安装oracle RAC
    ubuntu升级pip后, ImportError: cannot import name ‘main‘
  • 原文地址:https://www.cnblogs.com/cyq1162/p/2111628.html
Copyright © 2020-2023  润新知