Thanks Moonbase for this thread. For folks with a relatively powerful Squeezebox Server system and **RAM to burn** :-), I've attached my settings for "my.tt". For those running into trouble, rebooting and doing a "Clear library and rescan everything" will avoid database issues.
On my system (4G RAM, Opteron 165 Dual Core @2GHz, SB Server 7.5.1, 53K songs on 1.5TB WD Caviar Green SATA, 600x600+ artwork, 70% FLAC, ~200 24/96+ albums/LP rips), a full rescan was >30% faster and day-to-day use appears speedier. Web interface quite snappy and CLI apps like iPeng & SqueezePad at times instantaneous. Details below... As usual, YMMV :-) Archimago ----------------------------- Tests (these are all "Clear library and rescan everything" times after a reboot): Squeezebox Server Information: Version: 7.5.1 - r30836 @ Tue Jun 1 06:02:45 PDT 2010 Operating system: Windows 2008 Server R2 - EN - Platform Architecture: 586 Perl Version: 5.10.0 - MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt-log Default my.tt: (sorry, didn't copy and paste detailed timings) Total Time: 1:55:05 Moonbase's my.tt: Total Time: 1:40:20 Moonbase's my.tt + 300M innodb_buffer_pool_size: Directory Scan (53293 of 53293) Complete 00:53:49 Playlist Scan (3 of 3) Complete 00:00:00 Merge Various Artists (3785 of 3785) Complete 00:01:27 Artwork Scan (3928 of 3928) Complete 00:40:46 Total Time:01:36:02 ArchMega500 my.tt (500M innodb_buffer_pool_size + key_buffer, etc. tweaks): Directory Scan (53293 of 53293) Complete 00:31:25 Playlist Scan (3 of 3) Complete 00:00:00 Merge Various Artists (3786 of 3786) Complete 00:01:29 Artwork Scan (3929 of 3929) Complete 00:40:30 Total Time:01:13:24 Observation: 1. With just my FTP Server and Apache running in the background unused, Windows reports physical memory usage not to exceed 2.2GB through the scan. Memory usage drops thereafter in day-to-day use. 2. I don't see much multithreading going on at all, Directory Scan uses about 30-40% CPU, Artwork Scan only uses up to 50% of the dual cores. Therefore, HD speed, MHz/GHz speed more important than # cores for the scanning process. 3. IMO key_buffer and table_cache just as significant as innodb_buffer_pool_size. I actually did not notice any difference between 300M to 500M for the pool_size but decided to leave it as 500M to give the database room to grow. 4. An interesting related article: http://www.debianhelp.co.uk/mysqlperformance.htm +-------------------------------------------------------------------+ |Filename: ArchMega500v2-my.tt.txt | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=10550| +-------------------------------------------------------------------+ -- Archimago ------------------------------------------------------------------------ Archimago's Profile: http://forums.slimdevices.com/member.php?userid=2207 View this thread: http://forums.slimdevices.com/showthread.php?t=70371 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/discuss
