Thanks for the help to my question:
>
> Hi,
>
> i'm using swapscape in over-commitment mode and sometimes get the
> following messages:
>
> :
> :
> Jan 22 04:21:17 tycho vmunix: swap space below 10 percent free
> Jan 22 04:21:55 tycho last message repeated 3 times
> Jan 22 04:22:53 tycho last message repeated 4 times
> Jan 22 04:24:41 tycho last message repeated 2 times
> Jan 22 04:24:41 tycho vmunix: process (pid = 693) killed because of
> no swap space
> Jan 22 04:24:53 tycho vmunix: swap space below 10 percent free
> Jan 22 04:25:16 tycho vmunix: swap space below 10 percent free
> Jan 22 04:26:06 tycho last message repeated 3 times
> Jan 22 04:26:06 tycho vmunix: process (pid = 21998) killed because
> of no swap space
> :
> :
>
> is it possible to prevent the system from killing system processes??
> because sometimes this results in a total system crash!
>
and here's the summary of answers:
alan_at_nabeth.cxo.dec.com wrote:
>
> a. Get more page/swap space.
> b. Switch back to the default page/swap reservation mode.
> c. Do both a and b.
>
> The value of over-commit mode is that it doesn't limit virtual
> memory usage to the amount of swap space available. The risk
> is that when you do run out, it has to kill something to space
> back so it doesn't dead lock.
------------------------------------------------------------------------
Richard Sharpe wrote:
> Yes! Don't use over commit mode! That is the down side. Or, add more
> memory and swap!
>
------------------------------------------------------------------------
Gwen Pettigrew wrote:
>
> Hi Peter,
> If you are in overcommitment mode then you will probably have to add
> more swap space.
> I have seen this message in immediate-mode and I resolved it by
> switching to over commitment. ( we hardly ever page out on our
> programs.)
------------------------------------------------------------------------
Mostafa Mahdy wrote:
>
> Its better to increase the swap space by adding swap2.
------------------------------------------------------------------------
Peter.Stern_at_weizmann.ac.il wrote:
>
> As far as I know, there is no way in which you can control the system
> algorithm for deciding which processes to swap out. Your basic choices
> are to increase your swap space or increase your physical memory and
> your swap space. Basically, if you run out of swap space in deferred
> mode, your system is not functioning properly anyway. Something will
> have to be killed and it might be some other process that you didn't
> want to lose.
>
> I guess that if you use immediate mode new processes won't start if
> there isn't enough swap space available to reserve for them and then
> nothing gets swapped out and your system won't crash. But this requires
> a lot more memory and/or swap space or you will get to "below 10 percent
> free" much, much sooner.
>
------------------------------------------------------------------------
Nikola Milutinovic wrote:
>
> Yes, don't use over-commitment mode. It is bad, anyway. In order to use
> immediate mode you need a symbolic link to your primary swap, like this:
>
> # ln -s /dev/rz0b /sbin/swapdefault
>
> Then, reboot your machine and you shouldn't have a process killed off. They
> might refuse to run, but once they get to run, they won't die for lack of space.
------------------------------------------------------------------------
Erik Piip wrote:
>
> Basically, you are running out of virtual memory. Easy fix is to add more
> swap disk.
>
> When you run out of virtual memory, the system has no options other than to
> crash, or try to free up some memory by killing processes.
------------------------------------------------------------------------
"Lavelle, Bryan" wrote:
>
> No processes are safe from being killed when the swap is exceeded. No way
> to protect them. I've heard a rumor that this may change in future
> releases, but have done no research to confirm.
------------------------------------------------------------------------
"Davis, Alan" wrote:
>
> Peter,
>
> Processes are killed at random with no regard to
> whether they are system processes or not.
>
> Your two options are to add swap space or add memory.
>
> Alan Davis
------------------------------------------------------------------------
"Dr. Tom Blinn, 603-884-0646" wrote:
> Yes. Configure your system to have enough swap for your workload. Then
> the system won't kill processes. There is NO DISTINCTION between what
> you call a "system process" and any other process when it comes to the
> selection of a "victim" if you are out of swap space and more swap is
> needed to support demand paging -- some process dies. Whether it's the
> process that's trying to grow its address space or some process that is
> inactive but holding a lot of pages in swap is a policy decision, and
> I believe the policy is dependent on whether you're using "eager" or
> "lazy" swap allocation, but either way, some process is going to die
> if you run out of swap, and your system is running out of swap space.
>
> (I believe that in swap overcommit mode, the process that dies is the
> one that is holding the oldest page in physical memory; that process
> is the one that has the page that is chosen for swap out, and in many
> cases it's a process that is long running but doesn't touch all of its
> address space regularly, so it's often something like the X server or
> the "init" process. Killing "init" kills the system.)
>
> YOU MUST HAVE ENOUGH SWAP TO RUN IN SWAP OVERCOMMIT MODE OR YOU WILL
> MAKE THE SYSTEM FAIL IN UNPREDICTABLE WAYS.
>
------------------------------------------------------------------------
Serguei Patchkovskii wrote:
> Certainly. Add more swap space.
------------------------------------------------------------------------
"Luchini, Marco" wrote:
>
> No. I believe that the system has to kill the next process that asks for
> swap otherwise the system would deadlock. So there's no real way for the
> O/S to pick and choose which process to kill. Though I agree that killing
> the process that is gobbling up the swap would be a desirable outcome, this
> will only happen if it is continuously gobbling swap.
>
> What I usually find happens, is that the swap is full, desktop user
> complains by email, sendmail dies, user then complains to "knowledgeable
> friend" who telnets in causing inetd to die. Word eventually gets back to
> sysadmin who physically goes to the console and restarts the dead daemons.
> I used to hate this little ritual!
------------------------------------------------------------------------
Blake Roberts wrote:
>
> What you need to do is add more swap space to your server. There is no way
> of preventing which process dies. If the process can't get any memory (swap
> or otherwise), then it will die. Crashing is a way of life if you run out
> of swap space.
>
------------------------------------------------------------------------
John.McNulty_at_ntl.com wrote:
>
> It's really irittating that there are two different terminoligies used to
> describe the different swap algorithms. By over-commitment mode, I assume
> you mean deferred mode, as defined in the swapon(8) man page?
>
> You can change this by soft linking /sbin/swapdefault to your primary swap
> device, however, if you're running out of swap in deferred mode, you're
> going to run out even faster in immediate mode. The advantage here is that
> random processes won't die when you run out of swap. The downside is that
> you won't be able to create as many processes in the first place, as swap
> space allocation in this mode is checked at process start time.
>
> The long and short of it is that you're probably going to have to get
> another swap partition from somewhere else, even if that means buying
> another disk. Either that or reduce the load on the system.
>
> It's worth noting that Compaq recommend immediate mode for servers, where
> data integrity is important, and deferred mode for workstations. Running
> deferred (over-commitment) mode on servers where databases are involved is
> dangerous, as when swap is exhausted, the very next process to request a
> page of swap gets a bullet in the brain from the kernel. I've seen Oracle
> databases get toasted because of this. Though I had no sympathy for the
> victims as they should have known better.
------------------------------------------------------------------------
Mark.Scarborough_at_broadwing.com wrote:
>
> Yes, of course. The answer is to not run in over-commitment mode. That is the
> definition of that mode - it allows processes to start but might kill off old processes
> to regain swap space. Eager swapping will not ever kill processes.
------------------------------------------------------------------------
Peter
Received on Mon Jan 24 2000 - 18:18:31 NZDT