[arch-general] pacman too slow on reboot
Hi, Recently I'm facing a funny problem. pacman (and even packer) is toooo slow to search -Ss (db+aur) or -Qs (db). I see a lot of HDD activity going on. But when I run pacman-optimize, it gets fixed. This happens at every boot. Any ideas ? -- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com
On Wed, Feb 10, 2010 at 12:49 PM, Nilesh Govindarajan
Hi,
Recently I'm facing a funny problem. pacman (and even packer) is toooo slow to search -Ss (db+aur) or -Qs (db). I see a lot of HDD activity going on. But when I run pacman-optimize, it gets fixed.
This happens at every boot. Any ideas ?
I suggest you look this: http://bbs.archlinux.org/viewtopic.php?id=20385 It uses one single file to store all pacman's db tree, mounting it via loop device, so it gets faster than the native filesystem. I use it and the difference is impressive. HTH. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
@all, thanks for the tip. I used ext4 for the loop's format. But anybody knows the reason behind this ? -- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com
On Thu, Feb 11, 2010 at 12:39 AM, Nilesh Govindarajan
@all, thanks for the tip. I used ext4 for the loop's format.
But anybody knows the reason behind this ?
-- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com
Can I mount /var/lib/pacman/sync as tmpfs to gain a speed up? -- """ Keep It Simple,Stupid. """ Chinese Name: 白杨 Nick Name: Hamo Homepage: http://hamobai.com/ GPG KEY ID: 0x7CA25BED KEY fingerprint = F928 DEF3 F848 A878 F7C5 8FEB 4621 8489 7CA2 5BED
Am 11.02.2010 02:28, schrieb Hamo:
Can I mount /var/lib/pacman/sync as tmpfs to gain a speed up?
Definitely, just make sure you don't do the same with local. You have to pacman -Sy after every boot, but that shouldn't be a problem.
if you use pt-pacman-cage (from pactools package on AUR), you can use this tiny optimisation: * mount /var/lib/pacman with noatime option. it will speed up read and write on the loop file.
On 10/02/2010 04:49 μμ, Nilesh Govindarajan wrote:
Hi,
Recently I'm facing a funny problem. pacman (and even packer) is toooo slow to search -Ss (db+aur) or -Qs (db). I see a lot of HDD activity going on. But when I run pacman-optimize, it gets fixed.
This happens at every boot. Any ideas ?
Pacman's package databases (located inside /var/lib/pacman) are composed of many small files. Going through all of those files requires lots of read operations from the disk, which as you've noticed take a non-trivial amount of time (maybe several seconds). These files are then cached in memory and subsequent pacman operations are very fast. When you perform a reboot, disk cache is cleared and the files need to be accessed from the disk again. There has been discussion [1] about using a single tarball or an sqlite3 database for storing the package databases (maybe except the local one which is generally not that big). However, I'm not aware of any definite, reliable solution that has been developed yet. ---- [1] http://bugs.archlinux.org/task/8586
On Wed, Feb 10, 2010 at 9:49 AM, Nilesh Govindarajan
Hi,
Recently I'm facing a funny problem. pacman (and even packer) is toooo slow to search -Ss (db+aur) or -Qs (db). I see a lot of HDD activity going on. But when I run pacman-optimize, it gets fixed.
This happens at every boot. Any ideas ?
-- Nilesh Govindarajan Site & Server Adminstrator www.itech7.com
Short: This happens because the pacman db isn't in the cache yet after a reboot, but after running pacman-optimize, the db is in the cache. Long: The cache is unused RAM used to store recent accessed files. When a file gets read from disk or written out to disk, it is also placed in the cache, and taken out when more memory is needed for new cache entries or applications need want more memory. Since the db is made up of a bunch of small files, this causes the hdd to have to move its arm around the disk. Linux file systems, unlike Windows, tries to reduce fragmentation by allocating space for each file evenly across the disk. The problem with this shows itself with pacman. The db files are scattered through the disk and the hdd has to seek (slow operation) to find all of them. So, once all these files are in cache, the hard drive doesn't need to be accessed to get the db. Memory is fast at random access (like the hard drive's seek operation).
I suggest you look this:
http://bbs.archlinux.org/viewtopic.php?id=20385
It uses one single file to store all pacman's db tree, mounting it via loop device, so it gets faster than the native filesystem. I use it and the difference is impressive.
HTH.
Thus, with a single file, the Linux file system will try to store it as a contiguous block on the hard drive, and the hard drive won't have to seek around, greatly increasing throughput. -- Alexander Lam
participants (7)
-
Alexander Lam
-
Denis A. Altoé Falqueto
-
Evangelos Foutras
-
Hamo
-
Nilesh Govindarajan
-
solsTiCe d'Hiver
-
Thomas Bächler