Exchange HTTP Virtual Server Instance 100 :The IsAlive check for t

[daveberm]

On Jul 2, 11:35 am, jhcumms <jhcu...@gmail.com> wrote:
> On Jun 27, 9:58 am, Dan Sheehan <sheeh...@sheehans.org> wrote:
>
>
>
>
>
> > On Jun 25, 2:59 pm, bob.william...@steeleye.com wrote:
>
> > > Any update on this? Have you identified the issue?- Hide quoted text -
>
> > > - Show quoted text -
>
> > I was able to analyze a perfmon capture of every 10 minutes that
> > covered the time period of when the HTTP virtual server was once again
> > marked offline. The failure occured on 6/21/07 ~11:30pm.
> > So I narrowed the scope down in the permon debug from 6:30PM on
> > 6/21/07 to 1:20AM on 6/22/07.
> > The Free System Page Table Entries never drop below 8400. Here is the
> > MSFT criteria forExchange:
> > -Warning" when the Free System Page Table Entries is less than 8000
> > -Critical" when the Free System Page Table Entries is less than 5,000
>
> > The Paged Pool Bytes were ~92meg the entire time period. Here is the
> > MSFT criteria forExchange:
> > -Warning" when the Pool Paged Bytes counter exceeds 200 MB
> > -Critical" when the Pool Paged Bytes counter exceeds 220 MB
>
> > The Nonpaged Pool Bytes reached up to 107meg, with the average of
> > 99meg. Here is the MSFT criteria forExchange:
> > -Warning" when the Pool Nonpaged Bytes counter exceeds 100 MB
> > -Critical" when the Pool Nonpaged Bytes counter exceeds 110 MB
>
> > It also appears for a period time during the replication the system is
> > potentially paging harder (~350/sec) than after the failure (~25/sec).
> > After 11:45pm that night the Free System PTEs jump up around 9500, the
> > pool page bytes drop to about ~90meg, and the nonpage pool byes is
> > ~77meg.
>
> > So I don't see anything that causes me to believe the system ran out
> > of the vital memory resources. The only one that got close was the
> > Nonpaged Pool Bytes, but it did not cross the "critical" threshold.
>
> > Any other suggestions of what to look for in regards to why the
> > cluster server might think the HTTP virtual server is "offline"?
>
> I'm having the exact same issue.
>
> Any ideas anybody?- Hide quoted text -
>
> - Show quoted text -

Is XOSoft in the mix with you as well?

[jhcumms]

On Jul 2, 1:21 pm, daveberm <david.berming...@steeleye.com> wrote:
> On Jul 2, 11:35 am, jhcumms <jhcu...@gmail.com> wrote:
>
>
>
> > On Jun 27, 9:58 am, Dan Sheehan <sheeh...@sheehans.org> wrote:
>
> > > On Jun 25, 2:59 pm, bob.william...@steeleye.com wrote:
>
> > > > Any update on this? Have you identified the issue?- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > I was able to analyze a perfmon capture of every 10 minutes that
> > > covered the time period of when the HTTP virtual server was once again
> > > marked offline. The failure occured on 6/21/07 ~11:30pm.
> > > So I narrowed the scope down in the permon debug from 6:30PM on
> > > 6/21/07 to 1:20AM on 6/22/07.
> > > The Free System Page Table Entries never drop below 8400. Here is the
> > > MSFT criteria forExchange:
> > > -Warning" when the Free System Page Table Entries is less than 8000
> > > -Critical" when the Free System Page Table Entries is less than 5,000
>
> > > The Paged Pool Bytes were ~92meg the entire time period. Here is the
> > > MSFT criteria forExchange:
> > > -Warning" when the Pool Paged Bytes counter exceeds 200 MB
> > > -Critical" when the Pool Paged Bytes counter exceeds 220 MB
>
> > > The Nonpaged Pool Bytes reached up to 107meg, with the average of
> > > 99meg. Here is the MSFT criteria forExchange:
> > > -Warning" when the Pool Nonpaged Bytes counter exceeds 100 MB
> > > -Critical" when the Pool Nonpaged Bytes counter exceeds 110 MB
>
> > > It also appears for a period time during the replication the system is
> > > potentially paging harder (~350/sec) than after the failure (~25/sec).
> > > After 11:45pm that night the Free System PTEs jump up around 9500, the
> > > pool page bytes drop to about ~90meg, and the nonpage pool byes is
> > > ~77meg.
>
> > > So I don't see anything that causes me to believe the system ran out
> > > of the vital memory resources. The only one that got close was the
> > > Nonpaged Pool Bytes, but it did not cross the "critical" threshold.
>
> > > Any other suggestions of what to look for in regards to why the
> > > cluster server might think the HTTP virtual server is "offline"?
>
> > I'm having the exact same issue.
>
> > Any ideas anybody?- Hide quoted text -
>
> > - Show quoted text -
>
> Is XOSoft in the mix with you as well?

