Mailing List ecs-isp@2rosenthals.com Archived Message #646

From: "Massimo S." <ecs-isp@2rosenthals.com> Full Headers
Undecoded message
Subject: Re: [eCS-ISP] apache+php and VA limit
Date: Tue, 26 Dec 2023 14:01:23 +0100
To: 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


Subscribe: Feed, Digest, Index.
Unsubscribe
Mail to ListMaster