如何解决IIS单页应用中的内存泄漏

发布于 2025-02-06 15:25:21 字数 1099 浏览 4 评论 0原文

我有一个较旧的.NET Framework 4.5.2单页应用程序(SPA),该应用程序已经运行了大约5年而没有内存问题。

然后大约1个月前,它开始展示记忆泄漏。没有重大的代码更改(在客户端中进行了较小的调整,但没有任何会导致内存泄漏的情况)。

该应用程序大约有100个并发用户。典型的内存使用率稳定在约1.5次。当触发泄漏时,内存使用量将在大约两分钟的过程中迅速上升至2个演出,此时Apppool回收以重新宣布内存。原始应用程序池终止大约需要5分钟。在此期间,记忆使用量将在终止之前达到8个演出。

最终用户不受此影响。

然后,新的Apppool工人将在几分钟内遵循相同的高达8个演出的模式。这将持续约15分钟,此时,该问题在一天的其余时间消失了。但是第二天,它将回来。

没有明显的解释说明为什么会发生这种情况。测试无法重现该问题。

该应用程序是订单条目应用程序,该应用程序访问另一台服务器上的SQL Server数据库。进行了一些存储的过程更改,但是如果其中一个是问题的原因,在我看来,内存问题会发生在SQL Server主机机器上,而不是IIS上。

我已经尝试进行调试所做的事情:

  1. 我在触发时浏览了IIS日志。看不到异常活动。

  2. 我捕获了一个内存转储,我尝试使用 windbg ,但我无法从中获取任何数据。

  3. 我已经检查了IIS主机的事件日志,并且没有例外或警告。

  4. SQL Server是否存在任何问题,但没有发现任何异常活动。

  5. 尝试将应用程序移至其他IIS服务器,但是那里的问题是相同的。

关于如何追踪此问题的任何建议将不胜感激。

我唯一尚未尝试过的是更新库。自撰写该应用程序以来,已经有很多更新,但是我不愿意在没有明确的理由进行更新,而过去曾被此更新。

必须如此迅速地吞噬了很多东西。

I have an older .net Framework 4.5.2 Single Page App (SPA) that has been running with no memory issues for about 5 years.

Then about 1 month ago, it started exhibiting a memory leak. There were no major code changes (minor tweaks are done in the client, but nothing that would cause a memory leak).

The app has about 100 concurrent users. The typical memory usage is stable at about 1.5 gigs. When the leak is triggered, the memory usage will rapidly rise over the course of about two minutes to over 2 gigs at which point the AppPool recycles to re-claim the memory. It takes about 5 minutes for the original app pool to terminate. During that time, the memory usage will reach about 8 gigs before terminating.

The end users are not affected by this.

The new AppPool worker will then follow the same pattern of rising up to 8 gigs in a couple of minutes. This will continue for about 15 minutes at which point the issue disappears for the rest of the day. But the next day, it will be back.

There is no obvious explanation for why this is occurring. Testing cannot reproduce the issue.

The app is an order entry app which access a SQL Server database on another server. There were some Stored Procedure changes made, but if one of those were the cause of the issue, it seems to me that the memory issue would happen on the Sql Server host machine, not IIS.

What I have done to try to debug:

  1. I have looked through the IIS logs at the time it is triggered. No unusual activity is seen.

  2. I captured a memory dump, and I tried to view the memory using WinDbg But I was unable to get any data out of it.

  3. I have checked the event log of the IIS Host and there are no exceptions or warnings being generated.

  4. SQL Server is checked for any issues, but none found with no unusual activity.

  5. Tried moving the App to a different IIS Server, but the problem was the same there.

Any advice on how to track down this problem would be appreciated.

The only thing I have not tried yet is updating the libraries. There have been many updates since the app was written, but I am hesitant to update without a clear reason, having been bitten by this in the past.

There has to be something which is eating up so much memory so quickly.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文