4

我有一个 asp.net mvc4 web api 接口，每天收到大约 54k 个请求。

http://myserv.x.com/api/123/getstuff?whatstuff=thisstuff

我在负载均衡器后面有 3 个 Web 服务器，它们设置为处理 http 请求。

平均响应时间约为 300 毫秒。但是，最近出现了问题（或者可能一直存在），因为响应时间在 10-20 秒内返回的零星行为。这将是针对直接访问同一服务器而不是通过负载均衡器的相同请求。

GIVEN:
- System has been passed down to me so there may be gaps with IIS confiuration, etc,.
- Database: SQL Server 2008R2
- Web Servers: Windows Server 2008R2 Enterprise SP1
- IIS 7.5
- Using MemoryCache aggressively with Model and Business Objects with eviction set to 2hrs
- Looked at the logs but really don't see anything significantly relevant
- One application pool...no other LOB applications running on this server

假设和提问：不知何故，我认为某些东西正在回收应用程序池或 IIS 工作线程正在关闭并重新启动，从而导致每个新请求都进行预热和重新缓存。它是如此零星，以至于现在很难解决问题。对同一服务器的相同请求按预期快速返回（背靠背 N 个请求），因为它在大约 300 毫秒内被缓存......但等待大约 5-10-20 分钟，对同一服务器的相同请求需要 16 秒。

由于这些是生产系统，因此我只能进行有限的跟踪，因此我只能公开这么多的日志记录详细信息。任何攻击此或其他人遇到的类似行为的帮助和信息都将受到赞赏。谢谢

更新： w3wpe.exe 进程增长到 ~3G。不知何故，它被消灭了，PID 改变了，所以它本身或某些东西每 3-4 分钟就会杀死它我在我的网络服务器（IIS）日志中看到大量警告：

为应用程序池“MyApplication”提供服务的进程与 Windows 进程激活服务发生了致命的通信错误。进程 ID 为“1732”。数据字段包含错误号。

4

1 回答 1

4

经过 4-5 天的 IIS 和配置与内部代码问题评估后，我终于发现了这个问题，而使用 windbg 或 debugdiag IIS 工具几乎没有帮助。即使使用小型转储或日志跟踪堆栈，这些工具也包含如此多的信息，以至于它们可能是红鲱鱼。最好的办法是通过设置生产系统的“智能复制”实例来重现它，我们当时没有这个实例，并且需要一些操作来设置一些东西。

不用说，问题与过度缓存业务对象有关。有一个竞争条件，其中某个表上的更新正在更新相应业务对象的属性（更新来自多个服务器），这导致 OOC stackoverflow 几乎导致缓存递归地将自身缓存到死，从而导致 w3wp .exe 进程死亡并伪回收自身。这是在非生产环境中极难测试和重现的边缘案例之一。

于 2013-03-01T05:10:03.677 回答