On Fri, 29 Jul 2005, Joerg Bruehe wrote:
> > Now the only question that remains is why the Active memory goes close to
> > zero when exiting fillmem and is not when ending a compile run. I asked
>
> Again IMHO, it shows an error in memory management.
I do not know if it's an error or not. I do agree with you that the memory
management in Linux 2.6 does not seem to be ideal. I even found the
following comment in the malloc manpage:
'By default, Linux follows an optimistic memory allocation strategy. This
means that when malloc() returns non-NULL there is no guarantee that
the memory really is available. This is a really bad bug. In case it
turns out that the system is out of memory, one or more processes will be
killed by the infamous OOM killer. In case Linux is employed under circum-
stances where it would be less desirable to suddenly lose some randomly
picked processes, and moreover the kernel version is sufficiently
recent, one can switch off this overcommitting behavior using a command
like
# echo 2 > /proc/sys/vm/overcommit_memory
See also the kernel Documentation directory, files
vm/overcommit-accounting and sysctl/vm.txt.'
What I don't understand is why I seem to be one of few suffering from this
problem. MySQL on Linux 2.6 (combined with a massive amount of RAM) is
hardly an uncommon configuration nowadays.
Secondly it seems two parties (MySQL and Fedora) are pointing to each
other right now. Let me quote:
On Fri, 29 Jul 2005, Rick Stevens wrote:
> Well, malloc() will fail if you request a chunk of memory and there
> isn't a SINGLE chunk available of that size. So if memory gets fragged,
> there isn't a single 7GB chunk available and malloc() will fail.
> fillmem allocates in smaller chunks, then releases it all so the
> memory defragger can clean things up.
>
> Ideally, that's what mysql should do. Or start off at some huge
> size and keep trying progressively smaller chunks until it gets some,
> e.g. try 8GB. If that fails, try 6GB, then 4, then 2, you get the
> idea. It could then link those together and manage them.
>
> I'm not surprised that it fails. You're asking a single application to
> grab 7/8 of your RAM--and all in one chunk--regardless of what else has
> been run before it. On a pristine system (e.g. right after a boot),
> it may work. After that...
It sounds kind of reasonable if explained like this. Now, which method
(allocating all in one single malloc call or allocating multiple smaller
blocks) is considered good programming practice? And would this be
something InnoDB would be likely to change? (A long shot, I guess)
Best regards,
--
Matthijs van der Klip
System Administrator
Spill E-Projects
The Netherlands
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
