Long time to stop 64 bit host instances

[Trying To Forget]

We use 6 GB dual core BizTalk 2006 R2 servers with eight 64-bit host instances and two 32-bit host instances. The 32-bit host instances stop after a couple of seconds but the 64-bit host instances usually take 60 seconds each to stop even if they are not connected to any adapter nor orchestration. When a 64-bit host instance is stopping it will use 50% of the CPU.

 

If I stop 5 64-bit host instances from the Administration Console it will stop one at a time and it will take 300 seconds.

 

2 of the 64-bit host instances are clustered using MSCS. Unfortunately we don't have any non-clustered 64 bit servers so I cannot tell if this problem is due to the clustering.

 

Can we do something to lessen the time it takes to stop the 64-bit host instances?

 

Thanks,

Erik

 

[WenJun Zhang[msft]]

Hi Erik,

To deeply troubleshoot this kind of slow performance symptom, we need to
capture memory dump files of the 64bit host instance's process during
closure and debug into them to see what the root cause is. However it's not
possible to perform this kind of complicated debugging scenario in the
newsgroup.

I'd like to suggest you use one of your MSDN Technical Support Incidents to
work with us via telephone based support. This will be the most effective
way to assist you on complicated and project based issue. Also you won't
even need to spend the incident account if the problem is finally confirmed
to be a product issue or can be simply fixed by applying hotfix. Please
refer to the support note below.

About the information of free incident support for MSDN subscribers, please
look at:
http://msdn.microsoft.com/subscriptions/support/default.aspx.

To obtain the phone numbers for Microsoft Customer Service and Support
services technology request, please take a look at the web site listed
below.
http://support.microsoft.com/default.aspx?scid=fh;EN-US;PHONENUMBERS

Thanks.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Trying To Forget]

Ok. I will make a PSS case.

Thank you,
Erik

""WenJun Zhang[msft]"" <wjz...@online.microsoft.com> wrote in message
news:XMruy0zj...@TK2MSFTNGHUB02.phx.gbl...

[zutroy...@gmail.com]

We are experiencing an identical issue on our new hardware. 3 blades
(2.5GHz proc, 8GB RAM each) running BTS 2006 R2 64-bit. No
applications are deployed, therefore no activity in BizTalk.

Stop of 32-bit host instance takes ~ 3 seconds.

Stop of 64-bit host instance takes > 60 seconds.

With 20 host instances across these servers, a full recycle takes over
20 minutes. None of our host instances are clustered, so I can attest
that it does not appear to be an issue with the clustering.

In addition, with each host stop, there are two Service Control
Manager error 7011s thrown to the System Event log. The first one has
the following text

Timeout (30000 milliseconds) waiting for a transaction response from
the BTSSvc$BizTalkServerApplicationFILEHost service.

And the subsequent error has the following text 30 seconds later:

Timeout (30000 milliseconds) waiting for a transaction response from
the service.

These errors occur for each 64-bit host instance on each server, each
time.

I will be opening a support ticket with MS too. We don't want to
migrate our current production environment to a new environment which
is exhibiting health issues.

Ben

On Mar 26, 3:49 pm, "Trying To Forget"

<TryingToFor...@newsgroup.nospam> wrote:
> Ok. I will make a PSS case.
>
> Thank you,
> Erik
>

> ""WenJun Zhang[msft]"" <wjzh...@online.microsoft.com> wrote in message

> >http://msdn.microsoft.com/subscriptions/managednewsgroups/default.asp...

> > ications.
>
> > Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> > where an initial response from the community or a Microsoft Support
> > Engineer within 1 business day is acceptable. Please note that each follow
> > up response may take approximately 2 business days as the support
> > professional working with you may need further investigation to reach the
> > most efficient resolution. The offering is not appropriate for situations
> > that require urgent, real-time or phone-based interactions or complex
> > project analysis and dump analysis issues. Issues of this nature are best
> > handled working with a dedicated Microsoft Support Engineer by contacting
> > Microsoft Customer Support Services (CSS) at
> >http://msdn.microsoft.com/subscriptions/support/default.aspx.
> > ==================================================
> > This posting is provided "AS IS" with no warranties, and confers no

> > rights.- Hide quoted text -
>
> - Show quoted text -

[Ben]

After getting support from PSS, we determined the cause of this
issue. There is another KB out there (which at the moment indicates
it is not for 2006 R2) which addresses CPU spikes that occur after
applying Security Bulletin MS07-040. The KB article is here:

http://support.microsoft.com/?id=943165

Since the machines were newly built and fully up-to-date, the security
bulletin (though not installed independently) was on the machine. The
details of the security bulletin can be found here:

http://support.microsoft.com/?id=943165

After applying the fix to all three servers, the long stop effect and
service timeouts disappeared. Stopping the 20 host instances now
takes ~1.5 minutes as opposed to the 20 minutes accompanied by system
event log errors.

To solve the problem, you will still need to open a ticket with
Microsoft so they can give you the fix for 943165, as it is not freely
available for download. This problem will likely creep up more and
more as existing applications are migrated to BizTalk R2 64-bit, as
well as new development.

Ben

[Trying To Forget]

Thanks a lot Ben!

This really helped us. We were able to download the hotfix from the Premier
Customer Area so we didn't need to start a PSS case :)

And the hotfix makes an enormous change :)

Best regards,
Erik

"Ben" <zutroy...@gmail.com> wrote in message
news:a2d736d5-de69-4da2...@u10g2000prn.googlegroups.com...

[marcusq71]

I only see an x86 version of this hotfix. Is this what you used on your x64
machines or did you need to request a different version from PS? Thank you
in advance for your help.