pacman -Syu with 3.4 is very slow

anonymous_user · 2010-07-03 16:33:43

I think that message means you have an out-of-date mirror since VLC 1.1.0 is already in extra. You can use reflector to generate a good mirrorlist.

lilsirecho · 2010-07-05 03:16:38

Mirrors fixed..perhaps.

Strange behavior of pacman download... -Syu

Gross download of kde 264Mb among others..

Pacman takes 12 secs between downloads, as follows;

for five seconds ..nada...then 2 second burst...then 5 seconds of nada ...followed by the download.

Pattern repeats throughout the massive download.

Pacman hangs at end of install of all packages.

Had to X it out.

al3xis999 · 2010-07-05 09:01:29

Try pacman-cage from AUR

maxi_jac · 2010-07-06 17:15:46

I've done some tests :

For an up to date system (no upgrade actually processed) and a reboot between each (done in console, nothing stressing the CPU/disk in background, run right after boot so that caches are almost in the same state):

Laptop :
pacman -Syu : 1 min 34 sec
pacman -Syyu : 40 sec

Well... -Syyu is now more efficient than -Syu *in some cases*.

I've done some more tests with my desktop too, and it was way less flagrant (Syu in some cases quicker than -Syyu), because my hard drive is recent and quick.

What I can conclude now :
if pacman -Syy has been run not much before, it will be quick ( same for pacman-optimize I think)
but in most cases, if you have a relatively slow hard disk (like those in laptops), I think that -Syyu is a better choice than -Syu

The only thing I wonder is : Why reading "fragmented" data is slower than downloading, decompressing and writing files from a tarball ? it seems a bit weird.

Lars Stokholm · 2010-07-15 17:47:01

Here, on a Thinkpad T500, pacman -Syu completes in just over a minute while pacman -Syyu completes instantly under the exact same conditions: No new packages, pacman-optimize then reboot and finally pacman -Sy(y)u. I'm doing pacman -Syyu from now on.

It's seems like a very, very poor trade-off, saving a little bandwidth for this much time and other system resources, especially these days where bandwidth is thrown at you by providers.

Allan · 2010-07-16 04:26:24

allan@mugen ~ 
> su -c "sync; echo 3 > /proc/sys/vm/drop_caches"
Password: 

allan@mugen ~ 
> time pacman -Syu
:: Synchronizing package databases...
 kernel64 is up to date
 testing is up to date
 core is up to date
 extra is up to date
 community-testing is up to date
 community is up to date
:: Starting full system upgrade...
 there is nothing to do

real    0m16.462s
user    0m0.600s
sys    0m0.763s

And updating my four chroots (testing/not-testing i686/x86_64):

allan@mugen ~ 
> su -c "sync; echo 3 > /proc/sys/vm/drop_caches"
Password: 

allan@mugen ~ 
> time update_chroots 
<snip>

real    0m14.045s
user    0m0.170s
sys    0m0.290s

on a 5400 rpm hard-drive.

Quick enough for me... I wonder why no-one complaining about speed has jumped on the pacman-dev list offering to help fix the issue.

Lars Stokholm · 2010-07-16 08:24:26

Same conditions as before:

[root@thinkpad ~]# sync; echo 3 >/proc/sys/vm/drop_caches
[root@thinkpad ~]# time pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
:: Starting full system upgrade...
 there is nothing to do

real    1m2.907s
user    0m0.567s
sys    0m0.810s

On a 7200rpm hard drive. Not quick enough for me.

Allan wrote:

I wonder why no-one complaining about speed has jumped on the pacman-dev list offering to help fix the issue.

Because what I have been hearing up until now is, that there is no issue. Also I didn't even know Arch had mailing lists. Anyway, I can't program and I don't know much about caches and databases, but I'll be glad to help with all that I can.

Last edited by Lars Stokholm (2010-07-16 11:21:16)

JackH79 · 2010-07-16 08:45:48

Only now noticed that I've got the same problem (usually I just start the update, do something else, and then come back to it later).

My times:

# time pacman -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
local is up to date
:: Starting full system upgrade...
 there is nothing to do
pacman -Syu 0.40s user 0.62s system 1% cpu 1:20.53 total

after a reboot.
I optimise and sync my database regularly and
I don't think that my hard drive speed is responsible.

