How does a SSD drive behave with mm.db

Post a reply

Smilies
:D :) :( :o :-? 8) :lol: :x :P :oops: :cry: :evil: :roll: :wink:

BBCode is ON
[img] is ON
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: How does a SSD drive behave with mm.db

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

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

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

by MusicBringer » Mon Sep 17, 2012 3:13 am

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

by Teknojnky » Sun Sep 16, 2012 11:44 pm

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

by nohitter151 » Sun Sep 16, 2012 7:15 pm

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

by MusicBringer » Sun Sep 16, 2012 4:30 pm

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

by Teknojnky » Sun Sep 16, 2012 11:46 am

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

by MMuser2011 » Sun Sep 16, 2012 5:07 am

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

by MusicBringer » Sun Sep 16, 2012 4:17 am

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

by MusicBringer » Sun Sep 16, 2012 4:12 am

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

by Eyal » Sat Sep 15, 2012 3:40 pm

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

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.

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

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.

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

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.

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

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

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

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.

Top