[digiKam-users] The task "/usr/bin digikam -qwindowtitle digikam" appears twice in htop

[Rafael Linux]

I have Digikam to be launched at Plasma start (to make less tedious the 7
minutes that it takes to start). However, today is not ending. I didn't
launch it manually and I have Plasma configured to not "autoopen" latest
session.

However, with "htop" tool I can see that Digikam appears twice in task list,
taking (as always) near 99% CPU all time. The task appear like
"/usr/bin digikam -qwindowtitle digikam" (twice), but I understand this is
not normal, is it?

Thank you



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Rafael Linux]

Finally, I killed all task related to Digikam and MySQL and I launched
manually again Digikam. After 7 to 8 minutes, Digikam appeared, but it's
curious how many threads from Digikam and MySQL are working while doing
nothiing at Digikam ....

<http://digikam.1695700.n4.nabble.com/file/t376179/digikam_-_after_finished%2C_a_lot_of_task_repeated.png>  



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Maik Qualmann]

What's this??? Do you use internal MySQL from digiKam? This is absolutely not
normal, digiKam starts *one* mysqld if you use an internal MySQL database. Can
you please post the output from the console from start to the window opens?

Maik

Am Montag, 8. Oktober 2018, 11:29:31 CEST schrieb Rafael Linux:

> Finally, I killed all task related to Digikam and MySQL and I launched
> manually again Digikam. After 7 to 8 minutes, Digikam appeared, but it's
> curious how many threads from Digikam and MySQL are working while doing
> nothiing at Digikam ....
>
> <<a href="http://digikam.1695700.n4.nabble.com/file/t376179/digikam_-_after_finished%">http://digikam.1695700.n4.nabble.com/file/t376179/digikam_-_after_finished%
> 2C_a_lot_of_task_repeated.png>
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Maik Qualmann]

Also see 10 instances of digiKam, that too is not normal. And that happens
when you start digiKam once? I have no explanation for that at the moment.

Maik

Am Montag, 8. Oktober 2018, 12:22:56 CEST schrieben Sie:

> What's this??? Do you use internal MySQL from digiKam? This is absolutely
> not normal, digiKam starts *one* mysqld if you use an internal MySQL
> database. Can you please post the output from the console from start to the
> window opens?
>
> Maik
>
> Am Montag, 8. Oktober 2018, 11:29:31 CEST schrieb Rafael Linux:
> > Finally, I killed all task related to Digikam and MySQL and I launched
> > manually again Digikam. After 7 to 8 minutes, Digikam appeared, but it's
> > curious how many threads from Digikam and MySQL are working while doing
> > nothiing at Digikam ....
> >
> > <http://digikam.1695700.n4.nabble.com/file/t376179/digikam_-_after_finishe
> > d% 2C_a_lot_of_task_repeated.png>
> >
> >
> >
> > --
> > Sent from:
> > http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Rafael Linux]

Sorry, as I told in other posts, I have not direct access to retrieve info
when I want to (is the user job machine), so I just now have access and can
clarify some questions:
- I launch only ONE time Digikam (at Plasma start). In this case, I killed
all instances (Digikam and MySQL) and launch it manually again. Result is
the same: A lot of Digikam and MySQL threads.
- We are using internal MySQL
- Plasma monitor (ksysguard) only shows 1 Digikam task and 1 mysqld
instance. Is "htop" (from command line) who shows really all those threads.
Maybe is normal .... but I really don't know.
- When we got Digikam to respond (after launching manually and wait "X"
minutes), user *only clicked* "Advanced search" ... and that was the worst
decision ....  Digikam advanced search window opened but just  "freezed"
doing who knows, and unfortunately that implies Digikam main window is
freezed too, so user can't work with application (20 minutes ago now).

Digikam is working, as you can see in attached image, taking 25% of CPU
processes resources, but no Digikam windows contents are showed at all.

I think these issues are related to the growing database. We are reaching
398.000 images (we started at +300K) but our database is increased all days
by 20 to 100 (estimated) new photos (mainly JPG) every work day.

Any suggestion?
<http://digikam.1695700.n4.nabble.com/file/t376179/digikam_-_advanced_search_freezed_Digikam.png> 




--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Rafael Linux]

I just discovered what's difference between how HTOP and KSysguard shows
task. While "htop" shows all threads, Ksysguard only shows all task threads
if you put mouse pointer over the task name, then it will show how many
threads have that task (see attached image). So that it's normal, despite I
was wondering how it was possible.

