Arch Linux

personally i have never noticed this but I have a swap .... i never go without a swap. i have 1gb of ram and still set up a swap because it always get used. i never have more than 256 mb of swap.

yeah. that's what I said ;P
without swap you system seems like it hanged

If you have 256 megs of RAM you should have a swap partition on a "bleeding edge" disto anyway - this is a error in the choices made during installation and not a bug.

Pacman's database uses a large number of small files. On some filesystems, small files are exceptionally prone to fragmentation. If pacman has not been run in awhile, these files will not be cached. If the files are fragmented, pacman needs to seek all over the disk to read them all.

There are hacks to get around this, but they are indeed hacks and probably not a good idea to implement in the mainstream. A better solution would be a new database format, but I'm not sold on that idea yet.

well I don't know, and this is not too high, but soon we'll be having a lot non-swap filesystems. I'm using reiser3 btw. Thank you Judd for being so descriptive. Thanks indeed!

it's been ages and this one is open.

I am less an less impressed with pacman as time goes by. The more packages I have installed, the slower the post-install CHUG-CHUG-CHUG takes. At first it was lightning fast, way more-so than Debian's apt. Now with a complete set of apps installed, it is 5-10 times slower than Debian ! It often spents a solid 30 seconds to 1 minute of chugging even for installing a single small app, very disruptive to overall system performance -- and I have a gig of swap and 3/4 gig of RAM !

Anything that can be done to improve the performance of the package installation should be done.

hey Raven,
CHUG-CHUG is the noise of the HD?

I'm not an expert, but what else can be done there? maybe use sqlite.. [what that make it faster than scanning for files in directories] I don't know :)

maybe if soon we have a libpacman, the devs of this magnificent tool, can focus on making the lib faster and/or making the CLI faster

"CHUG-CHUG is the noise of the HD?"

Yes, the very audible sound of the hard drive servos moving. The IDE hard drive causes system lag as it labours away, eating up CPU time by waiting for system I/O to complete. Unless you're blessed with SCSI, hard drives needing to randomly seek hundreds of small files which may be anywhere at all on the physical hard drive platters, is quite slow and ineffective.

Blocks of one file are very unlikely to be fragmented, when compared to reading in randomly created, individual files.

Using sqlite or even just a big text file (wherein you write changes to a new file, and only then overwrite the old file with the new one, thereby making sure you never lose your whole data file accidentally) would be incredibly faster.

The amount of data is not the problem here at all, it is only a few MB worth of data. If that was unfragmented on the disk (in a line of blocks on the filesystem, one after the other) it would take only a couple seconds to read, none of this 30 or more seconds you often get once you have a lot of installed packages.

what filesystem are you using ??

I don't know if you ask me. I 'm using reiser3

Arjan Timmerman, if you were asking me, ReiserFS 3.6 currently. The problem only crops up once you install hundreds of packages, which then have to be slowly scanned every time you install a package.

Maybe there's a way to defragment volumes?

What does 'hdparm -c -d /dev/hdX' say?

Christer Solskogen:

This has nothing whatsoever to do with hard drive settings. Arch Linux opens hundreds if not thousands of files when you run the "pacman" command. It is inefficient.

Glenn Matthys:
This isn't NTFS or FAT32 ! ReiserFS and Ext filesystems don't defragment like that. This is inefficient coding.

Glenn Matthys,
I'm speaking for my self and not myself. I opened this bug report. I like /trust Judd.

to say that it's "inefficient coding" means you know the parts of the code that need to be fixed. So why don't you be a good boy and send a patch to Judd? Either that, or stop "This isn't NTFS or Fat32 [..] this is ineffience coding." ok?
TY

ps. I don't know you, neither Judd. So PEACE

#FIXME:
not myself --> only for myself

Nikos Kouremenos:

I think you were talking to me and not Glenn Matthys, I am the one that said it is inefficiently coded. The thing about filesystems was to someone that said perhaps the drive is fragmented ! Please re-read the posting, I specified who each comment was aimed at.

I am not talking out of my ass when I say that pacman is inefficiently coded. I just checked, and on my system pacman opens up a minimum of over one thousand data files every single time it is run:

strace pacman -Qo /usr/bin/mplayer 2>&1|grep 'open("/var/lib/pacman'|wc --lines

1065

Of course the *second* time you run pacman, it will have those 1000+ files in Linux's RAM cache, so it will be speedy, but the first time you run it, it is quite slow and chugs the hard drive a lot with all the random seeks performed.

Also, it is far slower when installing a large group of packages, as every one of them *repeats* these checks every time ! After extracting these files the RAM cache won't even be there anymore, so it will be reading them off the disk ... again, again, again and again.

Okay, I just downloaded packages from a pacman -Suy without installing any of them, and now I am going to check how many files are opened during an average update:

time strace pacman -Suy --noconfirm 2>&1|grep 'open("'>/Raven/strace.log

My /Raven directory is on a separate partition on a separate IDE cable, so writing out the log there will cause almost no performance hit.

My computer specs:

Athlon XP 1800+, 1625Mhz, 256KB cache, 3203 BMIPs
512MB PC3200 DDR SDRAM
Linux kernel 2.6.11.3

Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 128).
PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (rev 0).
IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 6).
ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] (rev 0).

Anyhow, it is done now:

