How does a SSD drive behave with mm.db

Get answers about using the current release of MediaMonkey for Windows.

Moderator: Gurus

MusicBringer
Posts: 622
Joined: Wed Oct 25, 2006 12:53 pm

How does a SSD drive behave with mm.db

Post by MusicBringer » Fri Sep 07, 2012 11:01 am

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,
MediaMonkey user since 2006

Lowlander
Posts: 45853
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

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

Post by Lowlander » Fri Sep 07, 2012 11:50 am

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.
Lowlander (MediaMonkey user since 2003)

MusicBringer
Posts: 622
Joined: Wed Oct 25, 2006 12:53 pm

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

Post by MusicBringer » Fri Sep 07, 2012 12:38 pm

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?
MediaMonkey user since 2006

Lowlander
Posts: 45853
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

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

Post by Lowlander » Fri Sep 07, 2012 12:49 pm

The amount of fragments doesn't matter on a SSD.
Lowlander (MediaMonkey user since 2003)

MusicBringer
Posts: 622
Joined: Wed Oct 25, 2006 12:53 pm

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

Post by MusicBringer » Fri Sep 07, 2012 1:39 pm

Ta.
MediaMonkey user since 2006

NWDreamer
Posts: 103
Joined: Fri Aug 24, 2012 4:12 am

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

Post by NWDreamer » Fri Sep 07, 2012 9:07 pm

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.
Craig B. (a.k.a., NW Dreamer - Gold MediaMonkey user.)

MMuser2011
Posts: 1290
Joined: Mon Oct 17, 2011 8:28 am
Location: Central Europe

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

Post by MMuser2011 » Sat Sep 08, 2012 4:42 am

Thank you for the advice with PowerDefragmentor. I didn't know, that we can defrag single files and folders only.
Magic Nodes v4.3.3 (2018-10-03) last free version SQL Viewer v2.4 (2009-10-25)
ExternalTools v1.4 (2011-05-09) iTunesMonkey 1.0 + Acoustid
Calculate Cover Size v1.7 (2012-10-23) RegExp Find & Replace v4.4.9 (2018-10-03) last free version

Lowlander
Posts: 45853
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

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

Post by Lowlander » Sat Sep 08, 2012 8:17 am

Defraggler can too, but it is still not recommended to do this on SSD drives.
Lowlander (MediaMonkey user since 2003)

MusicBringer
Posts: 622
Joined: Wed Oct 25, 2006 12:53 pm

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

Post by MusicBringer » Sat Sep 08, 2012 12:59 pm

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?
MediaMonkey user since 2006

Lowlander
Posts: 45853
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

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

Post by Lowlander » Sat Sep 08, 2012 1:02 pm

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.
Lowlander (MediaMonkey user since 2003)

Teknojnky
Posts: 5533
Joined: Tue Sep 06, 2005 11:01 pm
Contact:

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

Post by Teknojnky » Sat Sep 08, 2012 3:11 pm

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.

MusicBringer
Posts: 622
Joined: Wed Oct 25, 2006 12:53 pm

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

Post by MusicBringer » Sun Sep 09, 2012 12:23 pm

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
MediaMonkey user since 2006

Eyal
Posts: 3109
Joined: Sun Jun 26, 2005 9:27 am
Location: Québec

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

Post by Eyal » Sat Sep 15, 2012 5:56 am

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.
Skins for MediaMonkey: Cafe, Carbon, Helium, Spotify, Zekton. [ Wiki Zone ].

MusicBringer
Posts: 622
Joined: Wed Oct 25, 2006 12:53 pm

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

Post by MusicBringer » Sat Sep 15, 2012 1:56 pm

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.
MediaMonkey user since 2006

Teknojnky
Posts: 5533
Joined: Tue Sep 06, 2005 11:01 pm
Contact:

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

Post by Teknojnky » Sat Sep 15, 2012 3:37 pm

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.

Post Reply