Any thoughts on RAM needs?
Locked
 
|
Running on Windows XP, dK opens LOTS of running processes, mostly
something called kioslave.exe. All told, right about 600K total. I'm down to 2 GB, having had a couple of sticks fail over time. In process buying more. Adobe Photoshop Elements takes 48K. Quite a difference, although since I hate Adobe products generally and RAM is relatively cheap, I've no problem with dK's memory appetite. (Both memory requirements are noted after only opening the programs. I've seen the kioslave.exe numbers go up and down during use.) But regardless, I was wondering if there is any official advice or observations beyond "More is better!" I have no idea how much dK takes in Linux. ??????? Paul _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
I am on Linux Ubuntu and only with 1GB (netbook) and painfully slow. I
think 2 or 4GB are definately the way to go if possible. Don't know if there is other way to "optimize" things. I hope there is. big databases $ ls -lh ~/Images/*.db -rw-r--r-- 1 julien julien 172M 2011-09-13 09:32 /home/julien/Images/digikam4.db -rw-r--r-- 1 julien julien 1,6G 2011-09-11 09:39 /home/julien/Images/thumbnails-digikam.db $ free -m total used free shared buffers cached Mem: 990 976 14 0 10 185 -/+ buffers/cache: 779 211 Swap: 1951 417 1534 $ pmap 3269|egrep '[0-9][0-9][0-9][0-9][0-9]K' |sort -k 2 -n b19f5000 10284K rwxs- /var/tmp/kdecache-julien/icon-cache.kcache b56b8000 10284K rwxs- /var/tmp/kdecache-julien/icon-cache.kcache 4357c000 10700K r-x-- /usr/lib/libQtGui.so.4.7.2 aaf2e000 12332K rwx-- [ anon ] b065f000 15860K rwxs- /var/tmp/kdecache-julien/kpc/kde-icon-cache.data b4322000 15860K rwxs- /var/tmp/kdecache-julien/kpc/kde-icon-cache.data 97b66000 16400K r-x-- /usr/share/fonts/truetype/wqy/wqy-zenhei.ttc a2884000 16400K r-x-- /usr/share/fonts/truetype/wqy/wqy-zenhei.ttc a157b000 19492K rwx-- [ anon ] 46ced000 19648K r-x-- /usr/lib/libQtWebKit.so.4.7.2 92d54000 20564K r-x-- /usr/share/fonts/truetype/arphic/uming.ttc 98b6a000 20564K r-x-- /usr/share/fonts/truetype/arphic/uming.ttc a0166000 20564K r-x-- /usr/share/fonts/truetype/arphic/uming.ttc 09020000 44100K rwx-- [ anon ] 873a2000 47708K rwx-- [ anon ] 94169000 47708K rwx-- [ anon ] a5f2a000 65540K rwxs- /dev/shm/pulse-shm-2408409839 ac4e3000 65540K rwxs- /dev/shm/pulse-shm-915678883 total 812132K Cheers, Julien 2011/9/13, Paul Verizzo <[hidden email]>: > Running on Windows XP, dK opens LOTS of running processes, mostly > something called kioslave.exe. All told, right about 600K total. I'm > down to 2 GB, having had a couple of sticks fail over time. In process > buying more. > > Adobe Photoshop Elements takes 48K. Quite a difference, although since > I hate Adobe products generally and RAM is relatively cheap, I've no > problem with dK's memory appetite. > > (Both memory requirements are noted after only opening the programs. > I've seen the kioslave.exe numbers go up and down during use.) > > But regardless, I was wondering if there is any official advice or > observations beyond "More is better!" I have no idea how much dK takes > in Linux. > > ??????? > > Paul > > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
I have toubles with performance too,
If I select a tag in left pane all images are shown immediatly, but if I use rightpane filters, the pc becomes almost unresponsive after the first search, why? and I see no much use for a bug report saying ¨help my computer is so slow¨ so I hope one day figure out why. In the past I put some messages in the list about it without success, maybe we have a good starting point now. We need people with technical insight in this discussion. thanks julien for the free -m command obvious installing 4GB doesn´t help much. How about this, can anyone comment on it: jansen@jansen-HP-Pavilion-dv7-Notebook-PC:~$ free -m total used free shared buffers cached Mem: 3705 3672 32 0 1359 1307 -/+ buffers/cache: 1006 2698 Swap: 6171 0 6171 jansen@jansen-HP-Pavilion-dv7-Notebook-PC:~$ Rinus 2011/9/13 Julien T <[hidden email]> I am on Linux Ubuntu and only with 1GB (netbook) and painfully slow. I _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Any thoughts on RAM needs?
|
|
2011/9/13 Rinus Bakker <[hidden email]>:
> I have toubles with performance too, > If I select a tag in left pane all images are shown immediatly, but if I use > rightpane filters, the pc becomes almost unresponsive after the first > search, why? unresponsive can be due to query database through digiKam KIO Slave (a separated process based on KDE API to query BD) SQlite (if you use it), cannot be queried using multithreading. A separate process is used instead to not freeze GUI with long query. I tried here with my 2Gb computer, and both, tags view and filters view are fast. Which filters you use in right sidebar ? Which DB backend you use ? How many items are managed in your computer (Help/DB stats) ? Gilles Caulier _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
digiKam version 2.1.0
Images: BMP: 34 GIF: 9 JPEG: 37 JPG: 25644 PENTAX-PEF: 94 PNG: 675 PPM: 2 RAW-DNG: 450 RAW-PEF: 13995 TIFF: 796 XCF: 9 total: 41745 : : Videos: AVI: 17 MP4: 1 WMV: 3 total: 21 : : Total Items: 41766 Albums: 865 Tags: 1366 Database backend: QSQLITE Example. I do text search for ¨evelien¨ I t takes about one minute to find. In left pane tag view, it takes 1/100 of a second, I can even blink my eyes. Rinus 2011/9/13 Gilles Caulier <[hidden email]> 2011/9/13 Rinus Bakker <[hidden email]>: _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Any thoughts on RAM needs?
|
|
2011/9/13 Rinus Bakker <[hidden email]>:
> digiKam version 2.1.0 > Images: > BMP: 34 > GIF: 9 > JPEG: 37 > JPG: 25644 > PENTAX-PEF: 94 > PNG: 675 > PPM: 2 > RAW-DNG: 450 > RAW-PEF: 13995 > TIFF: 796 > XCF: 9 > total: 41745 > : > : > Videos: > AVI: 17 > MP4: 1 > WMV: 3 > total: 21 > : > : > Total Items: 41766 > Albums: 865 > Tags: 1366 > Database backend: QSQLITE > > > Example. I do text search for ¨evelien¨ I t takes about one minute to find. > weird. For me, it's take 500ms... I manage 10.000 items on this computer. i use SQlite too... Sound like something is broken in your BD file. To investiguate : - make a backup of your digiKam DB file. - remove it and rebuild DB from scratch - try again and look differences. Gilles Caulier _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Rinus Bakker
On Tuesday 13 September 2011 12:14:32 Rinus Bakker wrote:
... > How about this, can anyone comment on it: > jansen@jansen-HP-Pavilion-dv7-Notebook-PC:~$ free -m > total used free shared buffers cached > Mem: 3705 3672 32 0 1359 1307 > -/+ buffers/cache: 1006 2698 > Swap: 6171 0 6171 > jansen@jansen-HP-Pavilion-dv7-Notebook-PC:~$ One of the particularities of Linux is that any free RAM can be used to cache disk reads, so the 'free' part of the 'Mem' line shows less free memory than would be available to programs running (the 'cached' part can also be used for program memory, slowing disk I/O a bit). Swap (being disk space) isn't used for caching, so there the 'free' value is correct. In this case, there's no swapping to disk ('used' is zero), so the OS has still enough free RAM to work with, and lack of free RAM doesn't cause the slowness (swapping to and from disk is slow...). Adding memory wouldn't have much of an effect if this is the worst case... _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
I was suspicious about the db being broken and was hoping for that (it can be fixed) and was fearing that (it cause an awfull lot of work)
Putting the answers of Gilles and Remco together makes me even more suspicious about that scenario. That´s why I came with this question a while ago: I suppose that the db becomes more and more messy by adding, removing and readding etc etc, I wonder if someone knows if and if, how it is possible to optimize the db in order to have quicker search capabillity. A few filtering actions can make it quite unresponsive. and with this question: Does anyone know if this cleanup_digikamdb.1 by Andy Clemens is still valid to use with current digikam db? And any ideas what to do with that cleanup_digikamdb.1 file? If there is a way of fixing I would prefer to try before starting all over again. Thanks Rinus 2011/9/13 Remco Viëtor <[hidden email]> On Tuesday 13 September 2011 12:14:32 Rinus Bakker wrote: _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Any thoughts on RAM needs?
|
|
On Tue, 13 Sep 2011, Rinus Bakker wrote: > I was suspicious about the db being broken and was hoping for that (it can > be fixed) and was fearing that (it cause an awfull lot of work) > Putting the answers of Gilles and Remco together makes me even more > suspicious about that scenario. > > That´s why I came with this question a while ago: > I suppose that the db becomes more and more messy by adding, removing and > readding etc etc, I wonder if someone knows if and if, how it is possible to > optimize the db in order to have quicker search capabillity. > A few filtering actions can make it quite unresponsive. PostgreSQL, etc., get messy and fragmented as time goes by. And that's why all database software provide a "vacuum" function, to do cleanup tasks, reorganize tables and indexes, remove deleted tuples, etc. It's a good practice to do such cleanup from time to time. (Time to time may be every night for huge professional databases, or once or twice a month for a user level database as digiKam DB.) > and with this question: > Does anyone know if this > cleanup_digikamdb.1 by Andy Clemens > is still valid to use with current digikam db? > > And any ideas what to do with that cleanup_digikamdb.1 file? Cleanup_digikam doesn't nothing else than issuing "vacuum" commands. The extra is that it checks that no active DB connection is running, because it's not possible to do vacuum tasks while an application is connected and working with the database. But you don't need cleanup_digikam if you have the SQLlite3 package installed, just use the sqlite3 command line client program. - Close any running digiKam program - Go into your digiKam base directory and backup your digikam4.db file. - From command line run the following : sqlite3 -line digikam4.db 'vacuum;' That's all and that's mostly what cleanup_digikam does. You can also run some checks, e.g. : sqlite3 -line digikam4.db 'pragma integrity_check;' and, hopefully, get a message : integrity_check = ok Tuning a database performance is a bit more complicated because you need to know what kind of performance parameter may be affected. SQLite3 has a number of tuning parameters, see the documentation : http://www.sqlite.org/pragma.html Maybe, moving temporary storage from disk to computer memory may help about performance : sqlite3 -line digikam4.db 'pragma temp_store = 2;' (That's the only "tuning" I did on my digikam DB) Note that doing such DB maintenance tasks with the SQLite3 command line program is independant of such or such digiKam version. It's *the* program packaged with *the* sqlite library used by digiKam. So it knowns perfectly well what should a SQLite db look like, what is correct or not. If integrity checks are ok, you can trust that. Cheers, Jean-François _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
To be continued. Have a nice day, Rinus Op 13-09-11 14:10, Jean-Francois schreef:
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Was this action: sqlite3 -line digikam4.db 'vacuum;' supposed to delete the ¨thumbnails-digikam.db¨ or is it an accident? Rinus Op 13-09-11 14:47, sleepless schreef:
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Any thoughts on RAM needs?
|
|
On Tue, 13 Sep 2011, sleepless wrote: > Hi, > > Was this action: > > sqlite3 -line digikam4.db 'vacuum;' > > supposed to delete the ¨thumbnails-digikam.db¨ or is it an accident? Not at all. sqlite3 is the SQLite command line tool and works on one SQLite database. It is absolutely not aware of the fact that the digiKam application uses two different database. By the way, a cleanup, or integrity check, should require to run the commands on the two databases used. sqlite3 -line digikam4.db 'vacuum;' sqlite3 -line digikam4.db 'pragma integrity_check;' and also : sqlite3 -line thumbnails_digikam.db 'vacuum;' sqlite3 -line thumbnails_digikam.db 'pragma integrity_check;' But sqlite3 itself works on the only database specified as argument and doesn't care of whatever other databases you may have in the current directory. Hopefully... Jean-François _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Jean-Francois wrote:
> By the way, a cleanup, or integrity check, should require to run the (...) very interesting. Is it stable enough to be used in a cron script (monthly, for example, with backup rotation) thanks jdd _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Jean-François Rabasse
Weird, after it completed the action the thumbnails db was gone. But copies enough around, so no problem. I´ll try again. Thanks for the answer. Rinus Op 13-09-11 17:11, Jean-Francois schreef:
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Any thoughts on RAM needs?
|
|
In reply to this post by jdd@dodin.org
On Tue, 13 Sep 2011, Jean-Daniel Dodin wrote: > Jean-Francois wrote: > >> By the way, a cleanup, or integrity check, should require to run the > > (...) > > very interesting. Is it stable enough to be used in a cron script > (monthly, for example, with backup rotation) Is it stable ? Well, 'vacuum' is a SQL command, not strictly in the standards but implemented by all RDBMS software providers. There's no more risk to use this than to use any other SQL command that will modify your database, INSERT INTO, UPDATE, etc. It will be stable if you use a stable production version of your DB software, PostgreSQL, MySQL, SQLite, whatever. It may be buggy if you use a buggy CVS snapshot of the alpha.0.0.0.1 version of the next release of the software. As usual :-) All these commands can be issued from the related command line client. With SQLite : sqlite3 -line mybase.db 'vacuum;' With PostgreSQL : psql -d mybase -h myserver -c 'vacuum;' etc. And thus, it is very easy to cron. Doing cleanup along backup rotation is context specific, a matter of data volume, and processing time. If you have several large sized database, say 50 Tbytes to 200 Tbytes, installed on a reasonably safe system, e.g. RAID5 or 6 disks server, you'll probably consider doing a weekly backup because it will cost hours and hours of network traffic. But if your databases are subject to intensive daily use, a daily 'vaccum' will take several minutes and can be cron'ed at 3 or 4a.m., when 99% of users are sleeping. In that case it will be better to split backup and cleanup operations. For small volume databases, with a low operations daily rate, the two can be done at the same time. Jean-François _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Jean-Francois wrote:
> For small volume databases, with a low operations daily rate, the two > can be done at the same time. > very good, thank you! jdd _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Any thoughts on RAM needs?
|
|
In reply to this post by Rinus
Þann þri 13.sep 2011 15:11, skrifaði Jean-Francois:
> > and also : > sqlite3 -line thumbnails_digikam.db 'vacuum;' > sqlite3 -line thumbnails_digikam.db 'pragma integrity_check;' My thumbnail-db is called thumbnails-digikam.db, not thumbnails_digikam.db. Just in case. Thanks for this handy tip. Sveinn í Felli _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Rinus
Your very usefull method cured my digikam, thanks a lot. Rinus Btw: along the way the tread has changed direction, if someone has still thoughts about what should be the optimum amount of RAM we can pick it up again here... Op 13-09-11 17:16, sleepless schreef:
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Paul Verizzo
Rinus,
I managed to move my digikam material from one computer to the other, in Linux. What I did was as follows. 1. copied digikamrc from machine 1 to machine 2; 2. copied directory /pictures, including database file, from machine 1 to machine 2; 3. ran digikam and on startup said; I'll tell you about database later (or something like that); 4. deleted in digikam settings old path to pictures and add a new path, although they were the same; 5. restarted digikam And it worked. Thanks for your help. Bojan _______________________________________________ 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 |