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
:~)
How does a SSD drive behave with mm.db
Moderator: Gurus
-
- Posts: 622
- Joined: Wed Oct 25, 2006 12:53 pm
Re: How does a SSD drive behave with mm.db
Teknojnky, you went to a lot of trouble to compose your very helpful reply - thank you for that
Eyal, thanks for those links
Eyal, thanks for those links
MediaMonkey user since 2006
-
- Posts: 622
- Joined: Wed Oct 25, 2006 12:53 pm
Re: How does a SSD drive behave with mm.db
Reading this, I now wonder whether it is this process that is causing the "more than 3000" fragments to the MM.db fileTeknojnky wrote:MusicBringer 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.For me Complete takes a considerable time to finish its job.
MediaMonkey user since 2006
-
- Posts: 1308
- Joined: Mon Oct 17, 2011 8:28 am
- Location: Central Europe
Re: How does a SSD drive behave with mm.db
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?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.
● 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
● 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
Re: How does a SSD drive behave with mm.db
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.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?
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.Reading this, I now wonder whether it is this process that is causing the "more than 3000" fragments to the MM.db file
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.
New script: Last.FM Node Now with DJ Mode!
Last.fm + MediaMonkey = Scrobbler DJ!
Tag with MusicBrainz ~ Get Album Art!
Tweak the Monkey! ~ My Scripts Page
Last.fm + MediaMonkey = Scrobbler DJ!
Tag with MusicBrainz ~ Get Album Art!
Tweak the Monkey! ~ My Scripts Page
-
- Posts: 622
- Joined: Wed Oct 25, 2006 12:53 pm
Re: How does a SSD drive behave with mm.db
...make a copy is now part of my housekeeping routine.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.
MediaMonkey user since 2006
-
- Posts: 23640
- Joined: Wed Aug 09, 2006 10:20 am
- Location: NJ, USA
- Contact:
Re: How does a SSD drive behave with mm.db
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.MusicBringer wrote:...make a copy is now part of my housekeeping routine.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.
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.
Need help? Got a suggestion? Can't find something?
Please no PMs in reply to a post. Just reply in the thread.
Re: How does a SSD drive behave with mm.db
This is not entirely accurate.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.
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.
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.If you want to improve performance of an SSD, you should be worried about keeping a larger portion of the drive as empty space.
New script: Last.FM Node Now with DJ Mode!
Last.fm + MediaMonkey = Scrobbler DJ!
Tag with MusicBrainz ~ Get Album Art!
Tweak the Monkey! ~ My Scripts Page
Last.fm + MediaMonkey = Scrobbler DJ!
Tag with MusicBrainz ~ Get Album Art!
Tweak the Monkey! ~ My Scripts Page
-
- Posts: 622
- Joined: Wed Oct 25, 2006 12:53 pm
Re: How does a SSD drive behave with mm.db
I have one third Used space with two thirds Free space - so that's alright thennohitter151 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.
MediaMonkey user since 2006
Re: How does a SSD drive behave with mm.db
MusicBringer,
you might want to read this:
http://blogs.msdn.com/b/e7/archive/2009 ... s-and.aspx
http://www.oo-software.com/en/docs/whit ... od_ssd.pdf
you might want to read this:
http://blogs.msdn.com/b/e7/archive/2009 ... s-and.aspx
http://www.oo-software.com/en/docs/whit ... od_ssd.pdf