HP 9000 UNIX reboot

[MBacc]

In order to speed up our processing we find rebooting our HP9000 helps. We have a nightly process that runs 1 hour but after a reboot it runs only 30 minutes. Can you think of any clean up commands we can run instead of having to schedule a reboot every month?

[TTr]

> we find rebooting our HP9000 helps
How does it help? Typically rebooting a server cleans up all runaway processes that would do unnecessary i/o and occupy memory. So if you find these processes and clean them manually you may be able to do without rebooting.
Determine if you have any memory leaks. If so apply patches at the application server and at the OS level. Also check if you have any unreleased memory by using "ipcs -a". This is related to runaway processes but sometimes when you cleanup a process that holds a large memory segment, taht memory segment may not always be released and you have to clear it manually. Look at "man ipcs" and "man ipcrm"
If you run out of memory, your processes eventually will swap to disk and that could explain the example that you mentioned with the "1hour down to 30 minutes" process. Check your swap status with "swapinfo -tam"

[James R. Ferguson]

Hi:

To add to TTr's comments, make sure that users *gracefully* exit their telnet connections. PC-based users who disconnect ungacefully can leave orphaned processes that can consume both CPU and memory. If this is the case, demand that those users log-out of your server before they terminate their PC session.

Regards!

...JRF...

[Rasheed Tamton]

Before you reboot, take note all the processes, mem, cpu, etc. into a file:

UNIX95= ps -ef -o pid,vsz,pcpu,user,args |sort -rnk2 > /var/tmp/sysstat.txt

After system boot up, take note it again and compare with the above output. Start your database, note it again. Stop the db and note the values/compare. After stopping the db, the value should be the same as prior to starting the database. If not, you might have issues there - may be a memory leak.

Start and stop your applications one by one, each time you note/compare the differences.

If you are rebooting monthly, do kind of metrics on a daily basis with the above and try to compare. You might find the culprit process there.

[OldSchool]

James' suggestion is a good one. I've seen out users close their emulator window w/o logging off at all. In some cases the processes just "spin" and suck up CPU.

I've seen such processes become the highest resource user in "top". Killing those processes restored system performance to normal levels.

Repeat offenders were treated to not being able to login ("you're already logged on") until they went to the supervisor and explained what they'd done.