Re: Slow package database
On Mon, 2 Apr 2007 11:10:55 +0200 Christoph Haas <[EMAIL PROTECTED]> wrote: > Is there anything that I can do about it? Tuning the ext3 partition? Or is > somebody capable of turning the info directory into - say - an sqlite > database or in future Debian releases? There is a thread on debian-dpkg about this, even with a proof of concept: http://people.debian.org/~seanius/dpkg-sqlite/ grts Tim signature.asc Description: PGP signature
Re: Slow package database
On Friday 30 March 2007 22:25, Florian Weimer wrote: > * Christoph Haas: > > What might be the cause? Is there some fragmentation effect? > > It's probably ext3's directory hashing. It tries to access the files > in /var/lib/dpkg/info in hash order, which leads to essentially random > disk I/O. I think you are right. It's ext3 here. And I just "cp -a" the info directory and now everything is amazingly fast. Although copying the directory took half a minute. Is there anything that I can do about it? Tuning the ext3 partition? Or is somebody capable of turning the info directory into - say - an sqlite database or in future Debian releases? Cheers Christoph -- ~ ~ ".signature" [Modified] 1 line --100%--1,48 All -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slow package database
On Fri, Mar 30, 2007, Adam Borowski wrote: > > Indeed it accounts for some part of the problem; after I cloned and > > replaced my /var/lib/dpkg/info tree with the copy, the figure dropped > > from 22 seconds to 15 seconds. > It's not that. It's /var/lib/dpkg/available. Err, I timed before and after the change and resetted the caches before each test; I copied /var/lib/dpkg/info with "cp -a" and saw the difference mentionned above after the copy. How would /var/lib/dpkg/available be of any significance in my scenario? -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slow package database
* Adam Borowski: > On Fri, Mar 30, 2007 at 08:57:03PM +0200, Loïc Minier wrote: >> Indeed it accounts for some part of the problem; after I cloned and >> replaced my /var/lib/dpkg/info tree with the copy, the figure dropped >> from 22 seconds to 15 seconds. > > It's not that. It's /var/lib/dpkg/available. Not in my experience on ext3. Putting the contents of /var/lib/dpkg/info into the cache makes dpkg -i instantaneous.
Re: Slow package database
On Fri, Mar 30, 2007, Adam Borowski wrote: > On Fri, Mar 30, 2007 at 08:57:03PM +0200, Loïc Minier wrote: > > Indeed it accounts for some part of the problem; after I cloned and > > replaced my /var/lib/dpkg/info tree with the copy, the figure dropped > > from 22 seconds to 15 seconds. > > It's not that. It's /var/lib/dpkg/available. Which is totally unnecessary in most cases. See #397121, unanswered for months and with a patch. (If anyone addresses that bug, please also have a look at #395140). Cheers, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slow package database
> "Roberto" == Roberto C Sánchez <[EMAIL PROTECTED]> writes: > Interesting. I have ~1600 packages installed on my development machine > and I do not experience the slowness you talk about. It was installed > about 3.5 years ago. > How much RAM/CPU does the machine have? How fast are the disks? I have a Athlon X2 3800+ with 2Gig of RAM. To install a single package it takes 10s real time. I have a SATA 250GB disk. I have ~1500 packages installed. On a 2.8 Ghz P4 with 512MB RAM (~1800 packages) it does take 20-30 seconds. I also note that dselect eats up 40+ MB on this second machine and really slows down the machine during an install. -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slow package database
On Fri, 30 Mar 2007, Adam Borowski wrote: > It's not that. It's /var/lib/dpkg/available. > > Try this: > > for x in /var/lib/apt/lists/*Packages;do dpkg --merge-avail "$x";done > (or "dselect update") > Install+purge of an empty package: > 9-ish seconds on one box (my home desktop, years of use) > 6-ish seconds on another (a slow server) > > dpkg --clear-avail > Install+purge of an empty package: > 0.182s on the slow server > 3ish seconds on the desktop > > The difference between those 0.182s and 3s is due to removed and even purged > packages staying in the available file. Hmm. I've been wondering why upgrades seemed to take so long on my shiny new desktop... Here's a couple more data points for a 2GB/AMD64 box running 2.6.19.2 with and ext3 filesystem. My test package was the sid/etch ethereal 'dummy' package. Original baseline: % time (apt-get -y install ethereal && apt-get -y remove ethereal) [ . . . ] real 0m10.729s user 0m6.692s sys 0m1.224s I threw out the first couple iterations after which these timings were consistent to +- 0.1s across 5 subsequent samples. Now, I blow away my (22 MB) /var/lib/dpkg/available file: % dpkg --clear-avail % time (apt-get -y install ethereal && apt-get -y remove ethereal) [ . . . ] real 0m6.492s user 0m4.124s sys 0m0.800s I threw out the first couple iterations after which these timings were consistent to +- 0.1s across 5 subsequent samples. --> Result: 40% faster with an empty 'available' file. On a whim I enabled dir_index on my ext3 FS, _and_ rebuilt info/: % cd /var/lib/dpkg/ % cp -a info info.tmp % mv info info.orig % mv info.tmp info I gather that should both defrag the info files (FWIW), and rebuild the director using the hashed b-trees. (I don't see how the hashed b-trees could impact this particular test, but what the hell...) Then I redid the timing test: %time (apt-get -y install ethereal && apt-get -y remove ethereal) [ . . . ] real 0m6.847s user 0m4.100s sys 0m0.776s --> Result: No difference at all this time... Then I replaced the 'available' file with an archived version and ran the test again: %time (apt-get -y install ethereal && apt-get -y remove ethereal) [ . . . ] real 0m10.869s user 0m6.592s sys 0m1.228s --> Result: right back to the original (slow) baseline times Looks like '/var/lib/dpkg/available' is the main culprit here. (I wish I could test the same setup on a different filesystem like JFS though...) -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slow package database
* Christoph Haas: > What might be the cause? Is there some fragmentation effect? It's probably ext3's directory hashing. It tries to access the files in /var/lib/dpkg/info in hash order, which leads to essentially random disk I/O. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slow package database
On Fri, Mar 30, 2007 at 08:57:03PM +0200, Loïc Minier wrote: > Indeed it accounts for some part of the problem; after I cloned and > replaced my /var/lib/dpkg/info tree with the copy, the figure dropped > from 22 seconds to 15 seconds. It's not that. It's /var/lib/dpkg/available. Try this: for x in /var/lib/apt/lists/*Packages;do dpkg --merge-avail "$x";done (or "dselect update") Install+purge of an empty package: 9-ish seconds on one box (my home desktop, years of use) 6-ish seconds on another (a slow server) dpkg --clear-avail Install+purge of an empty package: 0.182s on the slow server 3ish seconds on the desktop The difference between those 0.182s and 3s is due to removed and even purged packages staying in the available file. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slow package database
On Fri, Mar 30, 2007, Joey Hess wrote: > It can also lead to a kind of "fragmentation", since during an initial > install these files tend to be fairly close together on disk while over > time new files will be scattered about and more seeking needed to read > them all. Indeed it accounts for some part of the problem; after I cloned and replaced my /var/lib/dpkg/info tree with the copy, the figure dropped from 22 seconds to 15 seconds. I suppose a cache would nevertheless address both problems. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slow package database
Hi, * Loïc Minier <[EMAIL PROTECTED]> [2007-03-30 20:29]: > On Fri, Mar 30, 2007, Christoph Haas wrote: > > It appears like apt-get/aptitude/dpkg dealing with the list/database of > > installed packages is terribly slow at times. > > I think dpkg spends a lot of time reading all /var/lib/dpkg/info/*.list > files. These are not big and this is typically in cache between dpkg > runs, and I think this is the reason that cold dpkg runs are very very > slow. > > I tested by stracing dpkg -i on a small .deb after sync && echo 3 > > /proc/sys/vm/drop_caches, and from a 24 seconds run, 22 seconds were > spent reading *.list files. Yes I experienced the same while doing a bit of stracing on dpkg. I wondered that it reads the whole info list even if you just remove a single package. Kind regards Nico -- Nico Golde - http://www.ngolde.de JAB: [EMAIL PROTECTED] - GPG: 0x73647CFF Forget about that mouse with 3/4/5 buttons, gimme a keyboard with 103/104/105 keys! pgpxZM21H0bvo.pgp Description: PGP signature
Re: Slow package database
Loïc Minier wrote: > I think dpkg spends a lot of time reading all /var/lib/dpkg/info/*.list > files. These are not big and this is typically in cache between dpkg > runs, and I think this is the reason that cold dpkg runs are very very > slow. It can also lead to a kind of "fragmentation", since during an initial install these files tend to be fairly close together on disk while over time new files will be scattered about and more seeking needed to read them all. -- see shy jo signature.asc Description: Digital signature
Re: Slow package database
On Fri, Mar 30, 2007, Christoph Haas wrote: > It appears like apt-get/aptitude/dpkg dealing with the list/database of > installed packages is terribly slow at times. I think dpkg spends a lot of time reading all /var/lib/dpkg/info/*.list files. These are not big and this is typically in cache between dpkg runs, and I think this is the reason that cold dpkg runs are very very slow. I tested by stracing dpkg -i on a small .deb after sync && echo 3 > /proc/sys/vm/drop_caches, and from a 24 seconds run, 22 seconds were spent reading *.list files. (A subsequent run took in the order of 1 second.) Perhaps someone with elite dpkg skillz will implement some form of cache for these? :-) NB: I have 227524 files in 1801 packages. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slow package database
debian sid installed about 9 years ago, actually on amd64 (but with 32bit kernel and 32bit userland ) sempron 3300+ with 1 gigs of ram. The system is on a dm-crypted in aes256 device over software raid1 composed by two slow ide disks, (so, I/O is *VERY* slow), i have something like 2500 packages installed. To install from local disk a simple fake package that just put an empy file on /tmp/: real0m5.499s user0m0.512s sys 0m0.200s -- Franco (nextime) Lanza Busto Arsizio - Italy SIP://[EMAIL PROTECTED] NO TCPA: http://www.no1984.org you can download my public key at: http://danex.nexlab.it/nextime.asc || Key Servers Key ID = D6132D50 Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 --- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc --- signature.asc Description: PGP signature
Re: Slow package database
On 3/30/07, Christoph Haas <[EMAIL PROTECTED]> wrote: what has always annoyed me is now ready to be asked on this list. :) It appears like apt-get/aptitude/dpkg dealing with the list/database of installed packages is terribly slow at times. I have roughly 1800 packages installed and it sometimes takes 20-30 seconds to install a single package I've experienced this myself, so much that I'm about to change my perfectly working IDE disk for a SATA disk with the intent of fixing this. On my attempts to fix this, I changed some of the HD parameters, and it improved a bit, but not completely. My only guess about why this happens is that at some point the hard-drive was a bit too-full, so that it started to become fragmented, and the package db never de-fragmented, even if I later emptied the disk. This is just a wild guess. It might be something completely different. -- Besos, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slow package database
On Fri, Mar 30, 2007 at 04:11:46PM +0200, Christoph Haas wrote: > On Friday 30 March 2007 15:43, Roberto C. Sánchez wrote: > > On Fri, Mar 30, 2007 at 03:39:29PM +0200, Christoph Haas wrote: > > > It appears like apt-get/aptitude/dpkg dealing with the list/database > > > of installed packages is terribly slow at times. > > > > Interesting. I have ~1600 packages installed on my development machine > > and I do not experience the slowness you talk about. It was installed > > about 3.5 years ago. > > > > How much RAM/CPU does the machine have? How fast are the disks? > > RAM: 1 GB > CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz > Kernel: 2.6.18-3-686 > Disk: ~ 20 MB/sec (if I read the bonnie++ numbers correctly) > > Christoph Hmm. I have 1.5 GB RAM, 1.8 GHz Athlon XP and a 2.6.16 or 2.6.17 kernel. My disks are a little faster, but not much. I wonder if something else is slowing you down. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Slow package database
On Friday 30 March 2007 15:43, Roberto C. Sánchez wrote: > On Fri, Mar 30, 2007 at 03:39:29PM +0200, Christoph Haas wrote: > > It appears like apt-get/aptitude/dpkg dealing with the list/database > > of installed packages is terribly slow at times. > > Interesting. I have ~1600 packages installed on my development machine > and I do not experience the slowness you talk about. It was installed > about 3.5 years ago. > > How much RAM/CPU does the machine have? How fast are the disks? RAM: 1 GB CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz Kernel: 2.6.18-3-686 Disk: ~ 20 MB/sec (if I read the bonnie++ numbers correctly) Christoph
Re: Slow package database
On Fri, Mar 30, 2007 at 03:39:29PM +0200, Christoph Haas wrote: > Dear list... > > what has always annoyed me is now ready to be asked on this list. :) > It appears like apt-get/aptitude/dpkg dealing with the list/database of > installed packages is terribly slow at times. I have roughly 1800 packages > installed and it sometimes takes 20-30 seconds to install a single > package. On a freshly installed system that's just a matter of seconds. > Since this is one of my two development workstations I uninstall and > install a lot of packages and dist-upgrade to unstable/experimental daily. > So the package database is in permanent flux. What might be the cause? Is > there some fragmentation effect? This is a common effect on a few Debian > systems here so I assume I'm not alone with it. Has anyone else observed > that? Is there a way to optimize it? > Interesting. I have ~1600 packages installed on my development machine and I do not experience the slowness you talk about. It was installed about 3.5 years ago. How much RAM/CPU does the machine have? How fast are the disks? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
