PDA

View Full Version : 5.1.1 Performance under Linux



Electric Slimpy
2004-03-09, 11:30
I just upgraded to the latest nightly build (03-08-04).. I was very
excited to see the tag caching option. Could this be the performance
improvement I have been waiting for?? Unfortunately, not yet.

I was previously running a 5.0.1 nightly on my slimp3 and have been a
user for over two years. I was hoping for great improvements in
performance with this release.

So, after starting the new version and giving it ample time to load
and cache my music, here is what I am seeing..

I have a music folder with approximately 800 sub dirs. Once in the
Browse Music Folder I can enter one of those sub-dirs quickly using
right arrow. But when I left arrow to go back up to my Music Folder it
takes 3 to 4 seconds until the remote/slimp3 is responsive again.
This is repeatable over and over. I think I get a little cursor
spinning while waiting.

Why does this take so long? I can understand the delays when first
entering the music folder. But I don't see why it should be so
resource intensive to merely pop back up from a subdir.

Process size increased (up from about 90MB) when I enabled caching:

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
slimp3 32205 4.4 41.5 114832 106772 ? S 08:26 10:42 slimserver

Here is what my system activity looks like under vmstat when I first
descend into the subdir and then pop back up to the main music folder.

Drop down into the sub dir, wait 5 seconds and then pop back up:

procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 19120 9604 34316 64808 0 0 0 0 114 9 0 0 100
0 0 0 19120 9604 34316 64808 0 0 0 0 132 65 6 0 94
0 0 0 19120 9604 34316 64808 0 0 0 0 114 8 0 0 100
0 0 0 19120 9604 34316 64808 0 0 0 21 122 11 0 0 100
0 0 0 19120 9604 34316 64808 0 0 0 0 114 9 0 0 100
0 0 0 19120 9600 34320 64808 0 0 4 0 117 15 0 0 100
0 0 0 19120 9600 34320 64808 0 0 0 0 116 11 0 0 100
0 0 0 19120 9600 34320 64808 0 0 0 0 114 9 0 0 100
1 0 0 19120 9596 34328 64808 0 0 0 12 120 15 90 0 10
1 0 0 19120 9592 34328 64808 0 0 0 0 116 10 96 1 3
0 0 0 19120 9592 34328 64808 0 0 0 0 126 53 1 0 99
0 0 0 19120 9592 34328 64808 0 0 0 0 114 7 0 0 100

Why does it take so much more CPU churn to pop back up vs. descend??

Clearly, this output indicates that the OS is not going out and
re-reading content from the disk. Nor does the OS have any difficulty
rapidly extracting info on all of those subdirs from the buffer
cache. An 'ls -l' of the music folder takes almost no time once the
data is cached:

slimphost# time ls -l > /dev/null
0.040u 0.020s 0:00.05 120.0% 0+0k 0+0io 196pf+0w

Thank you for the insight!



Dedicated server details:

Linux 2.4.23/Gentoo
458 Mhz Celeron
256 MB memory
WD 7200 RPM ATA drive

MP3DIR Mount options:
ext2, readonly, noatime



__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com