|
HP OpenVMS Systemsask the wizard |
|
The Question is:
We run an Alpha server 4100 with 4 processors and 3GB of memory serving to
the web using OSU web server.
Occasionally and for seemingly no reason the server will "run away". In
essence what happens is the number of processes goes through the ceiling
from around hundred under normal use to as high as 900 and more quickly
(within seconds).
Of course we can easily see which processes "belong" to the Web server and
are set up to quickly kill them.
The problem is this: often these processes will not die and one of two
things will happen to them:
Either
1) they report a LEF state with very little CPU time as in
00002DF1 TASK_14550000 LEF 4 0 0 00:00:00.01
they will stay in this state forever (or at least until the machine is
rebooted) and never show furthur CPU usage etc. Show proc reveals the
following
23-JUN-1999 17:04:39.78 User: DNA$SessCtrl Process ID: 000029C8
Node: IO Process name:
"TASK_145400C3"
Terminal:
User Identifier: [0,403]
Base priority: 4
Default file spec: Not available
Number of Kthreads: 1
Showing the user as dna@sessctrl which is why they do not die when we look
for those owned by user http_server
when I use the /cont switch I see that these processes are using the
executable loginout.exe
These processes respond to a stop proc by becoming com bound and then going
into the second scenario below...
Or
2) they will go to RWAST state and show proc will report the process is
suspended, however set proc /nosuspend does nothing Stop proc reports the
process can not be stopped since it is suspended.
These processes eat up CPU time etc and certainly cause a slowdown in the
system. More than about five in this state seems to be fatal to system
performance.
Other factors
loginout.exe has not changes since 1996
I hope you can shed some light on this so I can work towards resolving it.
Thanks
I hope you can help
The Answer is : Please confirm you are running the current version of the web server, and please check with the folks on the OSU web server email list (to join, send email to VMS-WEB-daemon-Request@KJSL.COM) for assistance with locating and resolving this problem.
|