Bug#808579: apt: Very slow rred phase during update
Control: tag -1 confirmed
On Mon, Dec 21, 2015 at 08:32:33AM +0100, Stefan Fritsch wrote:
> Package: apt
> Version: 1.1.5
> Severity: normal
>
> Since some time, the rred phase during aptitude/apt-get update is very
> slow and produces very high system cpu-load.
>
> Today I managed to get an strace of the relevant process (the one
> matched by "pgrep -f rred", I don't know the exact name right now). It
> does stuff like this:
>
> 2572 read(3, "P", 1) = 1
> 2572 read(3, "a", 1) = 1
> 2572 read(3, "c", 1) = 1
> 2572 read(3, "k", 1) = 1
> 2572 read(3, "a", 1) = 1
> 2572 read(3, "g", 1) = 1
> 2572 read(3, "e", 1) = 1
> 2572 read(3, ":", 1) = 1
> 2572 read(3, " ", 1) = 1
> 2572 read(3, "o", 1) = 1
> 2572 read(3, "p", 1) = 1
> 2572 read(3, "e", 1) = 1
> 2572 read(3, "n", 1) = 1
> 2572 read(3, "s", 1) = 1
> 2572 read(3, "l", 1) = 1
> 2572 read(3, "i", 1) = 1
> 2572 read(3, "d", 1) = 1
> 2572 read(3, "e", 1) = 1
> 2572 read(3, "-", 1) = 1
> 2572 read(3, "p", 1) = 1
> 2572 read(3, "y", 1) = 1
> 2572 read(3, "t", 1) = 1
> 2572 read(3, "h", 1) = 1
> 2572 read(3, "o", 1) = 1
> 2572 read(3, "n", 1) = 1
> 2572 read(3, "\n", 1) = 1
> 2572 write(4, "Package: openslide-python\n", 26) = 26
> 2572 read(3, "B", 1) = 1
> 2572 read(3, "i", 1) = 1
> 2572 read(3, "n", 1) = 1
>
> Maybe buffering is disabled for some file descriptor where it should not
> be?
We in fact do not have any buffering in our file layer. gzip, lzma,
and bzip2 have some buffering; but for reading raw files, we directly
issue read() requests on a raw file descriptor from our Read()
method [which we call with size 1].
We could use a FILE* instead of a file descriptor, that would be
buffered - or we could add our own generic buffering.
(The code could also use some refactoring...)
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.
Reply to: