CPU Usage very high on new server (shfs process)

[bfeist]

Hi all,

This is my first post. I'm in the process of putting together my first unRAID server. Currently I have 3 1.5TB drives with no parity drive (I'm copying everything first before initiating parity).

 

I noticed that when accessing the file system to perform a copy of data to the server, or to get properties on files on the server via my Windows7 box, the "shfs" process spikes CPU usage on the unRAID server to 150%+ until the copy process is over. The server also feels quite sluggish to respond from my windows computer.

 

I'm running an AMD X2 5200+ on a Gigabyte GA-MA74GM-S2 motherboard. I've done some searches on the shfs process and nobody seems to be talking about it being a CPU hog.

 

I'm running unRAID 4.5beta7

 

Any advice? I want the nice snappy response and low power consumption I read so much about before putting this box together.

 

UPDATE: If I access a drive share (\\tower\disk3) instead of a user share, the shfs process stays at 0% and copying is as fast as would be expected.

 

Ben

[BRiT]

Try the 4.5beta8 version. It has a bit of performance improvements for writes to disk and network file copying. Also try copying directly to the disk shares [/dev/disk#/] instead of the user shares.

[bfeist]

I've switched to beta8 and it appears to be much better. the process peaks at about 50% cpu when copying many small files. Thanks for the suggestion, I hadn't even realized that beta8 was available.

 

Ben

[kapperz]

I'm having the same trouble with the shfs process. If I re-mount my shares with the same command unRaid uses, but add the 'debug' option. I can see this process reading every single file when any directory is accessed. The discs don't spin up since I'm using Joe's cache_dir script, but the file names are being processed. Try it with a folder with 1000+ files. I would think this would be super fast if its all in RAM.

 

/usr/local/sbin/shfs /mnt/user -o noatime,big_writes,allow_other,attr_timeout=0,entry_timeout=0,negative_timeout=0,debug

 

I'm using subsonic music streamer and it lists sub-folders for a given path. Since the sub-folder is being accessed, all the files are being read. I have a few folders with 800-1200 sub-folders. This can take 5+ minutes to bring up the list. The shfs process is just pegged the whole time (htop or top command). I over-clocked my AMD Sempron 140 (2.7GHz single-core) to 3.5Ghz and the listing process was cut almost in half. Even so, 2-3min is still slow and my system was not stable (I didn't take the time to fine tune it). Maybe I will just upgrade to a dual-core Once a folder finally comes up, it seems to get cached and the next listing is less than a second. If I reboot, I'm back to waiting.

 

What is this shfs process? Are there any optimization tricks with the shfs options I can try? I have my eye on a AMD Phenom II X2 550 Black, but I hate to ruin a good low power server.

 

[limetech]

I'm having the same trouble with the shfs process. If I re-mount my shares with the same command unRaid uses, but add the 'debug' option. I can see this process reading every single file when any directory is accessed. The discs don't spin up since I'm using Joe's cache_dir script, but the file names are being processed. Try it with a folder with 1000+ files. I would think this would be super fast if its all in RAM.

 

/usr/local/sbin/shfs /mnt/user -o noatime,big_writes,allow_other,attr_timeout=0,entry_timeout=0,negative_timeout=0,debug

 

I'm using subsonic music streamer and it lists sub-folders for a given path. Since the sub-folder is being accessed, all the files are being read. I have a few folders with 800-1200 sub-folders. This can take 5+ minutes to bring up the list. The shfs process is just pegged the whole time (htop or top command). I over-clocked my AMD Sempron 140 (2.7GHz single-core) to 3.5Ghz and the listing process was cut almost in half. Even so, 2-3min is still slow and my system was not stable (I didn't take the time to fine tune it). Maybe I will just upgrade to a dual-core Once a folder finally comes up, it seems to get cached and the next listing is less than a second. If I reboot, I'm back to waiting.

 

What is this shfs process? Are there any optimization tricks with the shfs options I can try? I have my eye on a AMD Phenom II X2 550 Black, but I hate to ruin a good low power server.

 

 

Why do you think files are being read?  Probably what you are seeing are LOOKUP requests.

 

Please provide a few screen-fulls of debug output so I can verify.

 

EDIT: nevermind above.  Instead try this mount command and then let me know if performance is increased:

 

/usr/local/sbin/shfs /mnt/user -o noatime,big_writes,allow_other

 

[kapperz]

I spun down all the disks and ran "umount /mnt/user/" and then ran the above shfs command for dubug output. Refreshing the unRaid page still shows all green blinking. When I use subsonic to access one of the large music folders, I get the following output in the telnet session (shfs below). unRaid still showed all green blinking. I noticed in another telnet session running the 'top' command, the cpu was ~2-15% and shfs wasn't being a hog. Although, it was still taking many minutes to list the folder as usual.

 

This really isn't a unRaid issue. Browsing to the same directory (though shares) with 1200 subfolders has a slight delay, but only a few seconds. It could be the JAVA JRE runtimes causing overhead. I have 2GB of RAM and attached a few screen shot of what is happening when I see shfs spike.

 

I've been working with the developer a little and he had this to say about what happens when a music folder is chosen...

 

First of all, the page controller implements the "last-modified" / "if-modified-since" http headers, so that the client (web browser) can use its cache whenever possible. The last-modified time is calculated as the latest modification date of the relevant music root folders, but it also takes in to account when certain preferences were changed last.

 

Secondly, the page controller looks up in an on-disk cache containing the directory structure. This cache is stored in TMP/subsonic/ehcache">TMP/subsonic/ehcache, where TMP is the system's default temp directory (typically /tmp).

 

Thirdly, if there is no cache it, Subsonic will create a data structure representing the directory structure. In terms of disk I/O this basically boils down to a java.util.File.listFiles() call on the top level directory.

 

 

 

 

 

shfs

top

vmstat memory

[limetech]

Thanks for the follow up kapperz.  The upcoming -beta9 release now excludes the "attr_timeout=0,entry_timeout=0,negative_timeout=0" options when mounting the user share file system.  This might not help your situation but should speed up some operations, especially SMB (Windows Networking) which involve large directories.

[kapperz]

I did not see your edit before I upgraded to Beta 9. I did try the above mount command on beta 9 and the large folders come up within 10 seconds (same speed as with default beta9). I would be happy to downgrade to beta 8 and try if that will help you. I'm so happy that subsonic is running faster than on my Windows machine.

 

/usr/local/sbin/shfs /mnt/user -o noatime,big_writes,allow_other

 

Above looks to be the default when unRaid boots, right? I don't need to add "attr_timeout=0,entry_timeout=0,negative_timeout=0"

[limetech]

I did not see your edit before I upgraded to Beta 9. I did try the above mount command on beta 9 and the large folders come up within 10 seconds (same speed as with default beta9). I would be happy to downgrade to beta 8 and try if that will help you. I'm so happy that subsonic is running faster than on my Windows machine.

 

/usr/local/sbin/shfs /mnt/user -o noatime,big_writes,allow_other

 

Above looks to be the default when unRaid boots, right? I don't need to add "attr_timeout=0,entry_timeout=0,negative_timeout=0"

 

Right, do not add those options.