Here is an example where the background worker reaches the 8192 limit and waits. 3 sessions complete replay activities and the background worker prepares 3 new sessions and again reaches the 8192 limit. The messages are showing forward progress and that the “read ahead” limit has been reached. The background worker limits the queue size and waits to avoid encountering potential memory, resource limitations.
|2013-07-05 19:00:16:255 CRITICAL [Client Replay] Active connections exceed 8192, connection 8467 is waiting.|
|2013-07-05 19:00:16:255 INFORMATION [Client Replay] All events for spid=298 have been replayed|
|2013-07-05 19:00:16:255 INFORMATION [Client Replay] All events for spid=362 have been replayed|
|2013-07-05 19:00:16:255 INFORMATION [Client Replay] All events for spid=293 have been replayed|
|2013-07-05 19:00:16:255 CRITICAL [Client Replay] Active connections exceed 8192, connection 8470 is waiting|
I would also point out that the ‘connection #### is waiting’ is a nice progress indicator. The DReplay log previously shows the number of dispatched connections. 2013-07-05 18:59:47:956 OPERATIONAL [Client Replay] 35212 events are dispatched in 8800 connections. From the messages above you can see DReplay has prepared sessions up to 8469 of the 8800 total to be replayed.
One reproduction of the message was the 100 concurrent make/break connections, each repeating 160 times for a total of 16000 total sessions. DReplay sees these as 16000 unique sessions and sequences them accordingly. In doing this DReplay will queue 8192 sessions wait for sessions to complete, add a few more and repeat the logic. The message in this case is simply showing you have more then 8192 connect/disconnect boundaries (unique sessions) and DReplay has reached the prepared depth limit.
Bob Dorr - Principal SQL Server Escalation Engineer
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.