<http://digikam.1695700.n4.nabble.com/file/t376179/Digikam_-_ksysguard_processes_tooltips.png>



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Maik Qualmann]

 I now have over 320k images and over 1100 albums in my collection. With the
help of this script (https://loteks.de/tausende-zufaellige-bilder-mit-fortlaufenden-namen/) and additional code that automatically creates folders,
I have now created 300k random images, 500 folders x 600 images. My computer
is an already "older" AMD with 2 cores with 8GB memory, a SSD for the system
and an HDD for the images. An actually already longer planned update, I still
push in front of me, since he is still enough for me. The local MySQL DB is on
the SSD. OpenSUSE Tumbleweed with kernel 4.18.9 and Plasma KF5.50. DigiKam is
compiled from git/master itself. Of course, the first scan takes a while. Now
the times:

Start until the GUI is visible (last time the album mode was set): 10 seconds.

New item scan in the status bar: 22 seconds.

Change the sort order in albums with 600-2000 images: no delay.

The albums and images can be browsed without delay.

Search for keywords where the result is around 2000 images: 1 second.

Now the extreme, the search for images without keywords, here so 300k images.
The Icon view is able to display this number of images, takes 3 minutes and
digiKam use itself 1.3GB memory. Changing the sort order of this view takes 4
minutes. Here I will try to optimize further.

For me an interesting self-test and I think digiKam is also suitable for such
a collection.

Maik

Am Montag, 8. Oktober 2018, 15:03:22 CEST schrieb Rafael Linux:

> I just discovered what's difference between how HTOP and KSysguard shows
> task. While "htop" shows all threads, Ksysguard only shows all task threads
> if you put mouse pointer over the task name, then it will show how many
> threads have that task (see attached image). So that it's normal, despite I
> was wondering how it was possible.
>
> <http://digikam.1695700.n4.nabble.com/file/t376179/Digikam_-_ksysguard_proce
> sses_tooltips.png>
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Rafael Linux]

Well, maybe "clean" images that have no tags, comments and other EXIF data
inserted by user are not the problem. Or maybe the number of nested folders,
the length of the names of the folders ... really don't know. I created a
log with the Digikam output from command line and will sent here tomorrow.
In this file timestamp are visible each some time, so it could be useful.





--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Rafael Linux]

This is Digikam output in my system (+390K photos) where you can see time
elapsed before user can get rid of Digikam. Some filenames and id's has been
modified for privacy (they are long names, including date format at the
beginning, like "2018 august 29 - Place or event name and some other info").
Not the best way to name files or folders ... but I a user that works "his
way"  

digikam_log_forzado.log
<http://digikam.1695700.n4.nabble.com/file/t376179/digikam_log_forzado.log>  

I wish it helps some way to guess what's the bottleneck.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Maik Qualmann]

Well, you still use digiKam-5.9.0. It is very good to see with the timestamp of the internal MySQL server how long it takes. Your collection will include a lot of albums. Especially in this regard, a lot has already been done in digiKam-6.0.0. We added extra caches to reduce the time for certain queries. You'll get a significant boost in performance with the upcoming digiKam release.

Maik

Am Di., 9. Okt. 2018 um 12:45 Uhr schrieb Rafael Linux <[hidden email]>:

This is Digikam output in my system (+390K photos) where you can see time
elapsed before user can get rid of Digikam. Some filenames and id's has been
modified for privacy (they are long names, including date format at the
beginning, like "2018 august 29 - Place or event name and some other info").
Not the best way to name files or folders ... but I a user that works "his
way" 

digikam_log_forzado.log
<http://digikam.1695700.n4.nabble.com/file/t376179/digikam_log_forzado.log> 

I wish it helps some way to guess what's the bottleneck.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Rafael Linux]

I can't switch to beta version cause I'm not the user. I prefer in this case
to wait for the final version, whereever it is ready to be published. I'm
sure he'll happy (and won't bother me more about) when this issue is solved  



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Gilles Caulier-4]

Hi,

The new 6.0.0-beta2 will be out while this week end if all is ready to use with Exiv2 0.27 embeded in all bundles. Windows installers are ready, but i need to test if no side-effects do not appear.

Best

Gilles Caulier

Le mar. 9 oct. 2018 à 18:28, Rafael Linux <[hidden email]> a écrit :

I can't switch to beta version cause I'm not the user. I prefer in this case
to wait for the final version, whereever it is ready to be published. I'm
sure he'll happy (and won't bother me more about) when this issue is solved 



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html