[Digikam-users] Digikam slow
Dotan Cohen
dotancohen at gmail.com
Fri Dec 7 20:28:14 GMT 2007
On 07/12/2007, Jakob Østergaard Hegelund <joe at evalesco.com> wrote:
> >
> > procs -----------memory---------- ---swap-- -----io---- -system--
> > ----cpu---- r b swpd free buff cache si so bi bo
> > in cs us sy id wa 4 0 29296 157788 0 598832 0 2 182
> > 41 280 292 8 1 89 2 1 0 29296 151736 0 603532 0 0
> > 3312 344 305 280 86 11 0 3 1 0 29296 146744 0 608368
> > 0 0 4628 24 318 284 96 4 0 0 2 0 29296 141880 0
>
> Your vmstat tells us:
>
> 1: During the wait, digikam is reading 5 MB/sec from your disks, and
> this is not what is limiting performance (the system is not waiting for
> the disks, the read speed is limited by other factors).
>
> 2: The limiting factor is the CPU. Digikam is waiting for the CPU. It is
> inside digikam (or whatever digikam is using) the CPU cycles are
> burnt - it is not in the kernel, for making operations on behalf of
> digikam.
So the problem is in digikam, not something else that is overloading the system?
> >
> > top - 17:43:40 up 3:12, 1 user, load average: 0.08, 0.32, 0.39
> > Tasks: 105 total, 3 running, 102 sleeping, 0 stopped, 0 zombie
> > Cpu(s): 42.9%us, 5.6%sy, 0.0%ni, 37.9%id, 0.3%wa, 12.0%hi,
> > 1.3%si, 0.0%st Mem: 970748k total, 927200k used, 43548k
> > free, 0k buffers Swap: 2562356k total, 29296k used,
> > 2533060k free, 720052k cached
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 9856 ubuntu 20 0 30300 8336 6352 S 43.5 0.9 0:03.86
> > kio_digikamthum 8205 root 15 0 99088 26m 4440 S 3.3 2.8
> > 2:37.35 Xorg 9823 ubuntu 15 0 74408 35m 26m S 2.7 3.7
> > 0:13.25 digikam 5 root 10 -5 0 0 0 S 1.0 0.0
> > 0:00.72 events/0 7927 root 18 0 2764 700 540 S 0.3 0.1
>
> Aha!
>
> So we're just waiting for thumbnails to be generated.
It certainly does feel like that's the problem as the thumbnails are
displayed very slowly, and the digikam menus are responsive during
this time. Note that the first thumbnail takes a good 5-7 seconds, and
then each thumbnail takes another half second. Running "rebuild all
thumbnails" (it takes 45 minutes) does not help.
> Isn't there a setting somewhere in digikam to cache a larger number of
> thumbnails?
I could not find such a setting in digikam, but I set KDE to the max
at 100 MB. It did not help so far as I could tell.
> >
> > root at ubuntu-desktop:~# cat /proc/cpuinfo
> > processor : 0
> > vendor_id : AuthenticAMD
> > cpu family : 6
> > model : 7
> > model name : AMD Duron(tm) Processor
> > stepping : 1
> > cpu MHz : 1300.075
> > cache size : 64 KB
> > fdiv_bug : no
> > hlt_bug : no
> > f00f_bug : no
> > coma_bug : no
> > fpu : yes
> > fpu_exception : yes
> > cpuid level : 1
> > wp : yes
> > flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
> > cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts
> > bogomips : 2602.01
> > clflush size : 32
>
> Ok; this is not really a slow CPU but on the other hand I don't think
> anyone will get lost inside its cache either... ;)
I was also surprised to see 64 KB. Can that really be?
> > root at ubuntu-desktop:~# cat /proc/interrupts
> > CPU0
> > 0: 2910186 XT-PIC-XT timer
> > 1: 12 XT-PIC-XT i8042
> > 2: 0 XT-PIC-XT cascade
> > 5: 0 XT-PIC-XT ohci_hcd:usb2
> > 6: 5 XT-PIC-XT floppy
> > 8: 3 XT-PIC-XT rtc
> > 9: 0 XT-PIC-XT acpi
> > 10: 21134 XT-PIC-XT ehci_hcd:usb1, eth0, Ensoniq
> > AudioPCI 11: 55926 XT-PIC-XT ohci_hcd:usb3
> > 12: 112 XT-PIC-XT i8042
> > 14: 149160 XT-PIC-XT libata
> > 15: 125686 XT-PIC-XT libata
> > NMI: 0
> > LOC: 0
> > ERR: 0
> > MIS: 0
>
> Good; things look normal.
>
> ...
> > root at ubuntu-desktop:~# cat /proc/mtrr
> > reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1
> > reg01: base=0x20000000 ( 512MB), size= 256MB: write-back, count=1
> > reg02: base=0x30000000 ( 768MB), size= 128MB: write-back, count=1
> > reg03: base=0x38000000 ( 896MB), size= 64MB: write-back, count=1
> > reg04: base=0xc0000000 (3072MB), size= 64MB: write-combining,
> > count=1 reg07: base=0xd0000000 (3328MB), size= 256MB:
> > write-combining, count=1 root at ubuntu-desktop:~#
> >
>
> Hmm funny, you have two WC regions. Do you have two graphics cards in
> this system?
No, I don't think that there is even an AGP port on the motherboard.
Just an onboard VGA-out port.
> Anyway, this looks good too; if you had a region of system memory that
> was not set to write-back, then that could explain why your system
> would crawl for no apparent reason - bad cache settings is not the
> explanation.
How can I check about write-back. I'll start googling, but I've never
confronted the term until now.
> Is there anyway to cache more thumbnails? I think that would be the
> explanation :)
I'd like to know, too.
Note that digikam isn't even making an effort to make the thumbnails
in a directory (album) that is open if the thumbnail is not currently
displayed. That means that if I have 500 photos in an album, and the
pane only shows 16 thumbnails, digikam only prepares 16 thumbnails,
even if I leave her open for a few minutes. When I scroll down, I must
wait as each thumbnail is created.
While googling, I came across this:
http://rudd-o.com/archives/2007/10/02/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that/2/
Might that be relevant? Should I try writing vm.swappiness=1 to
/etc/sysctl.conf? What side effect might that have?
Thanks!
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
More information about the Digikam-users
mailing list