Jeff Johnson wrote:
>> The --stepped option mentioned causes Smart to do multiple commits
>> (after splitting the ChangeSet), with each commit() doing a ts.run
> Is smart calling ts.run() once or twice per-commit?
There should be only one call per commit / ts object,
but several such transactions created/commited within
one single run (and thus one python memory heap...)
> For hysterical up2date reasons, yum is likely detecting file conflicts
> with a call to ts.run(), then calling ts.run() a 2nd time to
> install/erase packages. The 2nd call is triggering the
> fragmentation in the bug report.
Smart kinda bombs out on file conflict, when not
specified elsewhere as an explicit file dependency.
i.e. it will try the transaction, and then fail it
(reporting the error given from rpm, i.e. conflict)
> There's likely some other code rearrangements in python, deleting
> objects that assist in removing fragmentation. But that likely
> cannot be done with yum, but I'm perfctly happy to help with smart.
I believe all that is being done is deleting the object.
ts = getTS(True)
# does getTS.ts = rpm.ts("/")
probs = ts.run(cb, None)
> Yes, I would expect the problem to show up with --stepped, which
> has more persistence, and a better chance to cause fragmentation.
> Deleting a rpmts to close/open an rpmdb per-stepped transaction
> will free whatever memory happens to be in use by rpmlib, and
> as long as there are <100 stepped transactions, close/open an rpmdb
> won't hurt much (yum was doing open-get-close cycles on every access,
> that too is/was very peculier).
Will see if I get a reproducer with some -vv spew.
(and _rpmts_debug sounds like a likely candidate)
Received on Sat Jan 17 16:53:50 2009