Bug 473569

Summary: Horrible performance using Digikam on my Mac with Database on Synology DS 920+
Product: [Applications] digikam Reporter: Martin Neuß <spamfilter>
Component: Database-MysqlAssignee: Digikam Developers <digikam-bugs-null>
Status: REPORTED ---    
Severity: wishlist CC: caulier.gilles, metzpinguin
Priority: NOR    
Version: 8.1.0   
Target Milestone: ---   
Platform: macOS (DMG)   
OS: macOS   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Screenshots recommendations
Terminal log file

Description Martin Neuß 2023-08-20 17:21:53 UTC
Created attachment 161075 [details]
Screenshots recommendations

Hi 

I´m using digikam since a few years, with its multitude of functions it is a very good management tool.

but the performance of the system placing the files on a synology ds 920+ (with ssd cache), using the synology mariadb database and a 1GB LAN connection is simply terrible. 
and this when i see that network transfers are miniuscule, the load of the nas cpu is at about 7%, the write transfers on the nas are well below saturation and the load on my macbookpro m2 (2023) is at about 10%.
setting new keywords for 500 pictures in the database takes minutes and this when dfirect transfer to the files is disabled  so there should be only database transfers.

- i already adjusted database settings to optimise database storage, caches and so on.

when checking the recommendations of the mariadb-server there were some suggestions mostly regarding file indexing and using indices when using "JOIN" and so on.

i took some screen shots.
- too many joins without using indices (3/minute when less than 1/hour is typical)
- too often first index table entry is read (27/h when less than 1/h is typical)
- rate of reading of fixed positions too high (3.4 / second when less than 1/h is typical)

all those problems are related to missing indices.

so my question is: 
is there any way to improve database performance over a LAN-connection as the actual implementation seems to be very problematic by design.

with best regards 

martin
Comment 1 Maik Qualmann 2023-08-20 18:47:58 UTC
The analysis is nice, but it misses the problem and is not the cause. We cannot flatten JOIN queries if they are needed for processing. If it takes minutes to tag 500 images without writing the metadata, then the problem lies elsewhere.
We need a log from the terminal of such a slow database operation when starting digiKam on macOS in a terminal. It is important to set the Qt Debug variable beforehand. The process for macOS is described here:

https://www.digikam.org/contribute/

Maik
Comment 2 Martin Neuß 2023-08-25 18:22:19 UTC
Created attachment 161181 [details]
Terminal log file
Comment 3 Martin Neuß 2023-08-25 18:23:58 UTC
Hi Maik,
thank you for your fast response.

I did a run with qt logging enabled. i attached the terminal log.

hope you find a clue. but perhaps my setup with the nas is just not sufficiernt.

with best regards

martin
Comment 4 Maik Qualmann 2023-08-27 17:40:37 UTC
This log doesn't look like a database problem.
The metadata is written into the images. The subsequent scanning process takes a very long time, between 10-20 seconds. It looks like the file system is busy.
We see this problem again and again with a lot of CPU cores. In your case, we start 10 metadata tasks. The network file system may be busy.
Maybe we should limit it as a test and they would have to see if it improves.

By the way, you should assign the program path to ExifTool, ExifTool is disabled for you at the moment.

Maik
Comment 5 caulier.gilles 2023-10-19 12:38:40 UTC
@Martin,

did you see the last comment from Maik ?

Also, digikam 8.2.0 pre-release have been rebuilt using last Qt 5.15.11 + KDE 5.110
frameworks. Installer is available at usual place :

https://files.kde.org/digikam/

Can reproduce the problem with this version?

Thanks in advance

Gilles Caulier
Comment 6 caulier.gilles 2024-09-17 13:28:40 UTC
@Martin

Please try the new 8.5.0 pre-release PKG installer for MacOS Silicon (arm64)
available here:

https://files.kde.org/digikam/

Thanks in advance

Gilles Caulier