Extremely Poor Pacman/HDD Performance

Zinfidel · 2008-02-22 01:01:10

This is a problem I have been having for a while now.

After about a month after a clean Arch install, Pacman's performance, and the performance of the OS itself, severely degrades to the point of operations that took seconds taking minutes.

After a fresh install, Pacman would take about 10 seconds or so to display any matches to a search I preform. The computer now starts accessing the HDD for about 5 or 6 minutes per search, and so intensively that the rest of the computer comes to a halt while Pacman is doing it's job.

This HDD activity that completely chokes the computer is becoming more apparent in other operations as well. Firefox (which is an enormous memory hog, I know) will kill the machine. Even opening an xterminal can take about 6 or 7 seconds after some intense HDD activity.

The computer is old, a 10GB HDD, 64MB of RAM, and a 1Ghz processor, but I don't think it should be having such a hard time with the hard disk activity as it is. I run xorg7 and openbox. The only other graphical elements on that are a wallpaper and a simple panel program. There aren't many daemons running besides your run-of the-mill stuff like syslog and dbus.

I've already taken the steps in the "improving pacman's performance" article on the wiki page, but no dice. Can anyone help?

fwojciec · 2008-02-22 01:03:48

What filesystem you're using? Is it xfs by any chance?

Zinfidel · 2008-02-22 01:07:48

ext3. Can't believe I forgot to specify that!

fwojciec · 2008-02-22 01:15:07

I've never experienced anything like this. My only recommendation would be to try and switch to something like reiserfs (which is super fast when it comes to working with large numbers of small files -- like in the case of Pacman database). I have a 1.7ghz celeron laptop, which is usually throttled down to 0.6 ghz running Arch for like 8 moths and pacman operations are as fast as ever -- it uses reiserfs filesystem with noatime,notail mount options.

Maybe someone else can shed more light on your problem...

lilsirecho · 2008-02-22 03:01:47

Run dmesg |grep ata...............

Zinfidel · 2008-02-22 21:40:40

Here is the output from dmesg:

Memory: 122864k/130952k available (3158k kernel code, 7548k reserved, 1045k data, 220k init, 0k highmem)
.data : 0xc0415a96 - 0xc051af24 (1045 kB)
libata version 2.21 loaded.
ata_piix 0000:00:1f.1: version 2.12
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001bfa0 irq 14
ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001bfa8 irq 15
ata1.00: ATA-5: IBM-DJSA-210, JS2OAB8A, max UDMA/66
ata1.00: 19640880 sectors, multi 8: LBA
ata1.00: configured for UDMA/66
ata2.00: ATAPI: SAMSUNG CD-ROM SN-124, S004, max UDMA/33, CDB intr
ata2.00: configured for UDMA/33
ieee80211: 802.11 data/management/control stack, git-1.1.13
EXT3-fs: mounted filesystem with ordered data mode.

shining · 2008-02-22 22:11:12

I believe I had a similar experience :
http://www.archlinux.org/pipermail/arch … 15751.html

I had a very slow ext3 filesystem. I formated my partition in reiserfs and reinstalled, and got normal speed back.
I am still using the same install, and no performance degradations yet.
So I think I am happier with reiserfs

lilsirecho · 2008-02-22 22:44:47

The dmesg you posted is a common problem with IDE devices in the latest kernels due to the lack of recognition 0f the 80-wire cable for UDMA. The normal use of 80-wire cables in IDE was to accomodate faster transfers and as such was a weak workaround for crosstalk problems.

In present kernels, the 80-wire system is not recognized therefore the speed of performance is degraded to UDMA 2.

See the following URL for a kernel patch force for 80-wire:\\

http://pixca.net/2008/02/03/limited-to-udma33-due -to-40-wire-cable/

The results of the install to kernel are presented, but no verifiable reports have been given for the patch from other users. Two answers by the same poster give no confidence in whether he loaded the kernel fix since his dmesg makes no reference to the 80-wire libata changes as does the original posted data.

