Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 496892 - sys-apps/portage: portage.doebuild() is consuming a lot of RAM since REPLACING_VERSIONS introduction
Summary: sys-apps/portage: portage.doebuild() is consuming a lot of RAM since REPLACIN...
Status: RESOLVED NEEDINFO
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-03 14:38 UTC by Fabio Erculiani (RETIRED)
Modified: 2022-07-28 05:15 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fabio Erculiani (RETIRED) gentoo-dev 2014-01-03 14:38:10 UTC
the introduction of REPLACING_VERSIONS caused portage.doebuild() to load the aux_db cache (via pickle) in RAM just for a bunch of vardb.match() calls.
aux_db cache is huge, in my case (typical desktop system) it can take up to 70-80Mb of RAM (and you know how Python is reluctant of giving back RAM to the OS).

The affected code path is this:

  /home/fabio/repos/entropy/lib/entropy/spm/plugins/interfaces/portage_plugin/__init__.py(2262)_portage_doebuild()
-> use_cache = 0
  /usr/lib64/python2.7/site-packages/portage/proxy/objectproxy.py(31)__call__()
-> return result(*args, **kwargs)
  /usr/lib64/python2.7/site-packages/portage/package/ebuild/doebuild.py(937)doebuild()
-> for match in vardb.match(cpv_slot, use_cache=use_cache) + \
  /usr/lib64/python2.7/site-packages/portage/dbapi/vartree.py(514)match()
-> self.cp_list(mydep.cp, use_cache=use_cache)))
  /usr/lib64/python2.7/site-packages/portage/dbapi/__init__.py(175)_iter_match_slot()
-> pkg_str = self._pkg_str(cpv, atom.repo)
  /usr/lib64/python2.7/site-packages/portage/dbapi/__init__.py(158)_pkg_str()
-> self.aux_get(cpv, self._pkg_str_aux_keys, myrepo=repo)))
  /usr/lib64/python2.7/site-packages/portage/dbapi/vartree.py(669)aux_get()
-> pkg_data = self._aux_cache["packages"].get(mycpv)
  /usr/lib64/python2.7/site-packages/portage/dbapi/vartree.py(568)_aux_cache()
-> self._aux_cache_init()
> /usr/lib64/python2.7/site-packages/portage/dbapi/vartree.py(592)_aux_cache_init()
-> aux_cache = mypickle.load()

Is there anything that could be done to avoid such a huge memory consuption?
Comment 1 Sebastian Luther (few) 2014-01-03 17:38:38 UTC
How did you manage to not load it until this point?
Comment 2 Fabio Erculiani (RETIRED) gentoo-dev 2014-01-03 17:41:40 UTC
I don't think it matters.
Comment 3 Sebastian Luther (few) 2014-02-09 20:59:18 UTC
(In reply to Fabio Erculiani from comment #2)
> I don't think it matters.

I think it matters, because if we don't know how you call the portage api, then we don't know what would need to be changed to fit your needs.

For normal emerge operation there's no problem, because you'll always have the vdb loaded.

You sending a patch to the portage ml would also work.