There’s a new MSMQ KnowledgeBase article out trying to compete for the “longest title award”:
940960 Error message when you run multiple instances of Message Queuing 3.0 in a Windows Server 2003-based cluster: “There are insufficient resources to perform this operation”
The article is VERY light on explanation so here’s some background information which I’ve also added to my “Insufficient Resources” blog, the one-stop-shop for your troubleshooting needs, as item 11 (Clustering too many MSMQ resources):
It is important to ensure that all the clustered MSMQ resources have adequate kernel memory address space for mapping messages. Each resource has its own instance of the Message Queuing driver (Mqac.sys) which maps files to a 4MB range of the System View Space memory pool (desktop heap for drivers). As the default pool size is 16MB, this allows for 3 MSMQ services (3x4MB=12MB) and 4MB left over for other (non-MSMQ) device drivers – this 4MB remainder may not be enough. Even worse, running a fourth service would mean MSMQ would try and allocate itself all of the memory pool, leaving none for other services to make use of. The results of this are, obviously, unpredictable and you may see “Insufficient Resources” reported.
Note – the local unclustered MSMQ service will also count against this limit if it is running.
To raise the limit, modify the SystemViewSize registry value (not to be confused with SessionViewSize). The value should be set as follows:
SystemViewSize = 16 + (total number of Message Queuing resources x 4)
SystemViewSize is documented here:
Message Queuing in server clusters
“Memory management for Message Queuing resources in clusters”
Other Reference material:
MSMQ FAQ document
“3.5 Why is there a 4-MB message size limitation?”
Deploying Message Queuing (MSMQ) 3.0 in a Server Cluster
Q. Are there any limitations for multiple MSMQ resources in a server cluster?
[[17th October 2007 – Thanks to Takuya Hirai for the following memory dump analysis]]
If you want to determine if the System View Space is large enough the take a kernel memory dump and have a look.
0: kd> dd nt!MmSystemViewSize l1
16,777,216, or 16Mbytes, is the default value
0: kd> x nt!MmSession
808af660 nt!MmSession = struct _MMSESSION
0: kd> dt _MMSESSION 808af660
+0x000 SystemSpaceViewLock : _KGUARDED_MUTEX
+0x020 SystemSpaceViewLockPointer : 0x808af660 _KGUARDED_MUTEX
+0x024 SystemSpaceViewStart : 0xbb000000 “H???”
+0x028 SystemSpaceViewTable : 0x8a95e6a0 _MMVIEW
+0x02c SystemSpaceHashSize : 0x3e
+0x030 SystemSpaceHashEntries : 0x13
+0x034 SystemSpaceHashKey : 0x3d
+0x038 BitmapFailures : 0x19
+0x03c SystemSpaceBitMap : 0x8afddce0 _RTL_BITMAP
The bitmap for the System Space starts at 0x8afddce0
0: kd> dt _RTL_BITMAP 0x8afddce0
+0x000 SizeOfBitMap : 0x100
+0x004 Buffer : 0x8afddce8 -> 0xffffffff
The bitmap is 256 bit in size; each bit maps to a 64byte block; 256*64K = 16Mbytes
The bitmap buffer starts at address 0x8afddce8.
0: kd> dd 0x8afddce8
8afddce8 ffffffff ffffffff ffffffff ffffffff
8afddcf8 ffffffff ffffffff 00000003 00000000
8afddd08 0a0a0006 6d446d4d 00000000 0001008b
8afddd18 822a93a0 8223ea20 81e1c278 818ec820
8afddd28 818ec838 818ec850 818ec868 818ec880
8afddd38 818ec898 818ec8b0 818ec8c8 818ec8e0
8afddd48 818ec8f8 818ec910 818ec928 818ec940
8afddd58 0a0a000a 6d446d4d 8afddc68 0001000a
All of the first 128 bits are in set.
67 of the second 128 bits are in set.
So over 12MB of the 16MB System View Size is in use which may result in “Insufficient Resources” errors being raised.