On Feb 19 10:12:03, Philip Guenther wrote:
> 14 == EFAULT. Those are generated when the kernel tries to write out
> a process's memory image for a coredump and the indicated range of
> memory couldn't be faulted in so that it could be written to the
> filesystem.
> > The inability to fault in memory that the kernel thinks should be
> > there makes me wonder if you're swapping and the device you're
> > swapping to is failing. Your dmesg suggests you might be swapping to
> > your CF card and you (only?) have 128MB of real memory. When this is
> > happening, what's the output of "swapctl -l"? If that shows you are
> > indeed into swap, then a failing CF card would be my guess.
>
> Yes, the machine only has 128MB of memory - which I think should be
> enough for what it does: NATing pf, dhcpd and resolver for the
> internal network, and postfix and httpd for my domain (which
> amounts to almost no traffic).
>
> It does not have any swap configured. In fact, I try to design
> my systems so that they don't ever need to swap.
>
> $ swapctl -l
> swapctl: no swap devices configured
>
> If it so happens that there is not enough memory for some running
> process (a situaion I cannot rule out now), and there is no swap
> to deal with this, is that a reason for a process to be coredumped?
On Feb 19 12:26:03, Philip Guenther wrote:
> Have you monitored the memory usage to confirm or deny your belief
> that it's sufficient?
I have now (and should have before of course).
The memory is _not_ sufficient because of a single
process (a demanding user's tomcat installation)
eating all the memory.
Specifically, the user is in the 'default' login class,
which entitles him to 512M on this 128M machine. His
java process requires about 180M (says top).
On Feb 19 15:17:31, Ted Unangst wrote:
> > If it so happens that there is not enough memory for some running
> > process (a situaion I cannot rule out now), and there is no swap
> > to deal with this, is that a reason for a process to be coredumped?
> > (I think that I have seen processes just die with ENOMEM
> > in that situaion.)
>
> ENOMEM is somewhat unlikely even in low memory situations, because the
> kernel allows overcommit. A process can allocate memory that's not
> technically available,
This must be what's happening on my machine now:
a java process getting 180M on a 128M machine.
> then when it tries to use that memory and the kernel can't find
> anything to provide, segfault.
What puzzles me that it's the other processes that are segfaulting;
the java process that ate the (nonexistent) memory keeps running,
but an innocent vi(1) gets killed later, or a ntpd trying to sync.
Is this how the memory "overcommit" functionality works?
I have killed the java process about an hour ago,
and limited the memory usage in login.conf to
:datasize-max=100M:\
:datasize-cur=100M:\
which makes the java process fail to start:
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
None of the symptoms has occured since.
At any rate, thank you for the hints. What can I do
to further test my current suspicion that the memory
insuficiency is what was causing it?
Jan
