Digikam slow
Locked
12
12
 
|
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. All apps run sluggish on this machine, but Digikam is really bad. What can I do to tweak it a bit? I may be an old timer, but in my opinion a 1300 MHz processor (with 1024MB RAM) should not be this bad. Thanks in advance. 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? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Hi Dotan,
sorry, no real ideas, but some remarks ... On Fri, 30 Nov 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. What does `top` give? Is there any indication the the system is already swapping? > All apps run sluggish on this machine, but Digikam is really bad. What > can I do to tweak it a bit? I may be an old timer, but in my opinion a > 1300 MHz processor (with 1024MB RAM) should not be this bad. I agree it should work, not super-fast, but at least at a reasonable speed. I could try to activate my "old" PIII, 1200 GHz with 512 MB, to see the speed there. However, this will require an OS update, so because of too much other stuff I don't see that I will manage that during the next two weeks. Does anyone else here have a similar machine and could report some timings? Best, Arnd _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On 01/12/2007, Arnd Baecker <[hidden email]> wrote:
> Hi Dotan, > > sorry, no real ideas, but some remarks ... > > On Fri, 30 Nov 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. > > What does `top` give? Is there any indication the the > system is already swapping? > > > All apps run sluggish on this machine, but Digikam is really bad. What > > can I do to tweak it a bit? I may be an old timer, but in my opinion a > > 1300 MHz processor (with 1024MB RAM) should not be this bad. > > I agree it should work, not super-fast, but at least at > a reasonable speed. I could try to activate my "old" PIII, 1200 GHz > with 512 MB, to see the speed there. However, > this will require an OS update, so because of too much other > stuff I don't see that I will manage that during the next two weeks. > > Does anyone else here have a similar machine and could > report some timings? > > Best, Arnd Until I open Digikam, only init and X show up at the top of top. With Digikam open: top - 16:44:08 up 16 min, 1 user, load average: 0.27, 0.21, 0.29 Tasks: 96 total, 2 running, 94 sleeping, 0 stopped, 0 zombie Cpu(s): 18.6%us, 6.0%sy, 0.0%ni, 72.4%id, 2.3%wa, 0.7%hi, 0.0%si, 0.0%st Mem: 970748k total, 330772k used, 639976k free, 1104k buffers Swap: 2562356k total, 0k used, 2562356k free, 206988k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7618 haldaemo 15 0 10304 8604 1708 S 9.0 0.9 0:04.04 hald 8193 root 15 0 93260 20m 3784 S 2.0 2.2 0:04.98 Xorg 8319 ubuntu 15 0 31692 12m 10m S 0.7 1.4 0:01.06 kded 5598 root 19 -4 2904 1244 372 S 0.3 0.1 0:00.80 udevd 7579 root 15 0 1792 520 432 S 0.3 0.1 0:00.04 dd 7602 messageb 15 0 2716 972 728 S 0.3 0.1 0:00.33 dbus-daemon 7619 root 20 0 2880 1028 884 S 0.3 0.1 0:00.05 hald-runner 7689 root 15 0 12324 1936 1684 S 0.3 0.2 0:00.04 NetworkManager 8373 ubuntu 15 0 32564 14m 11m R 0.3 1.5 0:00.86 konsole 1 root 15 0 2912 1848 524 S 0.0 0.2 0:01.58 init 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? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Arnd Baecker
Arnd,
To my son school, digiKam is installed on old computer : PIII-500 Mhz 512Mb RAM PIII-650 Mhz 512Mb RAM AMD K7 - 1.2 Ghz 800 Mb RAM PIV 1,6 Ghz 1Gb RAM etc... No problem relevant. Root album is always in a local drive (generally IDE). Mandriva 2008.0 is used as linux box... Gilles 2007/12/1, Arnd Baecker <[hidden email]>: Hi Dotan, _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On 01/12/2007, Gilles Caulier <[hidden email]> wrote:
> Arnd, > > To my son school, digiKam is installed on old computer : > > PIII-500 Mhz 512Mb RAM > PIII-650 Mhz 512Mb RAM > AMD K7 - 1.2 Ghz 800 Mb RAM > PIV 1,6 Ghz 1Gb RAM > > etc... > > No problem relevant. Root album is always in a local drive (generally IDE). > Mandriva 2008.0 is used as linux box... > > Gilles > Thanks, Gilles. Those machines are below the specs of this machine. I wonder what the problem could be. 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? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Hello,
Just a thought, where is the users home directory? The thumbnails directory is (usually) in $HOME/.thumbnails. Is this directory stored on a network drive? Gerry On Dec 1, 2007 10:27 AM, Dotan Cohen <
[hidden email]> wrote:
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On 01/12/2007, Gerry Patterson <[hidden email]> wrote:
> Hello, > > Just a thought, where is the users home directory? The thumbnails directory > is (usually) in $HOME/.thumbnails. Is this directory stored on a network > drive? > > Gerry > /home/user/.thumbnails is on a local IDE drive. But /home/user/pictures/digikam is on a different partition on the same drive. Might that be a problem? Note that / is on yet another partition. I always put / and /home on separate partitions. On this box, with it's 500GB hard drive, I have an additional few partitions, namely ~/pictures, ~/music, ~/video. I did this so that I could easily backup what I need. 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? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
2007/12/1, Dotan Cohen <[hidden email]>: On 01/12/2007, Gerry Patterson <[hidden email]> wrote: no, using local another partition is not a problem. All my computer use a dedicaced partition to host pictures. It's mounted in /mnt/photos Gilles _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Dotan Cohen
Dnia Saturday 01 of December 2007, Dotan Cohen napisał:
> 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. > > All apps run sluggish on this machine, but Digikam is really bad. What > can I do to tweak it a bit? I may be an old timer, but in my opinion a > 1300 MHz processor (with 1024MB RAM) should not be this bad. What disk do you have? What returns: hdparm -tT {device} ? m. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
What graphics card/memory do you have?
I have an old PIII with 768Ram, separate /home and separate USB photo storage and it all runs well - the problems sound like slow graphics. Just a thought Eddie _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Dotan Cohen
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. 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. 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. 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 ? -- Jakob Østergaard Hegelund _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Bugzilla from mikmach@wp.pl
On 02/12/2007, Mikolaj Machowski <[hidden email]> wrote:
> Dnia Saturday 01 of December 2007, Dotan Cohen napisał: > > 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. > > > > All apps run sluggish on this machine, but Digikam is really bad. What > > can I do to tweak it a bit? I may be an old timer, but in my opinion a > > 1300 MHz processor (with 1024MB RAM) should not be this bad. > > What disk do you have? > What returns: > > hdparm -tT {device} On an otherwise idle system, I get this for the drive on which /home/user/pictures is running: ubuntu@ubuntu-desktop:~$ sudo hdparm -tT /dev/sdb1 Password: /dev/sdb1: Timing cached reads: 340 MB in 2.01 seconds = 169.46 MB/sec Timing buffered disk reads: 190 MB in 3.03 seconds = 62.79 MB/sec ubuntu@ubuntu-desktop:~$ 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? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Jakob "Ãstergaard"
On 04/12/2007, Jakob Østergaard Hegelund <[hidden email]> 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@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@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@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@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? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
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@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@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@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@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 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On 07/12/2007, Jakob Østergaard Hegelund <[hidden email]> 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@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@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@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@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? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Hi
Am Friday 07 December 2007 schrieb Dotan Cohen: > While googling, I came across this: > http://rudd-o.com/archives/2007/10/02/tales-from-responsivenessland-why-lin >ux-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? No. A bigger filesystem cache would only help if you had a lot of IO ( => high system or wait io value in vmstat). The problem seems to be the "application cache" of the thumbnails. Did you check if you actually have files in .thumbnails? I think you could have one of the following problems: 1. Thumbnail cache too small (don't know how to increase it further) 2. The thumbnails can not be written to the .thumbnail directory so the are generated each time (permission problem) 3. Whenever it is checked if your image has been changed since the thumbnail was generated the result is that the image is newer. So the thumbnail has to be regenerated. I don't know what the criterias are (timestamp or something else). Did you check the creation time of your original images (ls -l). Maybe they are in the future. Andreas -- My Public GPG Key: http://www.silicoids-world.de/gpg.asc Q: How did you get into artificial intelligence? A: Seemed logical -- I didn't have any real intelligence. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On 08/12/2007, Andreas Weigl <[hidden email]> wrote:
> Hi > > Am Friday 07 December 2007 schrieb Dotan Cohen: > > While googling, I came across this: > > http://rudd-o.com/archives/2007/10/02/tales-from-responsivenessland-why-lin > >ux-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? > > No. A bigger filesystem cache would only help if you had a lot of IO ( => high > system or wait io value in vmstat). The problem seems to be the "application > cache" of the thumbnails. > > Did you check if you actually have files in .thumbnails? Yes, opening an album in Digikam makes the thumbnails appear in ~/.thumbnails. > I think you could have one of the following problems: > > 1. Thumbnail cache too small (don't know how to increase it further) It's 100 MB, as per Kcontrol. Although, I think that is too small for over 13,000 photos. 13000 * 100 KB = 1.3 GB. > 2. The thumbnails can not be written to the .thumbnail directory so the are > generated each time (permission problem) Checked, they are most certainly written. > 3. Whenever it is checked if your image has been changed since the thumbnail > was generated the result is that the image is newer. So the thumbnail has to > be regenerated. I don't know what the criterias are (timestamp or something > else). Did you check the creation time of your original images (ls -l). Maybe > they are in the future. Interesting idea, but alas, this is not the problem. Another thing that I have noticed: Digikam does not make thumbnails until the thumbnail in question is meant to be displayed on the screen. So if I want the thumbnails of all the photos in an album, I must pan slowly down, so that each one will have a chance to be created. After that, I can pan up and down quickly with almost no lag in the thumbnail's display. However, if I switch to another album and then back, once again I have a delay in the display of the thumbnails. It is not so long as it would take to create the thumbnails again, however it is extremely sluggish. We are considering replacing this aging computer. I will start a new thread asking about processor/memory recommendations for a machine that's main purpose will be to run digikam (as this one is). 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? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Hi
Am Saturday 08 December 2007 schrieb Dotan Cohen: > > 1. Thumbnail cache too small (don't know how to increase it further) > > It's 100 MB, as per Kcontrol. Although, I think that is too small for > over 13,000 photos. 13000 * 100 KB = 1.3 GB. Ummm, I just wanted to check what value I have. The only option I found in kcontrol was Internet & Network -> Web Browser -> Cache But I don't think that this option controls the size of the .thumnail directory. It is set to 50 MB and right now my .thumnail directory has a size of 72 MB. Is this the option you meant or another option? Andreas _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On 08/12/2007, Andreas Weigl <[hidden email]> wrote:
> Hi > > Am Saturday 08 December 2007 schrieb Dotan Cohen: > > > 1. Thumbnail cache too small (don't know how to increase it further) > > > > It's 100 MB, as per Kcontrol. Although, I think that is too small for > > over 13,000 photos. 13000 * 100 KB = 1.3 GB. > > Ummm, I just wanted to check what value I have. > > The only option I found in kcontrol was > Internet & Network -> Web Browser -> Cache > > But I don't think that this option controls the size of the .thumnail > directory. It is set to 50 MB and right now my .thumnail directory has > a size of 72 MB. > > Is this the option you meant or another option? Actually, I meant KDE ingredients -> File Manager -> Thumbnails and Metadata -> Maximum Size which I had set to 100.0 MB. However, I am now not as convinced as I once was that this controls the size of the _digikam_ thumbnails cache. I thought that they were one and the same because digikam stores it's files in ~/.thumbnails along with Konqueror. However, I have also noticed that this folder can grow much beyond the 100 MB that it is allotted. 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? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
More info: after running Rebuild Thumbnails, I see that ~/.thumbnails
has grown to 442.2 MB. However, there is absolutely no effect on performance versus an empty ~/.thumbnails directory. In other words, even after Rebuild Thumbnails, digikam seems to be creating thumbnails only when the thumbnail in question is meant to be displayed on the screen (as described in earlier email). 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? _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |