Page 2 of 2

Re: How does a SSD drive behave with mm.db

Posted: Sat Sep 15, 2012 3:40 pm
by Eyal
I Agree with Teknojnky. The time to complete the database optimization depends on:
• database size & scattered level
• computer processor speed
• disk access speed
• patience level you can provide...

A few topics about :
• Optimize Quick vs. Complete : http://www.mediamonkey.com/forum/viewto ... =3&t=59088
• How long should Optimize database (complete) take? : http://www.mediamonkey.com/forum/viewto ... =1&t=56967
• Optimize database (Complete) Never Ends [#7316] : http://www.mediamonkey.com/forum/viewto ... 0&start=15

:~)

Re: How does a SSD drive behave with mm.db

Posted: Sun Sep 16, 2012 4:12 am
by MusicBringer
Teknojnky, you went to a lot of trouble to compose your very helpful reply - thank you for that :)

Eyal, thanks for those links 8)

Re: How does a SSD drive behave with mm.db

Posted: Sun Sep 16, 2012 4:17 am
by MusicBringer
Teknojnky wrote:
MusicBringer wrote:
For me Complete takes a considerable time to finish its job.
complete is completely (pun intended) dependent on how fast your cpu and hard disk is. If you watch the mm.db folder, you can see it basically creates a new one by building up the database journal/lock file, creating a new empty database then dumping all the transactions to the new db file.
Reading this, I now wonder whether it is this process that is causing the "more than 3000" fragments to the MM.db file

Re: How does a SSD drive behave with mm.db

Posted: Sun Sep 16, 2012 5:07 am
by MMuser2011
Teknojnky wrote:complete is completely (pun intended) dependent on how fast your cpu and hard disk is. If you watch the mm.db folder, you can see it basically creates a new one by building up the database journal/lock file, creating a new empty database then dumping all the transactions to the new db file.
Maybe it would speed up this process, if the temporary MM.DB would be created on a other (hard-)disc and then moved entirely to the final location (SSD). What do you think?

Re: How does a SSD drive behave with mm.db

Posted: Sun Sep 16, 2012 11:46 am
by Teknojnky
MMuser2011 wrote:Maybe it would speed up this process, if the temporary MM.DB would be created on a other (hard-)disc and then moved entirely to the final location (SSD). What do you think?
no, keeping it on the ssd would be the fastest, since the ssd provided the most read/write bandwidth and lowest latency. With a SSD, the cpu will likely be the bottleneck, where as a regular hard drive can only read/write so fast, especially in the small read/write operations that the optimization process uses.
Reading this, I now wonder whether it is this process that is causing the "more than 3000" fragments to the MM.db file
it is possible, since the mm.db is 'grown' from nothing to an increasingly large file, the OS/filesystem will allocate a certain amount of extra free space, but as the file grows beyond that it will have to start using additional free space from non-contigous areas leading to a fragmented file. This is why I suggested to make a copy of the .db file, windows will tend to try to allocate the complete filesize with a minimum of fragmentation.

Of course the best cure for that is to have alot of free space. The fuller a hard drive, the less free space that will be contiguous.

And there is always the option to defrag, but we have already discussed the cost/benefit for that regarding ssd's.

Re: How does a SSD drive behave with mm.db

Posted: Sun Sep 16, 2012 4:30 pm
by MusicBringer
Teknojnky wrote:This is why I suggested to make a copy of the .db file, windows will tend to try to allocate the complete filesize with a minimum of fragmentation.
...make a copy is now part of my housekeeping routine. :D

Re: How does a SSD drive behave with mm.db

Posted: Sun Sep 16, 2012 7:15 pm
by nohitter151
MusicBringer wrote:
Teknojnky wrote:This is why I suggested to make a copy of the .db file, windows will tend to try to allocate the complete filesize with a minimum of fragmentation.
...make a copy is now part of my housekeeping routine. :D
I really don't see that it's necessary. As has been said already, it doesn't matter how fragmented a file is on an SSD. The drive is so fast that the effect of a fragmented file is nil. If you want to improve performance of an SSD, you should be worried about keeping a larger portion of the drive as empty space.

Re: How does a SSD drive behave with mm.db

Posted: Sun Sep 16, 2012 11:44 pm
by Teknojnky
nohitter151 wrote:As has been said already, it doesn't matter how fragmented a file is on an SSD. The drive is so fast that the effect of a fragmented file is nil.
This is not entirely accurate.

You can look at any ssd benchmark and there will be differences between sequential read/writes, and random read/writes.

When you have a heavily fragmented filesystem, what was sequential io pattern becomes more random and does affect performance to some extent. Obviously some ssd drives have better random io performance than others, and some drives can optimize and re-arrange ('garbage collect' etc) the memory to be better balanced for performance consistency and wear leveling behind the scenes, but not every drive can and free space can also play a role as you note below.

I can agree that in alot of situations the effect of fragmentation is minimal, but if your dealing with heavily IO'd files fragmented into the multi-thousands, it can make a difference.
If you want to improve performance of an SSD, you should be worried about keeping a larger portion of the drive as empty space.
definately, but free space and fragmentation exasperate each other, regardless of whether its ssd or a normal disk drive, though not necessarily for the same reasons.

Re: How does a SSD drive behave with mm.db

Posted: Mon Sep 17, 2012 3:13 am
by MusicBringer
nohitter151 wrote:If you want to improve performance of an SSD, you should be worried about keeping a larger portion of the drive as empty space.
I have one third Used space with two thirds Free space - so that's alright then 8)

Re: How does a SSD drive behave with mm.db

Posted: Mon Sep 17, 2012 3:35 am
by khelsing