9 个解决方案
#1
其实不管是自动还是手动,其工作机理都是一样的。
你自动回收的条件设置的是什么呢?是不是由于程序已经出现了错误而导致回收失败呢?卡死是什么概念,windows 桌面没有响应吗?
而你的手动回收是不是在系统正常运行的时候做的呢?
你自动回收的条件设置的是什么呢?是不是由于程序已经出现了错误而导致回收失败呢?卡死是什么概念,windows 桌面没有响应吗?
而你的手动回收是不是在系统正常运行的时候做的呢?
#2
多谢楼上的前来捧场~!
是这样的,程序中肯定是有BUG,因为以前人员编写代码编写不规范,代码量也比较大,排查了一两个星期也没找出根本原因,所以决定在新版上线之前,不再追查原因了,让程序池自动回收,目前应用程序池设置为最大内存使用为700MB,最长120分钟回收一次,最大虚拟内存使用没有设置,基本是这个样子的,服务器上有七八个站点,这个站点是独立的应用程序池
是这样的,程序中肯定是有BUG,因为以前人员编写代码编写不规范,代码量也比较大,排查了一两个星期也没找出根本原因,所以决定在新版上线之前,不再追查原因了,让程序池自动回收,目前应用程序池设置为最大内存使用为700MB,最长120分钟回收一次,最大虚拟内存使用没有设置,基本是这个样子的,服务器上有七八个站点,这个站点是独立的应用程序池
#3
120分钟回收一次也太频繁了吧?一般默认值1740挺合理的。
最大使用内存(也就是private bytes)700MB,如果是ASP.NET应用的话,设为这个数值基本合理,达到800MB之后就会发生内存泄漏。但是对于ASP应用来说,由于本身没有内存回收机制,所以我们一般经验值是设置在1.2G左右比较合适。
最大使用内存(也就是private bytes)700MB,如果是ASP.NET应用的话,设为这个数值基本合理,达到800MB之后就会发生内存泄漏。但是对于ASP应用来说,由于本身没有内存回收机制,所以我们一般经验值是设置在1.2G左右比较合适。
#4
是ASP+SQL2000的多用户平台,如果设置1.2G,那自动回收的时候更是卡死
#5
更是卡死说明你的内存不够啊。
如果设置成700的话,它就经常回收了,因为ASP很容易就达到700了。
这种问题一般都是由于你代码里面connection,recordset没有及时close所引起的。
另外,如果写了"on error resume next"而后面又跟了个"while not rs.eof"之类的循坏,一旦rs.eof出现错误就会变成死循环,很容易内存泄漏。
如果设置成700的话,它就经常回收了,因为ASP很容易就达到700了。
这种问题一般都是由于你代码里面connection,recordset没有及时close所引起的。
另外,如果写了"on error resume next"而后面又跟了个"while not rs.eof"之类的循坏,一旦rs.eof出现错误就会变成死循环,很容易内存泄漏。
#6
这些都查了,不过快放年假了,还得每天得提防着这个,什么也不做,就得准备着随时回收应用程序池,头痛,过个年都不安宁,有什么办法不?
#7
是ASP+SQLserver的,是利用oblog修改的
#8
那么你有没有抓包呢?
#9
http://hi.baidu.com/irinihp/blog/item/eaa9dd8b139885799e2fb49a.html
#1
其实不管是自动还是手动,其工作机理都是一样的。
你自动回收的条件设置的是什么呢?是不是由于程序已经出现了错误而导致回收失败呢?卡死是什么概念,windows 桌面没有响应吗?
而你的手动回收是不是在系统正常运行的时候做的呢?
你自动回收的条件设置的是什么呢?是不是由于程序已经出现了错误而导致回收失败呢?卡死是什么概念,windows 桌面没有响应吗?
而你的手动回收是不是在系统正常运行的时候做的呢?
#2
多谢楼上的前来捧场~!
是这样的,程序中肯定是有BUG,因为以前人员编写代码编写不规范,代码量也比较大,排查了一两个星期也没找出根本原因,所以决定在新版上线之前,不再追查原因了,让程序池自动回收,目前应用程序池设置为最大内存使用为700MB,最长120分钟回收一次,最大虚拟内存使用没有设置,基本是这个样子的,服务器上有七八个站点,这个站点是独立的应用程序池
是这样的,程序中肯定是有BUG,因为以前人员编写代码编写不规范,代码量也比较大,排查了一两个星期也没找出根本原因,所以决定在新版上线之前,不再追查原因了,让程序池自动回收,目前应用程序池设置为最大内存使用为700MB,最长120分钟回收一次,最大虚拟内存使用没有设置,基本是这个样子的,服务器上有七八个站点,这个站点是独立的应用程序池
#3
120分钟回收一次也太频繁了吧?一般默认值1740挺合理的。
最大使用内存(也就是private bytes)700MB,如果是ASP.NET应用的话,设为这个数值基本合理,达到800MB之后就会发生内存泄漏。但是对于ASP应用来说,由于本身没有内存回收机制,所以我们一般经验值是设置在1.2G左右比较合适。
最大使用内存(也就是private bytes)700MB,如果是ASP.NET应用的话,设为这个数值基本合理,达到800MB之后就会发生内存泄漏。但是对于ASP应用来说,由于本身没有内存回收机制,所以我们一般经验值是设置在1.2G左右比较合适。
#4
是ASP+SQL2000的多用户平台,如果设置1.2G,那自动回收的时候更是卡死
#5
更是卡死说明你的内存不够啊。
如果设置成700的话,它就经常回收了,因为ASP很容易就达到700了。
这种问题一般都是由于你代码里面connection,recordset没有及时close所引起的。
另外,如果写了"on error resume next"而后面又跟了个"while not rs.eof"之类的循坏,一旦rs.eof出现错误就会变成死循环,很容易内存泄漏。
如果设置成700的话,它就经常回收了,因为ASP很容易就达到700了。
这种问题一般都是由于你代码里面connection,recordset没有及时close所引起的。
另外,如果写了"on error resume next"而后面又跟了个"while not rs.eof"之类的循坏,一旦rs.eof出现错误就会变成死循环,很容易内存泄漏。
#6
这些都查了,不过快放年假了,还得每天得提防着这个,什么也不做,就得准备着随时回收应用程序池,头痛,过个年都不安宁,有什么办法不?
#7
是ASP+SQLserver的,是利用oblog修改的
#8
那么你有没有抓包呢?
#9
http://hi.baidu.com/irinihp/blog/item/eaa9dd8b139885799e2fb49a.html