How does a SSD drive behave with mm.db

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

Moderator: Gurus

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 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

:~)
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 » 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)
MediaMonkey user since 2006

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

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

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

Post 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?
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

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 » 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.

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

nohitter151
Posts: 23640
Joined: Wed Aug 09, 2006 10:20 am
Location: NJ, USA
Contact:

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

Post 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.
MediaMonkey user since 2006
Need help? Got a suggestion? Can't find something?

Please no PMs in reply to a post. Just reply in the thread.

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 » 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.

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

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

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

khelsing
Posts: 251
Joined: Sun Nov 27, 2011 4:11 pm
Location: Germany

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

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


Post Reply