LINUX Server Reboot Frequency 7372

OK: you can't "check for memory leaks" in such closed source code, you can only check that the amount of RAM being used is expanding: the "top" command will give a hint, and you should be able to poke around in theproc filesystem and find some appropriate flags buttociated with the Oracle processes that can be examined to see how large they are.

Linux tries hard to keep as much in RAM as feasible: it's only when things start overflowing RAM, such as a database that's been up for a while and gotten really, really big with people doing work on it or a program with a memory leak, that you start swapping and things slow down. Paul is right that just restarting the Oracle server should get it to release all resources.

To understand how leaks happen, read the manual pages on "free" and "malloc". Notice that "free" does not give the memory back to the system! It only frees up memory to be used by the same program, so that the next malloc can occur in that freed up memory space. But it's very easy to make mistakes with a big database or big program, mistakes in userland, that generate *grotesquely* large tables for only a few minutes, and they can never be returned to the system without restarting the program: they're only preserved for further use by that program.

Now, Oracle is supposed to have all sorts of nifty fail-over behavior which I've never gotten a chance to push: if you have such a setup, it should be possible to keep the servers synchronized, reboot one while the other takes the load, then restore the first server without that overflowing RAM problem, then a week later reboot the second one while the first takes the load. I've done things like that for DNS and DHCP, for various reasons, and it seems to work well.