JackH79 · 2010-07-16 08:46:23

Sorry. This was a double post by accident.

Last edited by JackH79 (2010-07-16 08:47:18)

siriusb · 2010-07-16 17:55:20

I have the same problem as others, pacman -Syu (after optimization, too) is very slow, and a pacman -Ss xyz got slow as well after upgrading to pacman 3.40.
If you need any details, pls let me know.

graysky · 2010-07-20 08:43:40

+1 for the slow down... did anyone open a flyspray task on this issue?

# sync
# echo 3 > /proc/sys/vm/drop_caches
# time pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
:: Starting full system upgrade...
 there is nothing to do

real    0m36.192s
user    0m0.390s
sys    0m0.033s

For me, the hardrive light is solid on the slow step which pacman reports as ":: Starting full system upgrade..." I have a SATA2 7200 RPM drive which is pretty quick on this system for /var and everything else is on an SSD (X25-M gen2). Under the older version of pacman, this sample operation took under 5 sec.

EDIT: Here, I opened a flyspray task. Please have a look, vote, add your experiences to help the devs see it.

http://bugs.archlinux.org/task/20233

Last edited by graysky (2010-07-20 08:50:56)

Allan · 2010-07-20 10:45:00

graysky wrote:

EDIT: Here, I opened a flyspray task. Please have a look, vote, add your experiences to help the devs see it.

Please do not add you experiences. We know about the issue and a bug report full of "me too"'s just makes any real information in the report hard to find.

BTW, we are already working on the issue. Changing how we store the sync dbs takes the reading of the entire [extra] database from 27.9sec to 0.25sec. See http://bugs.archlinux.org/task/8586#comment63522 .

graysky · 2010-07-20 20:30:37

Thanks, Allan. Glad to hear you guys are on it!

graysky · 2010-11-04 08:44:20

@Allan - I noticed that 8586 was implemented on 14-Oct. Is it a matter of time before we see a difference in the speed of a pacman -Syu as a function of these changes? It's not clear to me when the modifications will make it into production from the bug report.

Thanks!

Allan · 2010-11-04 08:50:52

You will see them whenever we release pacman-3.5... which has no schedule and is probably still a few months away.

graysky · 2010-11-04 19:47:55

Cool, thanks for the update.

Radioactiveman · 2010-11-06 18:55:03

I tested pacman-git today because I started this thread.
The performance increased a lot, good job.

Allan · 2010-11-06 22:27:21

I have some other patches on my git working branch which will boost speed even more!

Arch Linux

#26 2010-07-03 16:33:43

Re: pacman -Syu with 3.4 is very slow

#27 2010-07-05 03:16:38

Re: pacman -Syu with 3.4 is very slow

#28 2010-07-05 09:01:29

Re: pacman -Syu with 3.4 is very slow

#29 2010-07-06 17:15:46

Re: pacman -Syu with 3.4 is very slow

#30 2010-07-15 17:47:01

Re: pacman -Syu with 3.4 is very slow

#31 2010-07-16 04:26:24

Re: pacman -Syu with 3.4 is very slow

#32 2010-07-16 08:24:26

Re: pacman -Syu with 3.4 is very slow

#33 2010-07-16 08:45:48

Re: pacman -Syu with 3.4 is very slow

#34 2010-07-16 08:46:23

Re: pacman -Syu with 3.4 is very slow

#35 2010-07-16 17:55:20

Re: pacman -Syu with 3.4 is very slow

#36 2010-07-20 08:43:40

Re: pacman -Syu with 3.4 is very slow

#37 2010-07-20 10:45:00

Re: pacman -Syu with 3.4 is very slow

#38 2010-07-20 20:30:37

Re: pacman -Syu with 3.4 is very slow

#39 2010-11-04 08:44:20

Re: pacman -Syu with 3.4 is very slow

#40 2010-11-04 08:50:52

Re: pacman -Syu with 3.4 is very slow

#41 2010-11-04 19:47:55

Re: pacman -Syu with 3.4 is very slow

#42 2010-11-06 18:55:03

Re: pacman -Syu with 3.4 is very slow

#43 2010-11-06 22:27:21

Re: pacman -Syu with 3.4 is very slow

Board footer