On Tue, 2011-05-03 at 22:23 -0700, John Reiser wrote:
> On 05/03/2011 12:35 PM, David Lehman wrote:
> > New minimum for physical memory is 640MB. New minimum memory for us to
> > not require swap space is 1152MB. I arrived at this number by doing an
> > x86_64 install of F15 Beta in kvm, using "Web Server" package set. I
> > tried 1024MB and it froze during selinux-policy-targeted installation.
>
> I have no doubt that is what you observed. However, an installer which
> requires more than 1GB of system RAM is unreasonable, even if there is
> no swap space. That is too much RAM. Something fundamental is broken.
I agree that the memory requirements seem excessive.
>
> One guess for needing so much RAM is that the installer's allocator
> (python/C memory manager) never reclaims anything unless forced.
> The amount of memory _apparently_ required increases package-by-package.
> When the %post sub-process for selinux-policy-targeted is invoked,
> then inside the installer there is lots of space that is free (or
> _could_ be free), so there would be no problem if swap space were
> available, or if reclaiming had been done. But because swap space
> is not available and reclaiming has not yet been necessary,
> then there is not enough RAM for both the never-reclaimed installer
> and the %post sub-process.
You are talking about glibc and python here -- not anaconda.
>
> SUGGESTIONS: See if disaster can be avoided by forcing the installer's
> memory manager to run in less total space. How? Several things to try:
>
> 1. Invoke garbage collection explicitly every 10 packages.
>
> 2. Limit the installer's data size to 350MB with the shell builtin
> "ulimit -d 350000", or limit the total virtual size using
> "ulimit -v 350000".
>
> 3. Limit the installer address space by using the C code
> setrlimit(RLIMIT_AS, &{350000*1024, 350000*1024});
>
> 4. Check if the installer's class structure for a package,
> or the installer's use of it, causes unintended retention of I/O or
> decompression buffers that are not shared with other packages.
> (Did some destructor not get called? Is a big object retained
> on a list when it would suffice to keep only the string name
> of the package? Etc.)
>
> 5. Ask the maintainers of selinux-policy-targeted to check for
> over-estimating (and then over-allocating) runtime space requirements,
> particularly with regard to swap space being unavailable.
>
> If none of those ideas work, then here is the most-powerful hammer:
> 6. Surround the install of each package with:
> child = fork();
> if (-1==child) /* fork() failed */
> try_again;
> else if (child) /* in parent */
> wait_for(child);
> else { /* in child */
> install_package();
> exit(status);
> }
> This guarantees that the installation of a package does not change the
> state of the allocator arena in the parent. My hypothesis is: the largest
> amount of RAM required by the installer will be not more than the RAM
> required after only the first few packages have been installed:
> about 280MB or so. [Obviously this idea can be applied to each step
> before package installation, too. All the GUI dialogs
> shouldn't increase the process size very much, either.
A nice theory, but it shows that you have no understanding of how
package installation works. Or how yum is designed, for that matter.
It is very easy to call plays from the sidelines, but if you want to
make a difference you should consider putting some of your theories to
the test -- implement them.
Dave
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
