In a production system, it’s likely that you’ll have multiple hosts (and therefore multiple instances of the btsntsvc.exe process) running on a particular server. If one of the btsntsvc processes is performing particularily badly - e.g. hogging all of your CPU - how do you identify the host?
Fire-up Task Manager and identify the PID of the offending process (if you don’t have the PID column, add it by clicking View -> Select Columns). Armed with that information, use the tasklist command to view which Windows Service (i.e. Host) relates to the PID, as follows:
tasklist /svc /fi “imagename eq btsntsvc64.exe
The tasklist command will list the processes matching the query string, their PID and service name (something similar to the screenshot below). With your PID from the Task Manager, making the correlation between process and Host is straightforward.
Note that in the tasklist example above, I’m specifically searching for 64-bit processes - if you’re working on a 32-bit system (or you’re search for 32-bit processes on a 64-bit system), your search string will just be ‘btsntsvc.exe’. My Thanks to Francois Malgreve who originally helped me with this problem.
My colleague Mike Stephenson has just posted details of the next UK BizTalk User Group meeting to be held at the Edenbrook offices in London on the 12th September 2007.
I’ve missed the previous UK meetings so I’m looking forward to meeting the UK community, it’s also great that my employer is hosting the event!
I’m undertaking performance testing with a client today and was broadsided by an
Imagine a scenario where you want to create 1400 receive locations; to make life simpler, you’d probably want to use WMI or the BizTalk Explorer OM.
Not much of an issue there, however what happens when you try an run some custom C# code that creates the receive locations (and therefore references the Microsoft.BizTalk.ExplorerOM assembly) from within an orchestration [expression shape] that executes as a 64-bit process?
You get the following error XLANG/S error:
Event Type: Error
Event Source: XLANG/s
Event Category: None
Event ID: 10034
Date: 14/08/2007
Time: 19:22:49
User: N/A
Computer: WINBT01
Description:
Uncaught exception (see the ‘inner exception’ below) has suspended an instance of service ‘Demo.Integration.CustomerLink.Orchestrations.UserAdministration(108ace24-3b9d-e084-c9ea-f342878676e6)’.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 95ae9c6b-9af4-468b-9a3c-6398d7fba629
Shape name: CreateFileReceiveLocationExpression
ShapeId: 3695bc5d-cec3-4c9b-b2ca-84e0917a7bc1
Exception thrown from: segment 1, progress 22
Inner exception: Explorer OM is not supported in a 64bit process.Exception type: BtsException
Source: Microsoft.BizTalk.ExplorerOM
Target Site: Void .ctor()
The following is a stack trace that identifies the location where the exception occuredat Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer..ctor()
at Demo.Integration.CustomerLink.FileReceiveLocation.Create(String user)
at Demo.Integration.CustomerLink.Orchestrations.UserAdministration.segment1(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)
Hmmm, that’s a bit odd, especially given that both the custom and Explorer OM assemblies are compiled to MSIL (not a target platform), which should suggest that when invoked from the 64-bit orchestration the JIT-Compiler will compile both to run a 64-bit process:
A colleague of mine is running into an issue with a large number of receive locations on a single port and I would appreciate some community advice on how to resolve the issue.
He is running approx. 1400 file Receive Locations on a single Receive Port and after starting all of the locations, they slowly start to disable themselves with the following error message in the Event Log (note, the share isn’t actually called ’sharename’ in the environment):
The receive location “33183-FTP Receive Location” with URL “\\sharename\FTP\33183\IN\*.*” is shutting down. Details:”The FILE receive location \\sharename\FTP\33183\IN\*.* exhausted the network retry attempts.”.
For reference, the BizTalk environment is based on 2 servers participating in a group (Enterprise Edition), with the 1400 receive locations using a single Host (one Host Instance per server). The receive locations are polling a Windows SMB share hosted on a separate system; the authentication credentials are confirmed as being correct.
We have increased the maximum number of NetBIOS connections from the default of 50 to 2000 (well within the limit of 65,000) after readingthis blog entry and KB article 810886. We have also turned the file Receive Location polling off as per Rasmus Kristensen newsgroup entry.
Unfortunately, I’ve yet to take a look at the environment, but my initial thoughts are:
- The host instances are exhausting their available threads / memory - creating additional Hosts and moving the Receive Locations out to multiple Receive Ports may stop this problem.
- There are still NetBIOS connection issues - the ‘exhausted the network retry attempts’ seems to imply that this may be the case.
- Are we exceeding the maximum number of usable Receive Locations per Receive Port? Does anyone know how many locations a port can contain?
I’ll be traveling to the client early site next week to investigate (I imagine that PerfMon and I will become close friends), however in the meantime it would be good to get any advice from the community - have I missed anything obvious here??
Any comments or suggestions are greatly welcomed.
Nick.
No comments:
Post a Comment