[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