Page 1 of 2

How does a SSD drive behave with mm.db

Posted: Fri Sep 07, 2012 11:01 am
by MusicBringer
How does a SSD drive behave with mm.db.

I have a SSD drive as my c:/drive - which means that my mm.db is on the SSD.
I am told not to Defrag the SSD drive as it shortens its life.
However in Defraggler the mm.db is showing well in excess of 3000+ fragments. [How come?]
For large library collections the default recommendation is to Defrag the mm.db.

This means I am between a rock and a hard place - do I Defrag the SSD and bring it to it's knees, or suffer slow performance from MM4.
Any thoughts please...
Thanks,

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

Posted: Fri Sep 07, 2012 11:50 am
by Lowlander
Due to the nature of a SSD you don't need to defrag files. On a regular hard drive the drive reads sequential from the drive, so it is faster when everything is in sequence (no fragments), but an SSD actually performs very well in random reads and thus fragments are not something that will slow down performance.

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

Posted: Fri Sep 07, 2012 12:38 pm
by MusicBringer
Lowlander wrote:...thus fragments are not something that will slow down performance.
Thanks Lowlander, I was hoping you would answer me :)
I am concerned that the mm.db file reports fragments that number well over 3000.
But that's alright is it?

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

Posted: Fri Sep 07, 2012 12:49 pm
by Lowlander
The amount of fragments doesn't matter on a SSD.

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

Posted: Fri Sep 07, 2012 1:39 pm
by MusicBringer
Ta.

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

Posted: Fri Sep 07, 2012 9:07 pm
by NWDreamer
Lowlander is spot on about SSD drives. But, just as an aside, most defraggers can usually defragment a single file so, if it bugs you, you could defrag just the mm.db file. I use Power Defragmentor GUI, a free program that you can download from HERE if you want. It runs the actual defragging in a DOS window so it's much faster then the usual Windows default (plus it doesn't prevent execution if a certain percentage of your drive isn't free - a useless limitation with today's larger drives). With this program you can target just certain files or folders, a disk or use a special triple-pass option.

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

Posted: Sat Sep 08, 2012 4:42 am
by MMuser2011
Thank you for the advice with PowerDefragmentor. I didn't know, that we can defrag single files and folders only.

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

Posted: Sat Sep 08, 2012 8:17 am
by Lowlander
Defraggler can too, but it is still not recommended to do this on SSD drives.

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

Posted: Sat Sep 08, 2012 12:59 pm
by MusicBringer
Lowlander wrote:Defraggler can too, but it is still not recommended to do this on SSD drives.
What, not recommended with Defraggler or PowerDefragmentor... or not recommended to defrag an SSD at all?

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

Posted: Sat Sep 08, 2012 1:02 pm
by Lowlander
Not recommended at all. Defragging won't speed up things and only wears down the drive. Defragmenting is only useful when the drive reads best in sequence (regular hdd).

Many SSD will actually write stuff to random places on the drive due to wear leveling technology.

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

Posted: Sat Sep 08, 2012 3:11 pm
by Teknojnky
While it is true that it is not recommended to defrag SSD, simply because of the increased read/write wear (flash memory can only handle so many writes), there is a difference between the logical fragmentation (that the OS see's) and the wear-leveling techniques used to distribute the data across the memory banks.

And while SSD's do have a much much higher performance rate for random access, sequential access is still faster than random.

SO, if you do believe that your performance is being affected by MM database fragmentation, I would suggest one of 2 things.

Either;

a) go ahead and defragment your ssd. It does add additional wear to the drive and can shorten it's life, but if performance is affected, then it may be more important to you than potentially shortened lifespan.

b) (make sure MM is shut down), make a copy of your mm.db file (which now should not be as fragmented), then delete the original and then rename the copy back to mm.db (or whatever the filename was). Now you should have a clean, relatively non-fragmented file, and after deleting the old file, the fragmented space will be marked available for some other use as necessary.

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

Posted: Sun Sep 09, 2012 12:23 pm
by MusicBringer
Teknojnky wrote: b) (make sure MM is shut down), make a copy of your mm.db file (which now should not be as fragmented), then delete the original and then rename the copy back to mm.db (or whatever the filename was). Now you should have a clean, relatively non-fragmented file, and after deleting the old file, the fragmented space will be marked available for some other use as necessary.
Brilliant - why didn't I think of that :P

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

Posted: Sat Sep 15, 2012 5:56 am
by Eyal
But be aware that file defragmentation has no impact on (and is not the same as) database optimization.
File | Maintain Library | Optimize Database

Defrag will not make your library faster if the database is scattered.

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

Posted: Sat Sep 15, 2012 1:56 pm
by MusicBringer
Eyal wrote:Defrag will not make your library faster if the database is scattered.
Eyal, Thank you for mentioning that.
I do run File | Maintain Library | Optimize Database.

Now then, tell me this:
When should I do Quick, as opposed to Complete Optimize Database.
Is one more frequent - the other now and then, or what?
And should I close MM4 after/before running these Maintain Library functions.
For me Complete takes a considerable time to finish its job.
There is no progress bar to tell be how it is behaving.
Sometimes it just hangs there forever and after a long wait I have to kill it - which means that I loose the last played info among other things. Grrhh.
File | Maintain Library | Optimize Database seems to have a mind of its own and does not keep me informed of what is happening.

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

Posted: Sat Sep 15, 2012 3:37 pm
by Teknojnky
MusicBringer wrote: Now then, tell me this:
When should I do Quick, as opposed to Complete Optimize Database.
Is one more frequent - the other now and then, or what?
Well obviously one takes longer, so you ca do the quick one when you don't have time for the complete. Honestly though, I have a *HUGE* database (~1.3gb) and 99% of the time there is minimal performance difference, I doubt it can be noticed without a stopwatch.
And should I close MM4 after/before running these Maintain Library functions.
I do, just to make sure there isn't anything running before the job, and to make sure everything is written/saved afterwards.
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.
There is no progress bar to tell be how it is behaving.
unfortunately sqlite itself does not provide any progress feedback for MM to display.
Sometimes it just hangs there forever and after a long wait I have to kill it - which means that I loose the last played info among other things. Grrhh.
yeah I think this happens sometimes if a background script or process tries to do something while in the middle of an optimize, which is why I restart MM before and after.
File | Maintain Library | Optimize Database seems to have a mind of its own and does not keep me informed of what is happening.
as above, this is more of a sqlite issue, watch the folder where the mm.db is, you can see the files changing as it processes. If the files don't change in a long time, then it might be locked up, but otherwise you should always let it complete on its own, otherwise you risk losing data and/or corruption.