https://sourceware.org/bugzilla/show_bug.cgi?id=27399
Sergio Durigan Junior <sergiodj at sergiodj dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #3 from Sergio Durigan Junior <sergiodj at sergiodj dot net> ---
(In reply to Frank Ch. Eigler from comment #1)
> Can you check whether dpkg-deb is decompressing all of its content onto some
> RAM-backed filesystem, and running out of space via that (or via consuming
> machine free ram)?
It doesn't seem to be doing that. My /tmp is not mounted
> You can try a few things:
>
> - run debuginfod with a smaller concurrency limit (-c NNN), because the
> decompression etc. activities aggressively use all your CPUs and thus
> #CPU * memory, if they can
For completeness sake, I'm running my tests using a VM with 8GB RAM and access
to 10 host CPUs.
Having said that, I've tried specifying "-c 4", and it seems to have mitigated
the problem.
> - instead of 'debuginfod -U' (which uses dpkg-deb as the decompression
> streamer), use
> % debuginfod -Z.deb="(bsdtar -O -x -f - data.tar.xz)<"
> which causes deb files to be processed with libarchive's frontend
> (or equivalently, temporarily rename /usr/bin/dpkg-deb while starting
> debuginfod, so it makes the same inference)
This also seems to work, even without limiting the concurrency. So far, I
think it's the best workaround/solution.
> - monitor resource usage - particularly ram - during the indexing process
I'm monitoring RAM usage, and it's interesting to notice that in the "normal
case" (i.e., using "-U" and not limiting concurrency), the usage is pretty much
the same as it is when using bsdtar, and it stays well below the limit of the
VM.
> - try running elfutils 0.183 debuginfod, which does a touch more
> filesystem-space monitoring, related self-protection, more
> prometheus error metrics
Yeah, I'm using elfutils 0.183 here already.
--
You are receiving this mail because:
You are on the CC list for the bug.
