On Fri, Jul 24, 2009 at 6:12 AM, Mike Westerhof
(mwester)<[email protected]> wrote:
> Nicola Mfb wrote:
[...]
> This problem has been with opkg for a long time.
Sorry, I know that, but as I did not got it before I'm just supposing
the problem is grown recently.
> In a nutshell, opkg builds *huge* in-memory databases. It also places
> many temporary files (some duplicates, in fact!) in the /tmp directory,
> which is a tmpfs filesystem, and thus also comes out of memory. In
I just realized that doing some opkg process monitoring (see the other
my post) and fixed the problem with swap space.
> various parts of the code, it calls the fork() system call as well (in
> the example you post above, it forks a process to decompress the package
> and extract the control file portion of the package).
>
> The Linux fork() system call duplicates the memory space; both the
> parent and the child process have a copy of the parent's entire memory
> space. If there is not enough memory, the fork will fail outright, or
> the dreaded OOM Killer (Out-Of-Memory Killer) will terminate opkg.
Uh! AFAIK fork should advantage of linux copy on write, so if the
child process does not uses and change a huge data segment deeply, the
memory should not be wasted. If I remember well top signaled a big
shared candidate memory size this night, however I may be totally
wrong.
> A set of patches exists that address some of these issues. They need to
> be ported to the latest opkg sources, however. In a nutshell, replacing
> the use of fork() and system() calls with vfork() will help a lot. I
> would also suggest that the patch to move temp files out of /tmp would
> also be a good idea.
These are good work around, but IMHO opkg is for embedded systems it
should not use all that memory (I see a peak of 55Mb), and the second
it's now too slow, yesterday 5 mins to install tiny frameworkd config
files with high cpu usage and a lot of read call to file descriptor
number 6 returning 0, and about 15 mins to install a package with 4 or
5 dependencies. That's the reason I suppose some thing broke opkg
recently.
Thanks
Nicola
_______________________________________________
Shr-User mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-user