real 19m35.412s
user 2m53.153s
sys 3m34.835s

So it took just under 20 minutes to update -- and here is the scary part:

-rw-r--r-- 1 root root 35M Mar 15 17:21 /Raven/strace.log

grep /var/lib/pacman /Raven/strace.log|wc --lines

404501

It opened nearly half a million package description files ! Over four hundred thousand random hard drive seeks. My "/" partition is on a fairly modern 7200RPM, 60GB hard drive, if I had a Pentium II system with a 4500RPM drive and 192MB RAM, this update would easily have taken several hours.

It is unthinkable to reload the package dependancy data over and over and over like this. Stick it into a data structure in pacman's RAM usage, recall it from RAM. Even if this data has to be swapped out to disk, it will still recall it in a contiguous block from disk in under a second, as opposed to reading over 1000 different parts of the hard drive at random which takes several seconds.

Another unrelated efficiency note:

Pacman does not use a keepalive connection, it severs the HTTP or FTP connection after every file it downloads. This is especially noticeable when downloading 5 or 10 small files -- it takes longer to connect to the server for each file than it takes to download it.

If you are going to respond with "we can't stick it in RAM, that would use a lot of RAM", then simply tar it up in /tmp and delete it afterward. That way it would be one contiguous hard drive read, not 1000+ random seeks.

Actually, the [very crazy] default for Arch Linux is to use a RAM-based virtual partition for /tmp, so it would be sticking that tar file into RAM or swap anyhow.

I just checked and it is not actually much RAM at all -- the files are incredibly tiny:

tar cf test.tar /var/lib/pacman/{current,extra}

-rw------- 1 raven users 4.4M 2005-03-15 19:32 test.tar

Pacman is already using 20 to 40MB RAM, so another ~5MB to store these data structures is definitely peanuts.

We talked about it with jan and judd a few days ago on another bug report (after I experienced immense slowness as well), and the general idea is that the next pacman will/should go with either BDB4 or SQLite3. Under no circumstances it should still be using flat files though.

this is not to say that some architecture problems won't need fixing yway, as Raven pointed out with his tests.

I just tried 'strace pacman -Qo /usr/sbin/httpd 2>&1|grep 'open("/var/lib/pacman'|wc --lines' that gives the output of "0" - Are you sure your machine isnt dying?

Bugger! I didnt have strace installed. With strace install I get this this output:
strace pacman -Qo /usr/sbin/httpd 2>&1|grep 'open("/var/lib/pacman'|wc --lines
401

hmm. ok what raven says *now* I like it.
Eugenia, (or judd or jan) how soon should we expect this

I'm seperating the KEEP ALIVE thing, which is really really annoying in a new bug report
thank you all {and especialy Raven}

The static library of Berkely db is about 1 Mb big, SQLite3's is about 300 Kb big, and tiny db's (tdb) is 33 Kb big. I'd use tdb, even if searching can be done less easily and efficiently, the whole database is small enough to fit in ram and when it's in ram searching is fast enough anyway. The main problem is getting the db in ram, but that's fixed when it's only one file.

Another possiblity is to keep the files in the tar, without changing the current db format, and to use libtar's API to access the files.

The important thing is to switch to one file instead of many small ones, which causes a seek nightmare, so changing the db format so that it's only one file will fix the problem too. Using multiple files and directories has only an advantage if you don't read all files like Pacman does. But if the db becomes too big to store into memory then it's also too big to download each time, and then another solution is needed anyway.

About saving the database in a tar: Hum, correct me if I'm wrong, but isn't all the repos-indexes already stored in a tar file? As I see it: zap the tar down to a local directory, read the tar structures from each repos, and merge in memory as someone suggested, and ZAP. Should read the entire DB into a couple of megs in RAM in under a second?

As of seeking, to see the importance of a seek-times. Take an average low-spec drive such as my 7200RPM IBM drive. It happily reads around 40mbyte/second, in a contiguous block. The average seek is 7.2msec. 40mbyte/sec * 7.2msec = 288 kilobyte/seek! So in about the time of 10 hd seeks we could instead have read the entire pacman database.

So for a pacman database of 3 megabytes, it would take under 100msec to read from disk, and probably add another 50 msec for parsing the data into useful structures. Add some various overhead, and it's remarkable that reading the database ever takes more than half a second.

However, the database itself is hardly the only I/O hog in pacman though. I've performed some tests on async I/O and I estimate fs-conflicts could be performed around 3 times faster on average if they used async I/O and let the disk scheduler work, instead of the current synchronous solution. But that's a completely other topic.

Well, that's my five cents. And sorry for repeating and restating the obvious.

So, a year and a half later... and status is still unconfirmed? *bump* to say the least.

I'd choose SQLite 3 instead of Tiny DB (what is it? can you give a link?). It gives the power of SQL to Pacman, allows transactions, and has CLI which makes it easy scriptable (some abstract sctipts layer top of SQLite CLI will make things even easier for those who wants to interact with package database from shell scripts).

Nikos,

I was in the same trouble, but when I stopped mounting my /var partition (reiser3) with the notail option, pacman's performance improved a lot.

Hey guys, pacman now ships with pacman-optimize which basically forces the flat-files database to defragment by copying/removing/copying back the database. It should help with this somewhat, give it a try.