I deployed an ASP.NET web application last night and I when I woke up this morning it was very slow and would occasionally just throw a 'Service Unavailable' error.
我昨晚部署了一个ASP.NET Web应用程序,当我今天早上醒来时它非常慢,偶尔会抛出一个“Service Unavailable”错误。
I checked the Event Viewer and it was filled up with these errors:
我检查了事件查看器,它充满了这些错误:
An unhandled exception occurred and the process was terminated.
发生未处理的异常并终止该过程。
Exception: System.Runtime.Serialization.SerializationException
Message: Unable to find assembly 'MonoTorrent, Version=0.80.0.0, Culture=neutral, PublicKeyToken=null'
消息:无法找到程序集'MonoTorrent,Version = 0.80.0.0,Culture = neutral,PublicKeyToken = null'
I'm puzzled as it was working perfectly when I deployed it (MonoTorrent is required to retrieve the number of seeders/leechers for a certain torrent off the tracker - this was working fine), but it's no longer working and whenever code that uses MonoTorrent gets involved, the worker process just crashes.
当我部署它时,我很困惑,因为它工作得很好(MonoTorrent需要从跟踪器中检索出某些种子的播种者/ leechers数量 - 这很好用),但它不再有效,并且每当使用MonoTorrent的代码时参与其中,工人流程崩溃了。
MonoTorrent.dll is in the /bin/ directory.
MonoTorrent.dll位于/ bin /目录中。
UPDATE 6/4/10: I compiled the MonoTorrent source code in with the rest of my web application, but it still crashes whenever it uses MonoTorrent. However, it now says that it is Unable to find assembly 'OpenPeer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. Here, OpenPeer is the name of the web application's assembly.
更新6/4/10:我使用其余的Web应用程序编译了MonoTorrent源代码,但是只要它使用MonoTorrent它仍然会崩溃。但是,它现在说无法找到程序集'OpenPeer,Version = 1.0.0.0,Culture = neutral,PublicKeyToken = null。这里,OpenPeer是Web应用程序程序集的名称。
9 个解决方案
#1
3
This can happen in these circumstances:
在这些情况下会发生这种情况:
The ASP.NET app creates a background thread, which throws an uncaught exception. It looks like ASP.NET catches the exception and wants to log it to the Event Log. To do this, it sends this exception from the Web app's app domain to its own app domain (the default one of the w3wp process). This needs a serialization/deserialization of the exception.
ASP.NET应用程序创建一个后台线程,该线程抛出未捕获的异常。看起来ASP.NET捕获异常并希望将其记录到事件日志中。为此,它将此异常从Web应用程序的应用程序域发送到其自己的应用程序域(w3wp进程的默认属性)。这需要异常的序列化/反序列化。
If the exception is a custom one (i.e. defined by the Web app), it cannot be deserialized in the main app domain of ASP.NET because the assembly defining the exception is typically in the Web app's bin directory, not where w3wp.exe is (c:\windows\system32\inetsrv). This causes a serialization exception and w3wp crashes.
如果异常是自定义的(即由Web应用程序定义),则无法在ASP.NET的主应用程序域中反序列化,因为定义异常的程序集通常位于Web应用程序的bin目录中,而不是w3wp.exe所在的位置。 (C:\ Windows \ System32下\ INETSRV)。这会导致序列化异常并导致w3wp崩溃。
There are possible ways to fix the issue (in a - very subjective - order of preference):
有可能解决问题的方法(以非常主观的方式 - 优先顺序):
- Copy the missing DLL in c:\windows\system32\inetsrv
- Install the missing DLL in the GAC
- Remove the cause of the exception (harder to do than to say, as we say in French)
- Catch all exceptions from the background thread yourself and do the logging yourself.
在c:\ windows \ system32 \ inetsrv中复制丢失的DLL
在GAC中安装缺少的DLL
消除异常的原因(比说法语时更难说)
自己从后台线程中捕获所有异常并自行进行日志记录。
Notes:
- If WCF is used and the uncaught exception is FaultException, WCF swallows it and there is no crash
- If the uncaught exception is in the thread of the Web request, there is a yellow screen of death, not this serialization exception
- It really seems like a bug in ASP.NET
- The above is actually a summary of my investigations of this issue yesterday and are only a theory. I tested fixes 1 and 4, as well as using FaultException.
如果使用了WCF并且未捕获的异常是FaultException,则WCF会吞下它并且不会发生崩溃
如果未捕获的异常位于Web请求的线程中,则会出现黄色的死亡屏幕,而不是此序列化异常
这看起来像是ASP.NET中的一个错误
以上实际上是我昨天对这个问题的调查的总结,只是一个理论。我测试了修复程序1和4,以及使用FaultException。
#2
1
Try clearing the ASP.NET temp files. It's solved some odd issues before for me.
尝试清除ASP.NET临时文件。它之前解决了一些奇怪的问题。
Otherwise, Fusion-logging may shed some light.
否则,Fusion-logging可能会有所启发。
UPDATE: @Charlie - I'm not sure what to make of those logs...it looks like the failed log is from a different AppDomain. Notice the AppBase is set to "file:///c:/windows/system32/inetsrv/" and AppName is w3wp.exe.
更新:@Charlie - 我不确定如何制作这些日志......看起来失败的日志来自不同的AppDomain。请注意,AppBase设置为“file:/// c:/ windows / system32 / inetsrv /”,AppName为w3wp.exe。
I'm pretty sure the Event Viewer should show Application Id: LM/W3SVC/#/ROOT if it was the default AppDomain, too. At this point, all I've got is random guesses.
我非常确定事件查看器应该显示应用程序ID:LM / W3SVC /#/ ROOT,如果它也是默认的AppDomain。在这一点上,我所有的都是随机猜测。
- I notice you're running x64...does MonoTorrent perhaps require x86?
- Have you double checked that the directory is an IIS application, and is configured for the correct version of ASP.NET?
- Is there some other application that uses MonoTorrent on this server? Maybe a WCF service or something? I'm not sure where the Serialization is happening....
- Try hooking the AssemblyResolve event and loading it manually.
- Can you repro on a development machine? If not, maybe it's a borked FX install. Uninstall and reinstall.
- Does restarting, recycling or stopping/starting the AppPool fix the issue temporarily, or cause the issue to appear?
我注意到你正在运行x64 ...... MonoTorrent可能需要x86吗?
您是否仔细检查过该目录是否为IIS应用程序,并且是否配置了正确版本的ASP.NET?
是否有其他应用程序在此服务器上使用MonoTorrent?也许是WCF服务或其他什么?我不确定序列化在哪里发生....
尝试挂钩AssemblyResolve事件并手动加载它。
你可以在开发机器上复制吗?如果没有,也许这是一个borked FX安装。卸载并重新安装。
重新启动,回收或停止/启动AppPool会暂时解决问题,还是会导致问题出现?
You may want to type out your screenshot text too so you'll get some Google love....
您可能也想输入截图文字,这样您就会得到一些Google的爱...
#3
1
Here are some things you can try..
这里有一些你可以尝试的东西..
1.) Flush ASP.Net Temp directory. Restart IIS and recycle Application pool.
1.)刷新ASP.Net Temp目录。重新启动IIS并回收应用程序池。
2.) Make sure your web-application is running in FULL-TRUST if it really needs FULL-TRUST.
2.)如果确实需要FULL-TRUST,请确保您的Web应用程序在FULL-TRUST中运行。
3.) Take the Assembly, try to use it in other asp.net application and run the test application on a seperate server. This might help you diagnose the problem. Also try to run the test asp.net app on the same server but in seperate application pool.
3.)拿大会,尝试在其他asp.net应用程序中使用它,并在单独的服务器上运行测试应用程序。这可能有助于您诊断问题。还尝试在同一服务器上运行测试asp.net应用程序,但在单独的应用程序池中。
4.) Make sure the IIS website of your application is running under the user account with necessary security priviliges. Try running the application under Administratotr as user.
4.)确保您的应用程序的IIS网站在具有必要安全特权的用户帐户下运行。尝试在Administratotr下运行应用程序作为用户。
EDIT-1
5.) Also check if the assembly version is the same as mentioned in web.config. If there's a version mismatch then you can do AssemblyBinding Redirection in web.config.
5.)同时检查程序集版本是否与web.config中提到的相同。如果版本不匹配,则可以在web.config中执行AssemblyBinding重定向。
6.) Also try registaering the Assembly in GAC and see if it loads properly.
6.)同时尝试在GAC中对组件进行注册,看看它是否正确加载。
EDIT-2
7.) Try reconfigring ASP.NET support on the server or maybe framework runtime re-setup may help. This may not be a sure-shot solution but looking at the problem condition we may want to try various solutions.
7.)尝试在服务器上重新配置ASP.NET支持,或者框架运行时重新设置可能会有所帮助。这可能不是一个确定的解决方案,但考虑到问题的情况,我们可能想尝试各种解决方案。
8.) Make sure you're not missing any critical update of your windows server platform.
8.)确保您没有错过任何关于Windows服务器平台的重要更新。
#4
0
I try to give you some ideas - what I do if I was on your position.
我试着给你一些想法 - 如果我在你的位置,我会怎么做。
First of all I take a long look of the MonoTorrent.dll before some days that you make your question, and I look it again today. I found and the function that load the dll. My first opinion is that something have to do with the permissions.
首先,在你提出问题的某些日子之前,我会仔细看看MonoTorrent.dll,今天我再看一遍。我找到了加载dll的函数。我的第一个意见是,某些事情与权限有关。
I hope that you have access to the server - right ?
我希望你能访问服务器 - 对吧?
My first steps is that:
Ensure that your monotorrent.dll actuall have the right permissions to the bin directory, for Read, and execute by your asp.net app. Some times the copy of one dll, did not get the directory permissions buts carriage out his own permissions. To check if your dll have different permissions from the rest, just right click and see Properties | Security, then go to bin directory and do the same, and compare the Security permissions. If they are different then apply again the Directory permissions and make sure that the dll inherited by the directory.
确保您的monotorrent.dll实际拥有对bin目录的正确权限,对于Read,并由您的asp.net应用程序执行。有时一个dll的副本,没有得到目录权限,但运出了自己的权限。要检查您的dll是否具有与其余dll不同的权限,只需右键单击并查看属性|安全性,然后转到bin目录并执行相同操作,并比较安全权限。如果它们不同,则再次应用目录权限并确保目录继承的dll。
My second step
Download the ProcessMonitor from sysinternals
从sysinternals下载ProcessMonitor
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Run ProcessMonitor and try to recreate the error, stop it and analyse to see where and why the dll gets the denied permissions to run. With the ProcessMonitor you can even see if there is any dll that can not found !
运行ProcessMonitor并尝试重新创建错误,停止并分析以查看dll获取拒绝运行权限的位置和原因。使用ProcessMonitor,您甚至可以查看是否有任何无法找到的DLL!
I have check the MonoTorrent dlls and I do not found anything unusual. He have kerner32.dll calls, and use unsafe code to run, ok nothing so special about.
我检查了MonoTorrent dll,但我没有发现任何异常。他有kerner32.dll调用,并使用不安全的代码运行,没有什么特别的。
So if you do that 2 steps and give me some feedback, maybe I can go further. (if not solve by you and what you find)
所以如果你做了两个步骤并给我一些反馈,也许我可以走得更远。 (如果没有你解决,你发现了什么)
#5
0
I would advice to setup Regular maintanence probably once in a week at sunday night etc for following,
我建议在周日晚上等一周内安装常规维护,以便跟进,
- Delete all temporary files
- Delete all ASP.NET IIS temporary files
- Restart Server
删除所有临时文件
删除所有ASP.NET IIS临时文件
Problem is, ASP.NET web apps cause lot of temp files to be left in the disk, because of dynamic compilation of regex, seriliazation assemblies etc, such temp stuff never gets deleted, and more and more junk starts getting collected in temp locations, ASP.NET goes slower and slower, and a point comes in where disk as well as memory defragmentation reaches very high point, things start to fail.
问题是,ASP.NET Web应用程序导致许多临时文件留在磁盘中,因为正则表达式,seriliazation程序集等的动态编译,这样的临时内容永远不会被删除,并且越来越多的垃圾开始被收集到临时位置, ASP.NET变得越来越慢,并且在磁盘和内存碎片整理达到非常高的位置时出现了一个问题,事情开始失败。
No body likes to restart server once a week, but I remember we had no choice, in ASP.NET 1.1 we had stable system after restarting every day, in ASP.NET 2.0 onwards, we are good to have restarting scheduled at once a week.
没有人喜欢每周重启一次服务器,但我记得我们别无选择,在ASP.NET 1.1中我们每天重启后都有稳定的系统,在ASP.NET 2.0以后,我们很高兴每周重启一次。
#6
0
I have found this problem and I have do all of thing as I can, such as clear temp file, restart server, delete and add reference and I also rebuild the solution. However I can't solving this problem. Finally I move my entity class (almost of them need to serialize) to new folder that I have added to the project and then this problem solved.
我发现了这个问题,我尽我所能,比如清除临时文件,重启服务器,删除和添加引用,我也重建了解决方案。但是我无法解决这个问题。最后,我将我的实体类(几乎需要序列化)移动到我已添加到项目中的新文件夹,然后解决了这个问题。
This method is work for me.
这种方法对我有用。
#7
0
Is the server timezone different than your timezone? I've had this issue when deploying resource files, the compile time was in the future so they would fail to load.
服务器时区是否与您的时区不同?我在部署资源文件时遇到了这个问题,编译时间是将来的,因此无法加载。
#8
-2
My guess that you have plenty of open but not closed connections. I mean the connections are not returned to the pool. It looks okay, when you start the application, but after some time there are only several sockets available in the pool and it goes slow. Another thing - non-closed connection may keep DLL in memory, not allowing to release the handler. Try to debug object destruction.
我猜你有很多开放但没有关闭的连接。我的意思是连接不会返回池中。看起来没问题,当你启动应用程序时,但是经过一段时间后,池中只有几个可用的套接字并且速度很慢。另一件事 - 非闭合连接可能会将DLL保留在内存中,而不允许释放处理程序。尝试调试对象销毁。
#9
-2
I know it's simple but I had this problem once and itwas because I had a Web Application project which contains
我知道这很简单,但我曾经遇到过这个问题,因为我有一个包含的Web应用程序项目
References
Folder and I just copied my files into a
文件夹和我刚刚将我的文件复制到了
Bin
folder, in any .net web application in the Project Properties windows, a Reference Path tab is available which by default should nothing be include on it. check this option and also Build tab in Project Properties window which Output path be as the same as bin\
文件夹,在“项目属性”窗口中的任何.net Web应用程序中,“参考路径”选项卡可用,默认情况下不应包含任何内容。选中此选项以及“项目属性”窗口中的“构建”选项卡,其输出路径与bin \相同
#1
3
This can happen in these circumstances:
在这些情况下会发生这种情况:
The ASP.NET app creates a background thread, which throws an uncaught exception. It looks like ASP.NET catches the exception and wants to log it to the Event Log. To do this, it sends this exception from the Web app's app domain to its own app domain (the default one of the w3wp process). This needs a serialization/deserialization of the exception.
ASP.NET应用程序创建一个后台线程,该线程抛出未捕获的异常。看起来ASP.NET捕获异常并希望将其记录到事件日志中。为此,它将此异常从Web应用程序的应用程序域发送到其自己的应用程序域(w3wp进程的默认属性)。这需要异常的序列化/反序列化。
If the exception is a custom one (i.e. defined by the Web app), it cannot be deserialized in the main app domain of ASP.NET because the assembly defining the exception is typically in the Web app's bin directory, not where w3wp.exe is (c:\windows\system32\inetsrv). This causes a serialization exception and w3wp crashes.
如果异常是自定义的(即由Web应用程序定义),则无法在ASP.NET的主应用程序域中反序列化,因为定义异常的程序集通常位于Web应用程序的bin目录中,而不是w3wp.exe所在的位置。 (C:\ Windows \ System32下\ INETSRV)。这会导致序列化异常并导致w3wp崩溃。
There are possible ways to fix the issue (in a - very subjective - order of preference):
有可能解决问题的方法(以非常主观的方式 - 优先顺序):
- Copy the missing DLL in c:\windows\system32\inetsrv
- Install the missing DLL in the GAC
- Remove the cause of the exception (harder to do than to say, as we say in French)
- Catch all exceptions from the background thread yourself and do the logging yourself.
在c:\ windows \ system32 \ inetsrv中复制丢失的DLL
在GAC中安装缺少的DLL
消除异常的原因(比说法语时更难说)
自己从后台线程中捕获所有异常并自行进行日志记录。
Notes:
- If WCF is used and the uncaught exception is FaultException, WCF swallows it and there is no crash
- If the uncaught exception is in the thread of the Web request, there is a yellow screen of death, not this serialization exception
- It really seems like a bug in ASP.NET
- The above is actually a summary of my investigations of this issue yesterday and are only a theory. I tested fixes 1 and 4, as well as using FaultException.
如果使用了WCF并且未捕获的异常是FaultException,则WCF会吞下它并且不会发生崩溃
如果未捕获的异常位于Web请求的线程中,则会出现黄色的死亡屏幕,而不是此序列化异常
这看起来像是ASP.NET中的一个错误
以上实际上是我昨天对这个问题的调查的总结,只是一个理论。我测试了修复程序1和4,以及使用FaultException。
#2
1
Try clearing the ASP.NET temp files. It's solved some odd issues before for me.
尝试清除ASP.NET临时文件。它之前解决了一些奇怪的问题。
Otherwise, Fusion-logging may shed some light.
否则,Fusion-logging可能会有所启发。
UPDATE: @Charlie - I'm not sure what to make of those logs...it looks like the failed log is from a different AppDomain. Notice the AppBase is set to "file:///c:/windows/system32/inetsrv/" and AppName is w3wp.exe.
更新:@Charlie - 我不确定如何制作这些日志......看起来失败的日志来自不同的AppDomain。请注意,AppBase设置为“file:/// c:/ windows / system32 / inetsrv /”,AppName为w3wp.exe。
I'm pretty sure the Event Viewer should show Application Id: LM/W3SVC/#/ROOT if it was the default AppDomain, too. At this point, all I've got is random guesses.
我非常确定事件查看器应该显示应用程序ID:LM / W3SVC /#/ ROOT,如果它也是默认的AppDomain。在这一点上,我所有的都是随机猜测。
- I notice you're running x64...does MonoTorrent perhaps require x86?
- Have you double checked that the directory is an IIS application, and is configured for the correct version of ASP.NET?
- Is there some other application that uses MonoTorrent on this server? Maybe a WCF service or something? I'm not sure where the Serialization is happening....
- Try hooking the AssemblyResolve event and loading it manually.
- Can you repro on a development machine? If not, maybe it's a borked FX install. Uninstall and reinstall.
- Does restarting, recycling or stopping/starting the AppPool fix the issue temporarily, or cause the issue to appear?
我注意到你正在运行x64 ...... MonoTorrent可能需要x86吗?
您是否仔细检查过该目录是否为IIS应用程序,并且是否配置了正确版本的ASP.NET?
是否有其他应用程序在此服务器上使用MonoTorrent?也许是WCF服务或其他什么?我不确定序列化在哪里发生....
尝试挂钩AssemblyResolve事件并手动加载它。
你可以在开发机器上复制吗?如果没有,也许这是一个borked FX安装。卸载并重新安装。
重新启动,回收或停止/启动AppPool会暂时解决问题,还是会导致问题出现?
You may want to type out your screenshot text too so you'll get some Google love....
您可能也想输入截图文字,这样您就会得到一些Google的爱...
#3
1
Here are some things you can try..
这里有一些你可以尝试的东西..
1.) Flush ASP.Net Temp directory. Restart IIS and recycle Application pool.
1.)刷新ASP.Net Temp目录。重新启动IIS并回收应用程序池。
2.) Make sure your web-application is running in FULL-TRUST if it really needs FULL-TRUST.
2.)如果确实需要FULL-TRUST,请确保您的Web应用程序在FULL-TRUST中运行。
3.) Take the Assembly, try to use it in other asp.net application and run the test application on a seperate server. This might help you diagnose the problem. Also try to run the test asp.net app on the same server but in seperate application pool.
3.)拿大会,尝试在其他asp.net应用程序中使用它,并在单独的服务器上运行测试应用程序。这可能有助于您诊断问题。还尝试在同一服务器上运行测试asp.net应用程序,但在单独的应用程序池中。
4.) Make sure the IIS website of your application is running under the user account with necessary security priviliges. Try running the application under Administratotr as user.
4.)确保您的应用程序的IIS网站在具有必要安全特权的用户帐户下运行。尝试在Administratotr下运行应用程序作为用户。
EDIT-1
5.) Also check if the assembly version is the same as mentioned in web.config. If there's a version mismatch then you can do AssemblyBinding Redirection in web.config.
5.)同时检查程序集版本是否与web.config中提到的相同。如果版本不匹配,则可以在web.config中执行AssemblyBinding重定向。
6.) Also try registaering the Assembly in GAC and see if it loads properly.
6.)同时尝试在GAC中对组件进行注册,看看它是否正确加载。
EDIT-2
7.) Try reconfigring ASP.NET support on the server or maybe framework runtime re-setup may help. This may not be a sure-shot solution but looking at the problem condition we may want to try various solutions.
7.)尝试在服务器上重新配置ASP.NET支持,或者框架运行时重新设置可能会有所帮助。这可能不是一个确定的解决方案,但考虑到问题的情况,我们可能想尝试各种解决方案。
8.) Make sure you're not missing any critical update of your windows server platform.
8.)确保您没有错过任何关于Windows服务器平台的重要更新。
#4
0
I try to give you some ideas - what I do if I was on your position.
我试着给你一些想法 - 如果我在你的位置,我会怎么做。
First of all I take a long look of the MonoTorrent.dll before some days that you make your question, and I look it again today. I found and the function that load the dll. My first opinion is that something have to do with the permissions.
首先,在你提出问题的某些日子之前,我会仔细看看MonoTorrent.dll,今天我再看一遍。我找到了加载dll的函数。我的第一个意见是,某些事情与权限有关。
I hope that you have access to the server - right ?
我希望你能访问服务器 - 对吧?
My first steps is that:
Ensure that your monotorrent.dll actuall have the right permissions to the bin directory, for Read, and execute by your asp.net app. Some times the copy of one dll, did not get the directory permissions buts carriage out his own permissions. To check if your dll have different permissions from the rest, just right click and see Properties | Security, then go to bin directory and do the same, and compare the Security permissions. If they are different then apply again the Directory permissions and make sure that the dll inherited by the directory.
确保您的monotorrent.dll实际拥有对bin目录的正确权限,对于Read,并由您的asp.net应用程序执行。有时一个dll的副本,没有得到目录权限,但运出了自己的权限。要检查您的dll是否具有与其余dll不同的权限,只需右键单击并查看属性|安全性,然后转到bin目录并执行相同操作,并比较安全权限。如果它们不同,则再次应用目录权限并确保目录继承的dll。
My second step
Download the ProcessMonitor from sysinternals
从sysinternals下载ProcessMonitor
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Run ProcessMonitor and try to recreate the error, stop it and analyse to see where and why the dll gets the denied permissions to run. With the ProcessMonitor you can even see if there is any dll that can not found !
运行ProcessMonitor并尝试重新创建错误,停止并分析以查看dll获取拒绝运行权限的位置和原因。使用ProcessMonitor,您甚至可以查看是否有任何无法找到的DLL!
I have check the MonoTorrent dlls and I do not found anything unusual. He have kerner32.dll calls, and use unsafe code to run, ok nothing so special about.
我检查了MonoTorrent dll,但我没有发现任何异常。他有kerner32.dll调用,并使用不安全的代码运行,没有什么特别的。
So if you do that 2 steps and give me some feedback, maybe I can go further. (if not solve by you and what you find)
所以如果你做了两个步骤并给我一些反馈,也许我可以走得更远。 (如果没有你解决,你发现了什么)
#5
0
I would advice to setup Regular maintanence probably once in a week at sunday night etc for following,
我建议在周日晚上等一周内安装常规维护,以便跟进,
- Delete all temporary files
- Delete all ASP.NET IIS temporary files
- Restart Server
删除所有临时文件
删除所有ASP.NET IIS临时文件
Problem is, ASP.NET web apps cause lot of temp files to be left in the disk, because of dynamic compilation of regex, seriliazation assemblies etc, such temp stuff never gets deleted, and more and more junk starts getting collected in temp locations, ASP.NET goes slower and slower, and a point comes in where disk as well as memory defragmentation reaches very high point, things start to fail.
问题是,ASP.NET Web应用程序导致许多临时文件留在磁盘中,因为正则表达式,seriliazation程序集等的动态编译,这样的临时内容永远不会被删除,并且越来越多的垃圾开始被收集到临时位置, ASP.NET变得越来越慢,并且在磁盘和内存碎片整理达到非常高的位置时出现了一个问题,事情开始失败。
No body likes to restart server once a week, but I remember we had no choice, in ASP.NET 1.1 we had stable system after restarting every day, in ASP.NET 2.0 onwards, we are good to have restarting scheduled at once a week.
没有人喜欢每周重启一次服务器,但我记得我们别无选择,在ASP.NET 1.1中我们每天重启后都有稳定的系统,在ASP.NET 2.0以后,我们很高兴每周重启一次。
#6
0
I have found this problem and I have do all of thing as I can, such as clear temp file, restart server, delete and add reference and I also rebuild the solution. However I can't solving this problem. Finally I move my entity class (almost of them need to serialize) to new folder that I have added to the project and then this problem solved.
我发现了这个问题,我尽我所能,比如清除临时文件,重启服务器,删除和添加引用,我也重建了解决方案。但是我无法解决这个问题。最后,我将我的实体类(几乎需要序列化)移动到我已添加到项目中的新文件夹,然后解决了这个问题。
This method is work for me.
这种方法对我有用。
#7
0
Is the server timezone different than your timezone? I've had this issue when deploying resource files, the compile time was in the future so they would fail to load.
服务器时区是否与您的时区不同?我在部署资源文件时遇到了这个问题,编译时间是将来的,因此无法加载。
#8
-2
My guess that you have plenty of open but not closed connections. I mean the connections are not returned to the pool. It looks okay, when you start the application, but after some time there are only several sockets available in the pool and it goes slow. Another thing - non-closed connection may keep DLL in memory, not allowing to release the handler. Try to debug object destruction.
我猜你有很多开放但没有关闭的连接。我的意思是连接不会返回池中。看起来没问题,当你启动应用程序时,但是经过一段时间后,池中只有几个可用的套接字并且速度很慢。另一件事 - 非闭合连接可能会将DLL保留在内存中,而不允许释放处理程序。尝试调试对象销毁。
#9
-2
I know it's simple but I had this problem once and itwas because I had a Web Application project which contains
我知道这很简单,但我曾经遇到过这个问题,因为我有一个包含的Web应用程序项目
References
Folder and I just copied my files into a
文件夹和我刚刚将我的文件复制到了
Bin
folder, in any .net web application in the Project Properties windows, a Reference Path tab is available which by default should nothing be include on it. check this option and also Build tab in Project Properties window which Output path be as the same as bin\
文件夹,在“项目属性”窗口中的任何.net Web应用程序中,“参考路径”选项卡可用,默认情况下不应包含任何内容。选中此选项以及“项目属性”窗口中的“构建”选项卡,其输出路径与bin \相同