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

简介:

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

 

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

 

首先,我先上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:多线程中的异常,没有全局捕获的事件了?如果有,你在哪呢?

 

 

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

 

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

版权声明:本文原创发表于博客园,作者为路过秋天,原文链接:http://www.cnblogs.com/cyq1162/archive/2011/07/20/2111628.html

相关文章
|
1天前
|
存储 关系型数据库 MySQL
服务器数据恢复—EVA存储异常断电重启后虚拟机无法启动的数据恢复方案
服务器存储数据恢复环境: 某品牌EVA8400,服务器上安装VMware ESXi虚拟化平台,虚拟机的虚拟磁盘包括数据盘(精简模式)+快照数据盘,部分虚拟机中运行oracle数据库和mysql数据库。 服务器存储故障&检测: 存储异常断电重启后,存储中一台虚拟机无法启动。工作人员推测故障原因是异常断电导致电源模块出现故障,清空cache后重新启动存储发现该虚拟机仍无法正常启动。
|
1天前
|
弹性计算 Kubernetes 监控
【阿里云弹性计算】阿里云 ECS 与 Kubernetes 集成:轻松管理容器化应用
【5月更文挑战第28天】阿里云ECS与Kubernetes集成,打造强大容器管理平台,简化应用部署,实现弹性扩展和高效资源管理。通过Kubernetes声明式配置在ECS上快速部署,适用于微服务和大规模Web应用。结合监控服务确保安全与性能,未来将深化集成,满足更多业务需求,引领容器化应用管理新趋势。
15 2
|
2天前
|
弹性计算 Java 关系型数据库
最佳实践:阿里云倚天ECS在千寻位置时空智能服务的规模化应用
当前,千寻已有上千台倚天ECS实例在支撑线上核心业务。
|
2天前
|
运维 监控 Linux
提升系统稳定性:Linux服务器性能监控与故障排查实践深入理解与实践:持续集成在软件测试中的应用
【5月更文挑战第27天】在互联网服务日益增长的今天,保障Linux服务器的性能和稳定性对于企业运维至关重要。本文将详细探讨Linux服务器性能监控的工具选择、故障排查流程以及优化策略,旨在帮助运维人员快速定位问题并提升系统的整体运行效率。通过实际案例分析,我们将展示如何利用系统资源监控、日志分析和性能调优等手段,有效预防和解决服务器性能瓶颈。
|
2天前
|
弹性计算 运维 Java
最佳实践:阿里云倚天ECS在千寻位置时空智能服务的规模化应用
阿里云、平头哥及安谋科技联合举办的飞天技术沙龙探讨了倚天Arm架构在业务创新中的应用。活动中,千寻位置运维专家分享了将核心业务迁移到倚天处理器ECS实例的成功案例,强调了倚天处理器的高能效比和降本增效优势。迁移过程涉及操作系统、CICD系统和监控系统的适配,以及业务系统的性能测试。目前,千寻已迁移了上千台ECS实例到倚天处理器,实现了成本和效率的显著提升。未来计划继续扩展倚天处理器在核心业务和K8S中的应用。
|
2天前
|
弹性计算 运维 负载均衡
【阿里云弹性计算】阿里云ECS在金融科技中的应用案例:高性能交易系统的构建
【5月更文挑战第27天】阿里云ECS助力某证券公司构建高性能交易系统,满足高并发、高可用和弹性扩展需求。ECS凭借最新处理器技术、高速内存实现高性能计算;支持多地域、多可用区部署保证高可用性;弹性伸缩特性适应业务波动,降低运维成本。通过分布式架构和负载均衡技术,实现交易请求高效处理,确保系统稳定运行。案例证明,阿里云ECS是金融科技领域构建高性能交易系统的理想选择。
21 1
|
2天前
|
域名解析 缓存 安全
cdn服务器连接异常怎么办
当遇到CDN服务器连接异常时,可采取以下步骤排查:检查CDN配置,包括域名解析和防火墙设置;清空CDN缓存;测试网络连接;确认源服务器状态;更换CDN服务器;等待恢复;联系服务商;检查本地电脑安全;检查程序代码;保持更新和维护。具体解决步骤需根据实际情况调整。
|
3天前
|
消息中间件 弹性计算 物联网
【阿里云弹性计算】阿里云ECS在IoT领域的应用:支撑大规模设备连接与数据处理
【5月更文挑战第26天】阿里云ECS是弹性计算服务,支持IoT设备的连接与数据处理。通过MQTT协议实现设备快速接入,配合消息队列处理异构实时数据。ECS可用于部署数据处理工具、应用服务,如智能家居控制系统,通过弹性伸缩适应负载变化。结合阿里云其他服务,ECS为IoT提供完整解决方案,助力企业数字化转型。
11 0
|
4天前
|
弹性计算 监控 数据库
【阿里云弹性计算】企业级应用上云实战:基于阿里云 ECS 的 ERP 系统迁移案例
【5月更文挑战第25天】制造企业将面临资源不足、维护成本高和数据安全问题的ERP系统迁移到阿里云ECS,实现业务上云。通过数据迁移、应用部署、网络配置和性能优化等步骤,企业享受到弹性计算资源、高可靠性和数据安全优势,降低维护成本。阿里云提供24小时支持,助力企业数字化转型。此案例展示企业级应用上云的可行性,鼓励更多企业借助云计算实现创新发展。
18 0
|
6天前
dispatch_after引起的内存释放异常闪退
dispatch_after引起的内存释放异常闪退
7 0