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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
