Performance Problem, "REBOOT SERVER",,, But ...?

[Shahbaz_1]

Hi Friends,
In most of the performance related cases, it has been seen that, "SERVER-REBOOT" advice comes in.

When should we go for server-reboot?

---System Memory is fragmented. How to find out this? And is "Server-Reboot" the only-solution?

---Processors are over-burden, certain daemons are running consuming cpu-resources, don't know the implication of killing these daemons, so better "REBOOT SERVER"
Is it justifyable ...... ?

Friends, Please share your experience and ideas in regarding above.

Thanks in Adv

Regards
Shah

[Patrick Wallek · Accepted solution]

IF application is written WELL, then you should NEVER have to reboot a server to clear memory, etc. I have heard of servers that ran for months and YEARS without a reboot.

In an ideal situation, you should only have to reboot the server if / when you install patches that require a reboot.

If an application does not manage memory properly and possibly does not release it when it is done, a reboot could be called for, but then the real solution is to fix the application so you don't have to reboot.

[Michael Tully]

Generally speaking servers should not need a reboot if the application that runs on it is stable. Patching and some other necessary hardware maintenance to a server is about the only other time(s)
We have one particular application at our site that requires a reboot every week, as it has memory leaks which for some reason cannot be fixed by the application vendor at this time.

Other times:
NFS/pfs mount problems (if not patched properly)
zombie processes that won't die.

I've also seen and heard of many systems that have run for many months and years.

[Shahbaz_1]

Hi Thanks for the input.
-- How to find out the memory fragmentation/leak problem?
-- "APPLICATION" is culprit in "memory leak", how about the database?

Without rebooting-server, bouncing-back the database, after finding that lots of resources are consumed by database-processes ?

please share your views.

Regards
Shah

[Stefan Farrelly]

The best way ive found to check for an application memory leak is;

1. reboot your server and do not start your applications.
2. check free memory with vmstat
3. start your applications (but no users)
4. check free memory with vmstat
5. shutdown your applications
6. check free memory with vmstat. I would expect the amount of free memory to go back to what it was before you started your applications. If not then looks like a leak.
7. restart your app, let users on.
8. check free memory with vmstat
9. get all users off and shutdown app.
10. check free memory with vmstat
11. Free memory should now be back to the same as it was after you rebooted your server but before any applications were started. If not then you app has a leak! Trying to isolate the leak is a lot more difficult though.

The best way to do this is using some graphs like PerfView so you can go back over many weeks and compare memory usage - its easy to then see the memory used curve not returning to normal so you can spot leaks easily. You can free a free trial if you install it.

[Stefan Farrelly]

Oh, I forgot to add, before doing these free memory tests using vmstat you will need to set buffer cahce to a fixed amount - to stop it clouding the issue. Set dbc_min_pct and dbc_max_pct to the same number (eg. 5) and build a new kernel and reboot. Otherwise buffer cache may expand and contract and confuse your free memory stats.