On 4/13/22 23:28, Gordon Messmer wrote:
I've gotta ask... How much memory does the new dnf daemon take while idle?
I know this comes up time to time... As it is, PackageKitd and gnome-software
both, individually, take ~ 450MB of RAM without any user interaction (other
than logging in to a desktop) on a F36 system I updated for general testing.
Assuming that there is minimal "bloat" in app data structures, then
the root cause of such high usage of address space is python memory management.
By default, python does not collect and re-use memory "garbage" (previous
allocations that no longer are accessible) until the OS denies a request to
allocate a new page. The typical result is a long time before the first
collection,
because Linux will allocate new pages until /proc/meminfo.CommitLimit is reached
(and/or swap space is exhausted, which invokes OutOfMemory process killer.)
In particular, a python daemon which starts and reaches a (near-)steady state
soon after system boot might not ever collect garbage unless the system
runs for weeks or months before a re-boot.
In order to reduce the memory footprint then the python strategy
must be changed, and/or the app must pay attention (explicitly delete
and collect garbage.) In the particular case of rpm package management
on a system with 64-bit pointers, then the app also should use arrays
instead of linked structures. There is no case of more than (1<<24)
packages, and nearly all invocations manage fewer than (1<<16) packages.
Thus a 2-byte or 3-byte ordinal (packed) can be used instead of an 8-byte
pointer.
This may require non-trivial code changes. For instance, the stack
cannot be used as the residence for a temporary package structure.
Also, using text compression might reduce significantly the RAM
that is required to store character strings. Even without compression,
in many apps character strings tend to persist forever without
modification, so just append them into chunks of (1<<20) bytes,
with a separate array of (1<<12) pointers to chunks. Then such a string
can be identified by a 32-bit ID instead of a 64-bit pointer,
which saves 4 bytes for the pointer plus at least 8 bytes of
accounting overhead used by the default malloc().
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
