[Digikam-users] Digikam slow

Dotan Cohen dotancohen at gmail.com
Fri Dec 7 15:48:06 GMT 2007


On 04/12/2007, Jakob Østergaard Hegelund <joe at evalesco.com> wrote:
> On Friday 30 November 2007, Dotan Cohen wrote:
> > The system: Ubuntu Feisty on AMD Duron 1.3 GHz, 1GB RAM, KDE 3.5.6,
> > Digikm 0.9.2, 13,100 pictures in Digikam library which is on it's own
> > disk partition. KDE thumbnails cache opened up to 100MB.
> >
> > The problem: Digikam is so slow that it is nearly unusable. When we
> > open a folder/album in digikam we must wait 8 seconds before we see
> > thumbnails. Then, they trickle in at 0.87 sec per thumbnail (200
> > thumbnails in two minutes, 54 seconds on the clock). When a photo is
> > deleted, we wait 8 seconds before there is any UI reaction.
> >
>
> The good news is that you wait so long, so that it is possible
> to "meter" this with very simple external programs.

Yippie! A good wait.

> 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 613088    0    0  4496    12  291  212 96  4  0  0
 1  0  29296 136104      0 618548    0    0  5264    16  323  305 90  9  0  1
 1  0  29296 130272      0 624244    0    0  5432    28  303  233 95  5  0  0
 1  0  29296 124368      0 629704    0    0  5188   504  327  288 91  7  0  2
 2  0  29296 118916      0 635116    0    0  5208    88  319  270 91  9  0  0
 1  0  29296 115368      0 638548    0    0  3276     8  304  251 98  2  0  0
 1  0  29296 109652      0 643976    0    0  5260    20  299  214 94  5  0  1
 1  0  29296 105196      0 648136    0    0  3956    32  316  290 97  2  0  1
 1  0  29296 100104      0 653164    0    0  4856   252  356  290 91  9  0  0
 2  0  29296  94388      0 658624    0    0  5228   480  426  298 91  7  0  2
 1  0  29296  89812      0 662884    0    0  4044    16  289  209 94  5  0  1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 2  0  29296  85004      0 667668    0    0  4588    16  315  270 93  6  0  1
 1  0  29296  81168      0 671288    0    0  3464    84  302  271 93  7  0  0
 1  0  29296  75516      0 676748    0    0  5276   156  338  299 92  7  0  1
 1  0  29296  69800      0 682148    0    0  5232    16  300  218 94  5  0  1
 1  0  29296  66252      0 685632    0    0  3324    16  359  716 94  6  0  0
 2  0  29296  63776      0 687808    0    0  1940    24  275  271 95  5  0  0
 0  0  29296  60096      0 691188    0    0  3104    36  309  320 88  5  6  1
 0  0  29296  60096      0 691188    0    0     0   188  297  317  1  1 98  0
 1  0  29296  60080      0 691188    0    0     0     0  275  474 10  0 90  0



> Ok, now stop the 'vmstat 1' and type 'top' instead. Here we have a list
> of processes, sorted by their current CPU time consumption.
>
> Now, open a new folder/album (expected 8 second wait once again).
>
> 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   0:00.12 dirmngr
 8362 ubuntu    15   0 35936  18m  14m S  0.3  2.0   0:13.67 kicker
 9722 ubuntu    15   0 32744  14m  11m R  0.3  1.5   0:02.77 konsole
 9852 root      15   0  2316 1160  880 R  0.3  0.1   0:00.07 top
    1 root      18   0  2912 1844  524 S  0.0  0.2   0:01.53 init
    2 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
    3 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
    4 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
    6 root      10  -5     0    0    0 S  0.0  0.0   0:00.02 khelper
    7 root      14  -5     0    0    0 S  0.0  0.0   0:00.00 kthread
   30 root      10  -5     0    0    0 S  0.0  0.0   0:00.03 kblockd/0
   31 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 kacpid
   32 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 kacpi_notify
   99 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kseriod
  122 root      15   0     0    0    0 S  0.0  0.0   0:00.02 pdflush
  123 root      15   0     0    0    0 S  0.0  0.0   0:00.48 pdflush
  124 root      10  -5     0    0    0 S  0.0  0.0   0:00.64 kswapd0
  125 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 aio/0
 1946 root      10  -5     0    0    0 S  0.0  0.0   0:00.56 ata/0
 1947 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 ata_aux
 1950 root      13  -5     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_0
 1951 root      10  -5     0    0    0 S  0.0  0.0   0:00.64 scsi_eh_1
 1956 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 ksuspend_usbd
 1957 root      10  -5     0    0    0 S  0.0  0.0   0:00.03 khubd




> This will tell us, if CPU is what we're waiting for, exactly which
> process is causing the wait.
>
> 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

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
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:~#



Thank you very much, Jakob. I look forward to your analysis.

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