This seems to affect every IDE interface in different ways and is based on not requiring 80-wire confirmation in scsi/sata since it is different than IDE interface and controller.

This may be causing your slowdowns.....give it a second look..

fwojciec · 2008-02-22 23:03:19

@lilsirecho -- perhaps I'm misreading the dmesg output or misunderstanding the problem but it seems that the hard drive gets configured as UDMA/66 (ata1.00) and it's the CD-ROM drive that gets configured as UDMA/33 (ata2.00)...

lilsirecho · 2008-02-22 23:51:12

My oops!

lilsirecho · 2008-02-22 23:57:57

Perhaps hdparm will shed some light on the problem...

Zinfidel · 2008-02-23 08:27:17

I'm not sure what options I should be using with hdparm, but here is the output for hdparm -tT /dev/sda2

/dev/sda2:
Timing cached reads: 326 MB in 2.00 seconds = 162.66 MB/sec
Timing buffered disk reads: 24 MB in 3.15 seconds = 7.62 MB/sec

I don't think the problem is read/write times, but rather these enormous amount of HDD work even simple actions take. It feels like there is something causing the computer to do far more HDD work than it should.

shining · 2008-02-23 10:51:50

Zinfidel wrote:

I'm not sure what options I should be using with hdparm, but here is the output for hdparm -tT /dev/sda2
/dev/sda2:
Timing cached reads: 326 MB in 2.00 seconds = 162.66 MB/sec
Timing buffered disk reads: 24 MB in 3.15 seconds = 7.62 MB/sec
I don't think the problem is read/write times, but rather these enormous amount of HDD work even simple actions take. It feels like there is something causing the computer to do far more HDD work than it should.

Something like fragmentation?
Did you see my post?

noalwin · 2008-02-23 17:24:34

Have you tried pacman-optimize ?

Zinfidel · 2008-02-23 20:14:35

My initial suspicion was fragmentation as well, Shining, but upon using fsck, the machine reported 1.5% fragmentation.

I am seriously considering switching over to reiserfs to see if that makes a difference, I just have to find a backup medium first.

Yes, I have used pacman-optimize, but it didn't make any difference in pacman's speeds, unfortunately.

dyscoria · 2008-02-24 01:31:24

I have a pretty damn good dual core laptop here, and even i'm noticing the speed improvements that ReiserFS is giving! (Changed from ext3 to ReiserFS, using noatime and notail options). Pacman is even more lightning fast than before

Arch Linux

#1 2008-02-22 01:01:10

Extremely Poor Pacman/HDD Performance

#2 2008-02-22 01:03:48

Re: Extremely Poor Pacman/HDD Performance

#3 2008-02-22 01:07:48

Re: Extremely Poor Pacman/HDD Performance

#4 2008-02-22 01:15:07

Re: Extremely Poor Pacman/HDD Performance

#5 2008-02-22 03:01:47

Re: Extremely Poor Pacman/HDD Performance

#6 2008-02-22 21:40:40

Re: Extremely Poor Pacman/HDD Performance

#7 2008-02-22 22:11:12

Re: Extremely Poor Pacman/HDD Performance

#8 2008-02-22 22:44:47

Re: Extremely Poor Pacman/HDD Performance

#9 2008-02-22 23:03:19

Re: Extremely Poor Pacman/HDD Performance

#10 2008-02-22 23:51:12

Re: Extremely Poor Pacman/HDD Performance

#11 2008-02-22 23:57:57

Re: Extremely Poor Pacman/HDD Performance

#12 2008-02-23 08:27:17

Re: Extremely Poor Pacman/HDD Performance

#13 2008-02-23 10:51:50

Re: Extremely Poor Pacman/HDD Performance

#14 2008-02-23 17:24:34

Re: Extremely Poor Pacman/HDD Performance

#15 2008-02-23 20:14:35

Re: Extremely Poor Pacman/HDD Performance

#16 2008-02-24 01:31:24

Re: Extremely Poor Pacman/HDD Performance

Board footer