| ??: |
"Massimo S." <ecs-isp@2rosenthals.com> |
?????? ?????????
?????????????? ????????? |
| ????: |
Re: [eCS-ISP] apache+php and VA limit |
| ????: |
Tue, 26 Dec 2023 14:01:23 +0100 |
| ????: |
eCS ISP Mailing List <ecs-isp@2rosenthals.com> |
|
|---|
Il 02/12/2023 16:42, Steven Levine ha scritto:
In <list-8670041@2rosenthals.com>, on 12/02/23
at 10:29 AM, "Massimo S." <ecs-isp@2rosenthals.com> said:
Hi Massimo,
the reboot, manual or scheduled
first close all applications than do a setboot /b
but in the rare case that the webserver "runs out of something" it freeze
with the banner system is rebooting on the screen
In case you are not already doing them, there are a couple of other things
you might try. I have an older reference copy of your reboot script so
you might have already implemented some of these ideas. You might want to
send a current copy my way in case you have made updates.
You might try downing all the network interfaces.
You might try running the setboot program at time critical priority using
setpri or the equivalent.
You might write the output of go to a log file before rebooting. This way
you will more information on what the live processes are doing when the
reboot hangs.
You might try adding a call SysSleep 10 after the setboot. In general
SysSleep is better than sleep because it does not start a new process.
i added a wait of 10 seconds now
When you need to try a manual reboot, does top show any processes using a
lot of CPU time?
Steven
after more than 3 weeks i've to say that raising the value of VAL has improved
overall system stability
but today at the scheduled reboot early in the night (a cmd start that close most of the processes and do setboot /b) the VM freeze with "The system is rebooting. Please wait ....."
of course in that condition the server is not accessible, with mouse, keybord or remote
i've completely forgot :) that in the past i added a "PDumpCtl HTTPD r f d o"
before the reboot
it also save the previous DUMP and do the new one, so i've 2 dumps
the situation good and the situation bad
this could be of any help?
anyway i also added to that script a lot of diagnotic logs
the content of the ram in that moment, before the seboot /b is this under here:
as you can see the task #65
0065 10.605M 10.047M 2715 2572 HTTPX
is an unkillable apache child
GETRAM version is 1.0.0.
RAM use by process started on Mon Dec 25 23:49:48 2023
Doing 1 time intervals of 0 seconds each.
<Count in Megabytes><Count in Pages>
Pid Private Shared Private Shared Task Names
0000 117.691M 5.598M 30129 1433 system
0001 0.023M 0.117M 6 30 Sysinit
0004 0.066M 0.016M 17 4 LVMALERT
0007 0.020M 0.031M 5 8 LANMSGEX
0008 0.133M 0.027M 34 7 ACPIDAEM
0009 0.230M 0.023M 59 6 CNTRL
0016 1.258M 4.043M 322 1035 PMSHELL
0017 0.020M 0.000M 5 0 VDM
0018 0.043M 0.031M 11 8 HARDERR
0019 0.414M 0.168M 106 43 PMSPOOL
0020 0.066M 0.039M 17 10 CMD
0022 0.188M 0.066M 48 17 CMD
0059 3.684M 2.340M 943 599 GATEWAY
0065 10.605M 10.047M 2715 2572 HTTPX
0066 0.070M 0.039M 18 10 CMD
0092 1.660M 3.699M 425 947 HTTPX
0093 6.996M 3.691M 1791 945 HTTPX
0094 12.320M 5.496M 3154 1407 HTTPX
0095 12.293M 5.535M 3147 1417 HTTPX
0096 12.297M 5.500M 3148 1408 HTTPX
0097 0.293M 0.066M 75 17 CMD
0105 0.105M 0.012M 27 3 PROCDUMP
0163 24.223M 0.102M 6201 26 GETRAM
-------- -------- ------- -------
204.699M 46.688M 52403 11952 Total RAM used
2820.160M 721961 Free RAM available
-------- -------
3071.547M 786316 Total RAM (Prvt+Shr+Free)
now i also close PMSPOOL (i don't know why it's running in that moment, since i kill it at VM startup), added a 10 sec. sleep and removed all the diagnostic stuff
let's see if it improves the situation
but if it's apache with his unkillable child all these improvements will not help for sure, since afaik in some way it lock something in the file system that prevent the normal reboot with setboot /b
i also don't know if there something more powerful to the setboot /b that is able
to reboot the system also in those situations
thanks
massimo
|