[Digikam-users] Any thoughts on RAM needs?

[Rinus Bakker]

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 <remco.vietor at wanadoo.fr>

> On Tuesday 13 September 2011 12:14:32 Rinus Bakker wrote:
> ...
> > How about this, can anyone comment on it:
> > jansen at 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 at 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
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20110913/1cca93a2/attachment.html>