Your message dated Fri, 14 Oct 2022 02:35:40 +0200 with message-id <y0iu3fogkjckk...@thunder.hadrons.org> and subject line Re: Bug#245970: dpkg: [PERF] unpacking packages extremely slow on systems with <= 64 MB memory has caused the Debian Bug report #245970, regarding dpkg: Unpacking packages extremely slow on systems with <= 64 MB memory to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 245970: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245970 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: dpkg Version: 1.10.23 Severity: normal Hello, On my sid box, dpkg has been crashing for the last 15 days. Digging a bit I found that dpkg needs above 100Mo of RAM nowdays to be able to proceed on this box. Killing a bunch of application does solve the pb. It would be nice if you guys could do something to lower the memory usage of dpkg. @+, Fab Some more info : $ sudo apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done The following packages have been kept back: <...cut...> 58 upgraded, 0 newly installed, 0 to remove and 24 not upgraded. 1 not fully installed or removed. Need to get 0B/74.7MB of archives. After unpacking 5248kB of additional disk space will be used. Do you want to continue? [Y/n] Reading changelogs... Done Preconfiguring packages ... (Reading database ... 462457 files and directories currently installed.) Preparing to replace sysvinit 2.86-1 (using ..../sysvinit_2.86-4_i386.deb) ... Unpacking replacement sysvinit ... dpkg: error processing /var/cache/apt/archives/sysvinit_2.86-4_i386.deb (--unpack): fork failed: Cannot allocate memory dpkg: error while cleaning up: fork failed: Cannot allocate memory Errors were encountered while processing: /var/cache/apt/archives/sysvinit_2.86-4_i386.deb Processing was halted because there were too many errors. E: Sub-process /usr/bin/dpkg returned an error code (1) $ sudo dpkg -i /var/cache/apt/archives/verilog_0.7+20040828-1_i386.deb Password: (Reading database ... 462457 files and directories currently installed.) Preparing to replace verilog 0.7+20040606-1 (using ..../verilog_0.7+20040828-1_i386.deb) ... Unpacking replacement verilog ... dpkg: error processing /var/cache/apt/archives/verilog_0.7+20040828-1_i386.deb (--install): fork failed: Cannot allocate memory dpkg: error while cleaning up: fork failed: Cannot allocate memory Errors were encountered while processing: /var/cache/apt/archives/verilog_0.7+20040828-1_i386.deb Processing was halted because there were too many errors. $ free total used free shared buffers cached Mem: 517220 429968 87252 0 2072 51516 -/+ buffers/cache: 376380 140840 Swap: 0 0 0 ^^^^ running without swap = wanted feature. $ grep -v "^#" /etc/apt/sources.list | grep -v "^$" deb ftp://debian.univ-mlv.fr/debian sid main non-free contrib deb-src ftp://debian.univ-mlv.fr/debian sid main non-free contrib deb ftp://debian.univ-mlv.fr/debian-non-US sid/non-US main contrib non-free $ dpkg -l | wc -l 3759 -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.7arkham Locale: LANG=fr, LC_CTYPE=ISO-8859-15 (ignored: LC_ALL set to fr_FR@euro) Versions of packages dpkg depends on: ii dselect 1.10.23 a user tool to manage Debian packa ii libc6 2.3.2.ds1-16 GNU C Library: Shared libraries an -- no debconf information
--- End Message ---
--- Begin Message ---Hi! On Mon, 2004-04-26 at 16:20:18 +0200, Guus Sliepen wrote: > Package: dpkg > Version: 1.10.21 > Severity: normal > For some time now dpkg is really slow on a 200 MHz AMD k6 with 64 MB > memory. On a 1.4 GHz Athlon with 768 MB it runs fine. The difference is > much more than what could be attributed to difference in processor > speeds, so I believe memory is the main issue here. A dpkg process > easily uses > 30 MB. The unpacking phase is the worst, and by profiling > I found three points in process_archive() in processarc.c that take the > most time: I think the amount of RAM mentioned here is extremely low for nowadays standards, so I'm just going to close this one. (I'm always interested into looking into performance improvements, as long as they do not significantly impact the code readability, nor current semantics, although currently I think disk I/O seems to dominate the installation process anyway.) Thanks, Guillem
--- End Message ---
