Trouble Shooting IIS

[AJ]

Hello,

We have a NT4.0 box with SP5 installed.

Every day at one point inet???.exe file causes the Processor to go to 100%.

We have to shutdown the server and restart it to get it going.

Problem is, there is no errors in Event Viewer etc.

How do we find out where the problem is coming from? We have multiple domains hosted on this box. What if someone has a bad script, how do we find out?

Please someone help me here..

Thanks
AJ

[Chris Wolney]

No solutions here, I came to this message board to post the same problem and would appreciate any feedback as well. You may also want to try some of these troubleshooting steps to see if we're experiencing the same challenge.
I'm running IIS4 on NT4 with SP5 on a 450Mhz HP Netserver LC3, 256MB of RAM, and 18GB of disk on hardware RAID-5 (NetRAID controller).

We also have an intermittent problem with the processor pegging at 100%, which is apparently when executing ASP scripts.

First, I monitored the network throughput, processor utilization, processsor queue length, available physical memory, page file usage, interrupts/sec, and disk throughput to see if a memory, disk or processor bottleneck could be causing this. There are no indications of a lack of physical memory, execessive disk or network throughput. When the processor hits 100%, it will usually stay there until I stop and start the w3svc-- and the processor queue length gets up into the 9's, which is pretty bad (a single processor machine shouldn't get this up over two according to TechNet).

So, I looked into what was monopolizing the processor. I opened up another perfmon to examine each thread running. Of course, it is between 1 and 4 inetinfo threads wreaking havoc on the processor. During this time, I get numerous complaints from users about ASP code executing very slow. While the high processor utilization is going on, "standard" HTML with graphics fly up on the browser speedily.

I then watched the processor utilization like a hawk at my workstation. When it would peg at 100%, I would quickly grab the last log entries to see if it was one particular ASP application. It is not; we have many ASP applications reading from various Access databases on a remote server via ODBC that are accessed before inetinfo goes down in flames.

This has been happening frequently for us as well, and being a webmaster and not an ASP developer I'm not sure what else to try as I can't analyze the code for errors. When checking the inetinfo threads during 100% utilization, I can get the process ID, but I have no idea if it is from the ASP interpreter, ISAPI, the Index Server, or any of the many components that run in the inetinfo service.

Any additional troubleshooting ideas would be appreciated, especially if anyone knows of a tool I can use to determine what the process ID of the inetinfo thread is doing. I suspect it is ASP, but for right now our only solution is to start and stop the w3svc... Sometimes it clears up the problem for hours, sometimes for only minutes or seconds-- this entire morning was a nightmare with the server spiking at 100% utilization within seconds of me restarting the w3svc!

TIA, any and all suggestions are appreciated!

------------
AJ at 2/22/00 9:38:43 AM

Hello,

We have a NT4.0 box with SP5 installed.

Every day at one point inet???.exe file causes the Processor to go to 100%.

We have to shutdown the server and restart it to get it going.

Problem is, there is no errors in Event Viewer etc.

How do we find out where the problem is coming from? We have multiple domains hosted on this box. What if someone has a bad script, how do we find out?

Please someone help me here..

Thanks
AJ

Hello Chris,

The problem we found was the access to ODBC was causing the problem..

We updated MDAC to latest 2.5.. We have not had the problem since..

This may help

AJ


------------
Chris Wolney at 2/29/00 3:56:15 PM

No solutions here, I came to this message board to post the same problem and would appreciate any feedback as well. You may also want to try some of these troubleshooting steps to see if we're experiencing the same challenge.
I'm running IIS4 on NT4 with SP5 on a 450Mhz HP Netserver LC3, 256MB of RAM, and 18GB of disk on hardware RAID-5 (NetRAID controller).

We also have an intermittent problem with the processor pegging at 100%, which is apparently when executing ASP scripts.

First, I monitored the network throughput, processor utilization, processsor queue length, available physical memory, page file usage, interrupts/sec, and disk throughput to see if a memory, disk or processor bottleneck could be causing this. There are no indications of a lack of physical memory, execessive disk or network throughput. When the processor hits 100%, it will usually stay there until I stop and start the w3svc-- and the processor queue length gets up into the 9's, which is pretty bad (a single processor machine shouldn't get this up over two according to TechNet).

So, I looked into what was monopolizing the processor. I opened up another perfmon to examine each thread running. Of course, it is between 1 and 4 inetinfo threads wreaking havoc on the processor. During this time, I get numerous complaints from users about ASP code executing very slow. While the high processor utilization is going on, "standard" HTML with graphics fly up on the browser speedily.

I then watched the processor utilization like a hawk at my workstation. When it would peg at 100%, I would quickly grab the last log entries to see if it was one particular ASP application. It is not; we have many ASP applications reading from various Access databases on a remote server via ODBC that are accessed before inetinfo goes down in flames.

This has been happening frequently for us as well, and being a webmaster and not an ASP developer I'm not sure what else to try as I can't analyze the code for errors. When checking the inetinfo threads during 100% utilization, I can get the process ID, but I have no idea if it is from the ASP interpreter, ISAPI, the Index Server, or any of the many components that run in the inetinfo service.