No.

[Dan Sheehan]

On Jul 9, 11:03 am, jhcumms <jhcu...@gmail.com> wrote:
> On Jul 2, 1:21 pm, daveberm <david.berming...@steeleye.com> wrote:
>
> > Is XOSoft in the mix with you as well?
>
> No.- Hide quoted text -
>
> - Show quoted text -

I have sent more Perfmon and Poolmon dumps to MSFT for them to analyze.

[Dan Sheehan]

On Jul 10, 9:52 am, Dan Sheehan <sheeh...@sheehans.org> wrote:
> On Jul 9, 11:03 am, jhcumms <jhcu...@gmail.com> wrote:
>
> > On Jul 2, 1:21 pm, daveberm <david.berming...@steeleye.com> wrote:
>
> > > Is XOSoft in the mix with you as well?
>
> > No.- Hide quoted text -
>
> > - Show quoted text -
>
> I have sent more Perfmon and Poolmon dumps to MSFT for them to analyze.

I accidentally hit send before I was done.
I was also going to note the problem happened again this weekend, this
time with out running the XOSoft software. So this further leads me to
believe there is a resource issue with the cluster, and that the
replication software just brought it to light.
If MSFT finds anything, I will re-post it here.

[jhcumms]

On Jul 10, 7:59 am, Dan Sheehan <sheeh...@sheehans.org> wrote:
> On Jul 10, 9:52 am, Dan Sheehan <sheeh...@sheehans.org> wrote:
>
> > On Jul 9, 11:03 am, jhcumms <jhcu...@gmail.com> wrote:
>
> > > On Jul 2, 1:21 pm, daveberm <david.berming...@steeleye.com> wrote:
>
> > > > Is XOSoft in the mix with you as well?
>
> > > No.- Hide quoted text -
>
> > > - Show quoted text -
>
> > I have sent more Perfmon and Poolmon dumps to MSFT for them to analyze.
>
> I accidentally hit send before I was done.
> I was also going to note the problem happened again this weekend, this
> time with out running the XOSoft software. So this further leads me to
> believe there is aresourceissue with the cluster, and that the
> replication software just brought it to light.
> If MSFT finds anything, I will re-post it here.

Netsh int ip set chimney DISABLED

Try this and let me know if it works for you.

[Dan Sheehan]

On Jul 16, 6:26 pm, jhcumms <jhcu...@gmail.com> wrote:

>
> Netsh int ip set chimney DISABLED
>
> Try this and let me know if it works for you.- Hide quoted text -
>
> - Show quoted text -

What does that do?

BTW MSFT PSS support claims the non-paged pool memory on the server
was used too much, and that's why the Cluster Resource manager marked
the HTTP virtual server offline. The claim the top three culprits were
STORPORT.SYS, EXIFS.SYS, and the Symantec file system antivurs the
customer has installed.
Current plan of action is to upgrade STORPORT.SYS to this version
http://support.microsoft.com/kb/935561, and to update Symantec's
antivirus software to the latest version (I threw out the suggestion
of removing it all together since it is barely scanning anything with
all the file system exclusions for Windows and Exchange).

They said the replication software we were using was not at fault, but
it just asked the system to do more which caused the STORPORT.SYS file
to grab more memory.

I am crossing my fingers.

[bw-judge]

We have exact the same problems they started with W2K3 SP2.
-W2K2 SP2
-Exchange 2003 SP2 Cluster
-IBM x3650 with Broadcom Netxtreme II

This article wil be described the problem in a good way.

http://msexchangeteam.com/archive/20...18/446400.aspx

With the following command the none pageable pool will go stable down to 50-60 MB
Netsh int ip set chimney DISABLED

With this command the following registry entry will change from dword:00000001 to dword:00000000.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"EnableTCPChimney"=dword:00000000

Without reboot all is fine.

But after you restart the servers the connection with rdp and outlook is very slow with VISTA and OUTLOOK 2007.
With Windows XP and Outlook 2003 it looks good.

To update the NIC driver make no difference.