This thread motivated me to do some performance tests for full scans.
Setup: Linux 3.11, ext4 file system, up-to-date LMS 7.8, existing DBs (library.db 130MB, artwork.db 900MB), ~70k audio tracks, 85% mp3 / 15% flac, ~600GB
Scenario 1: music and DB on the same disk
![Name: lmsdisk.jpg
Views: 20
Size: 20.1 KB]()
![Name: lmscpu.jpg
Views: 20
Size: 24.9 KB]()
- scan takes 02:38:33
- wiping the existing library DB took ~5 minutes, audio file discovery starts at 19:46
- nearly all of the time, it's IO bound. The only period the CPU is relevant is during the playlist scan (starts at 21:32) and SmartMix track export (starts at 21:35), both of which have lots of DB queries
- even during artwork pre-caching (starts at 21:43), IO remains the bottleneck (one custom pre-caching specification)
Scenario 2: music and DB on different disks
![Name: lmsdisk_s.jpg
Views: 20
Size: 25.7 KB]()
![Name: lmscpu_s.jpg
Views: 20
Size: 21.2 KB]()
- scan takes 01:16:12
- again, nearly all of the time, it's IO bound
(continued in next post due to attachment restrictions)
Setup: Linux 3.11, ext4 file system, up-to-date LMS 7.8, existing DBs (library.db 130MB, artwork.db 900MB), ~70k audio tracks, 85% mp3 / 15% flac, ~600GB
Scenario 1: music and DB on the same disk
- scan takes 02:38:33
- wiping the existing library DB took ~5 minutes, audio file discovery starts at 19:46
- nearly all of the time, it's IO bound. The only period the CPU is relevant is during the playlist scan (starts at 21:32) and SmartMix track export (starts at 21:35), both of which have lots of DB queries
- even during artwork pre-caching (starts at 21:43), IO remains the bottleneck (one custom pre-caching specification)
Scenario 2: music and DB on different disks
- scan takes 01:16:12
- again, nearly all of the time, it's IO bound
(continued in next post due to attachment restrictions)