Any additional troubleshooting ideas would be appreciated, especially if anyone knows of a tool I can use to determine what the process ID of the inetinfo thread is doing. I suspect it is ASP, but for right now our only solution is to start and stop the w3svc... Sometimes it clears up the problem for hours, sometimes for only minutes or seconds-- this entire morning was a nightmare with the server spiking at 100% utilization within seconds of me restarting the w3svc!

TIA, any and all suggestions are appreciated!

------------
AJ at 2/22/00 9:38:43 AM

Hello,

We have a NT4.0 box with SP5 installed.

Every day at one point inet???.exe file causes the Processor to go to 100%.

We have to shutdown the server and restart it to get it going.

Problem is, there is no errors in Event Viewer etc.

How do we find out where the problem is coming from? We have multiple domains hosted on this box. What if someone has a bad script, how do we find out?

Please someone help me here..

Thanks
AJ

Thanks for the note! I installed that this morning after a quick trip to the Microsoft ODBC site-- haven't seen the problem yet, but I will keep my eye on it.

-Chris

------------
at 2/29/00 3:59:57 PM

Hello Chris,

The problem we found was the access to ODBC was causing the problem..

We updated MDAC to latest 2.5.. We have not had the problem since..

This may help

AJ


------------
Chris Wolney at 2/29/00 3:56:15 PM

No solutions here, I came to this message board to post the same problem and would appreciate any feedback as well. You may also want to try some of these troubleshooting steps to see if we're experiencing the same challenge.
I'm running IIS4 on NT4 with SP5 on a 450Mhz HP Netserver LC3, 256MB of RAM, and 18GB of disk on hardware RAID-5 (NetRAID controller).

We also have an intermittent problem with the processor pegging at 100%, which is apparently when executing ASP scripts.

First, I monitored the network throughput, processor utilization, processsor queue length, available physical memory, page file usage, interrupts/sec, and disk throughput to see if a memory, disk or processor bottleneck could be causing this. There are no indications of a lack of physical memory, execessive disk or network throughput. When the processor hits 100%, it will usually stay there until I stop and start the w3svc-- and the processor queue length gets up into the 9's, which is pretty bad (a single processor machine shouldn't get this up over two according to TechNet).

So, I looked into what was monopolizing the processor. I opened up another perfmon to examine each thread running. Of course, it is between 1 and 4 inetinfo threads wreaking havoc on the processor. During this time, I get numerous complaints from users about ASP code executing very slow. While the high processor utilization is going on, "standard" HTML with graphics fly up on the browser speedily.

I then watched the processor utilization like a hawk at my workstation. When it would peg at 100%, I would quickly grab the last log entries to see if it was one particular ASP application. It is not; we have many ASP applications reading from various Access databases on a remote server via ODBC that are accessed before inetinfo goes down in flames.

This has been happening frequently for us as well, and being a webmaster and not an ASP developer I'm not sure what else to try as I can't analyze the code for errors. When checking the inetinfo threads during 100% utilization, I can get the process ID, but I have no idea if it is from the ASP interpreter, ISAPI, the Index Server, or any of the many components that run in the inetinfo service.

Any additional troubleshooting ideas would be appreciated, especially if anyone knows of a tool I can use to determine what the process ID of the inetinfo thread is doing. I suspect it is ASP, but for right now our only solution is to start and stop the w3svc... Sometimes it clears up the problem for hours, sometimes for only minutes or seconds-- this entire morning was a nightmare with the server spiking at 100% utilization within seconds of me restarting the w3svc!

TIA, any and all suggestions are appreciated!

------------
AJ at 2/22/00 9:38:43 AM

Hello,

We have a NT4.0 box with SP5 installed.

Every day at one point inet???.exe file causes the Processor to go to 100%.

We have to shutdown the server and restart it to get it going.

Problem is, there is no errors in Event Viewer etc.

How do we find out where the problem is coming from? We have multiple domains hosted on this box. What if someone has a bad script, how do we find out?

Please someone help me here..

Thanks
AJ

[Raman]

Hi,

Did you try installing the Service Pack 6a?

Raman


------------
AJ at 2/22/00 9:38:43 AM

Hello,

We have a NT4.0 box with SP5 installed.

Every day at one point inet???.exe file causes the Processor to go to 100%.

We have to shutdown the server and restart it to get it going.

Problem is, there is no errors in Event Viewer etc.

How do we find out where the problem is coming from? We have multiple domains hosted on this box. What if someone has a bad script, how do we find out?

Please someone help me here..

Thanks
AJ

[Raman]

Hi,

Did you try installing the Service Pack 6a?

Raman


------------
AJ at 2/22/00 9:38:43 AM

Hello,

We have a NT4.0 box with SP5 installed.

Every day at one point inet???.exe file causes the Processor to go to 100%.

We have to shutdown the server and restart it to get it going.

Problem is, there is no errors in Event Viewer etc.

How do we find out where the problem is coming from? We have multiple domains hosted on this box. What if someone has a bad script, how do we find out?

Please someone help me here..

Thanks
AJ

[Caroline Smith]

Hi,

I agree, when we saw this problem it was in accompanied by SQL connectivity errors. We haven't seen the problem again since standardizing our MDAC versions on our web and transaction servers.

Caroline

------------
at 2/29/00 3:59:57 PM

Hello Chris,

The problem we found was the access to ODBC was causing the problem..

We updated MDAC to latest 2.5.. We have not had the problem since..

This may help

AJ