[Digikam-users] Digikam slow

[Jakob Østergaard Hegelund]

On Friday 07 December 2007, Dotan Cohen wrote:
...
>
> Yippie! A good wait.
>

Yeah, these exist :)

> > Please start up a konsole with 'vmstat 1' running.
> >
> > Then, open a folder/album (expected 8 second wait).
> >
> > Please send the 8 lines of output from 'vmstat 1' that appeared
> > during that 8 second wait. This will tell us if you're waiting on
> > disk or CPU or something else.
>
> 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.


> > Wait for 2 (two) updates in the 'top' konsole. Once the second
> > update occur, copy the entire konsole contents. Please send this
> > too.
>
> 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.

Isn't there a setting somewhere in digikam to cache a larger number of 
thumbnails?

...
> > Last but not least, you said everything else was slow on this
> > machine as well...  This indicates a fundamental problem - digikam
> > may be hit harder than other applications because it actually works
> > on a lot of data. Could you send the output of /proc/cpuinfo,
> > /proc/interrupts and /proc/mtrr ?
>
> 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...  ;)

...
>
> 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?

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.

Is there anyway to cache more thumbnails? I think that would be the 
explanation :)

-- 
Jakob Østergaard Hegelund