Diagnosing slow network shares in OSX Mavericks.

Question

newjerseydan Author

Level 1

0 points

Diagnosing slow network shares in OSX Mavericks.

NAS 1513+

- Two RAID1 volmes, 1 plain disk.

- DSM 4.3-3810 U4

- LACP on 2 1GB ports

2009 Mac Pro

- 2.66Ghz, 32GB RAM, SSD boot drive (1TB)

- OSX 10.9.1

- LACP on 2 1GB ports

- Mount the RAID1 volumes via AFP

- Mount the 1 plain disk via AFP for time capsule.

No updates are currently available for either.

Since upgrading to 10.9, like others I at times get HORRIBLE network attached storage performance, but it is not constant, nor have I found the trigger for it. I have symptoms on both SMB2 -OR- AFP links, not just one or the other. Sometimes I can remedy it by merely booting mounted user from the Synology control panel and then reconnecting to the volume.

Here is an example, copying a 3.85GB file from local disk (SSD) to an AFP NAS volume...it basically was lagging my user interface, but this seems to be because finder/launcherd has some thread blocking issues when the network seems to hiccup.

Traceroute ping against the NAS unit from the MAC, you can see when I attempted to start to copy the file. For note, MAC is 192.168.1.2, NAS is 192.168.1.5, this is a 1024-byte ping:

1032 bytes from 192.168.1.5: icmp_seq=88 ttl=64 time=0.317 ms

1032 bytes from 192.168.1.5: icmp_seq=89 ttl=64 time=0.300 ms

1032 bytes from 192.168.1.5: icmp_seq=90 ttl=64 time=0.368 ms

1032 bytes from 192.168.1.5: icmp_seq=91 ttl=64 time=0.351 ms

1032 bytes from 192.168.1.5: icmp_seq=92 ttl=64 time=0.290 ms

1032 bytes from 192.168.1.5: icmp_seq=93 ttl=64 time=589.964 ms

1032 bytes from 192.168.1.5: icmp_seq=94 ttl=64 time=206.975 ms

1032 bytes from 192.168.1.5: icmp_seq=95 ttl=64 time=325.690 ms

1032 bytes from 192.168.1.5: icmp_seq=96 ttl=64 time=146.775 ms

1032 bytes from 192.168.1.5: icmp_seq=97 ttl=64 time=630.380 ms

1032 bytes from 192.168.1.5: icmp_seq=98 ttl=64 time=2325.074 ms

1032 bytes from 192.168.1.5: icmp_seq=99 ttl=64 time=1323.902 ms

1032 bytes from 192.168.1.5: icmp_seq=100 ttl=64 time=323.091 ms

1032 bytes from 192.168.1.5: icmp_seq=101 ttl=64 time=69.879 ms

1032 bytes from 192.168.1.5: icmp_seq=102 ttl=64 time=190.796 ms

1032 bytes from 192.168.1.5: icmp_seq=103 ttl=64 time=712.165 ms

1032 bytes from 192.168.1.5: icmp_seq=104 ttl=64 time=3.779 ms

1032 bytes from 192.168.1.5: icmp_seq=105 ttl=64 time=229.078 ms

1032 bytes from 192.168.1.5: icmp_seq=106 ttl=64 time=1037.666 ms

I kicked off the mounted user through the interface I had open (once I could get it open, the first to connects timed out) via Firefox on the Synology. I then remounted the volume and copied the same file and it worked fine and fast, here you can see the ping go from .3 to 2.X or so during the copy:

1032 bytes from 192.168.1.5: icmp_seq=0 ttl=64 time=0.312 ms

1032 bytes from 192.168.1.5: icmp_seq=1 ttl=64 time=9.421 ms

1032 bytes from 192.168.1.5: icmp_seq=2 ttl=64 time=0.272 ms

1032 bytes from 192.168.1.5: icmp_seq=3 ttl=64 time=0.293 ms

1032 bytes from 192.168.1.5: icmp_seq=4 ttl=64 time=0.266 ms

1032 bytes from 192.168.1.5: icmp_seq=5 ttl=64 time=2.626 ms

1032 bytes from 192.168.1.5: icmp_seq=6 ttl=64 time=17.977 ms

1032 bytes from 192.168.1.5: icmp_seq=7 ttl=64 time=5.908 ms

1032 bytes from 192.168.1.5: icmp_seq=8 ttl=64 time=2.226 ms

1032 bytes from 192.168.1.5: icmp_seq=9 ttl=64 time=2.511 ms

1032 bytes from 192.168.1.5: icmp_seq=10 ttl=64 time=0.347 ms

1032 bytes from 192.168.1.5: icmp_seq=11 ttl=64 time=0.336 ms

1032 bytes from 192.168.1.5: icmp_seq=12 ttl=64 time=0.297 ms

1032 bytes from 192.168.1.5: icmp_seq=13 ttl=64 time=0.680 ms

1032 bytes from 192.168.1.5: icmp_seq=14 ttl=64 time=2.641 ms

1032 bytes from 192.168.1.5: icmp_seq=15 ttl=64 time=0.347 ms

1032 bytes from 192.168.1.5: icmp_seq=16 ttl=64 time=2.576 ms

Something gets very broken and starts blocking on the network stack. Whatever breaks in the connected volume does NOT fix itself without disconnected the user and reconnecting the volume. During this time, I was able to ping my router from the MAC with no issues.

--- 192.168.1.5 ping statistics ---

30 packets transmitted, 29 packets received, 3.3% packet loss

round-trip min/avg/max/stddev = 14.590/456.075/1846.661/463.270 ms

Tron:~ daniel$ ping -s 1024 192.168.1.1

PING 192.168.1.1 (192.168.1.1): 1024 data bytes

1032 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.720 ms

1032 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.632 ms

1032 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.630 ms

1032 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.602 ms

1032 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.588 ms

1032 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.571 ms

No errors are present in any console logs on the Mac or the NAS unit.

Mac Pro (Early 2009), Mac OS X (10.6)

Posted on Jan 14, 2014 10:47 AM

Reply

Answer 1

Doug Metz

Level 2

348 points

Jan 15, 2014 9:25 AM in response to newjerseydan

Having serious AFP trouble here, too. Similar setup (2009 MacPro w/10.9.1 SSD boot, 1010+ NAS, LCAP, etc).

I'm seeing about 75 Mbps write and 700 Mbps read from the NAS, and interestingly, similar results from our 10.6.8 Server with multiple shares.

When I first set up the NAS, I was on 10.6.8, no SSD, and I was seeing 900 Mbps writes and 1200 Mbps reads.

I cannot afford a 90% drop in write speed. This is ludicrous.

Reply

Answer 2

newjerseydan Author

Level 1

0 points

Jan 15, 2014 9:33 AM in response to Doug Metz

Yeah. I can't get it to reliable be repeatable, it just slowly dies over time.

In 10.8 I would routinely hit the maximum speed of the spindles on my NAS unit pushing 100MB/s both ways on my 2-GB link.

On 10.9 I have never gotten more then 70MB/s when it IS working, and then when it isn't, it drops down to 1-3MB/s if it works at all.

I'm thinking I may roll back to 10.8.4 if this isn't fixed soon... I'm hoping the Jan 16 releae of Synology DSM 5 may get around some of Apple's problem for me.

Reply

Answer 3

Jan 16, 2014 3:32 PM in response to newjerseydan

I've been experiencing horrid transfers, high pings & massive packet loss from a mid-2013 MBA on Mavericks to a new 214+, which was somewhat deflating after 3 years sterling service from the DS210j it replaced!

Yes, obviously I'm connecting via wifi, but pings to other kit in parallel are sub 10ms with 0 packet loss.

Pings from hard wired PCs are a solid wall of <1ms.

Turning off "SMB 2 and large MTU support" is what has just fixed things for me! I haven't measured transfer speeds, but you don't need to read a book between browsing folders on the NAS, pings are sub 10ms again, and no packet loss.

Might be worth a try if you haven't already done so...

Dan

Reply

Answer 4

newjerseydan Author

Level 1

0 points

Jan 17, 2014 5:04 AM in response to ᴰᵃⁿ

I've been trying every combination, and at the moment I'm sitting similar to you - SMB1 no SMB2 for the main shares, which is slower then the AFP performance was against the NAS in 10.8...

This doesn't work for Time Machine though, as Time Machine is only AFP. I've given up for the moment and bought another 4TB drive that I'm going to put in my Mac Pro just for Time Machine rather then backing up to the NAS over the network.

Reply

Answer 5

Jan 17, 2014 6:12 AM in response to newjerseydan

That's interesting - I actually find browsing to the Synology shares in Finder defaults to AFP - SMB is only used now if I specifically mount as smb://

Looking into this further just now I find I've been suffering a cable fault as well - the Airport extreme was only negotiating 100MB and my throughput has been limited to around 1.3MB/s since my network reorganisation, whoops, idiot!

With that fixed, throughput stats are now:

smb1 = 15.4MBps

ftp = 23MBps

afp = 63MBps

I did lots of tests on the last result because it seemed too good to be true, but yeah 802.11ac kicks botty it seems!

(Not sure why FTP is so much lower therefore, perhaps there's an overhead with Yummy FTP)

I shall try SMB2 again later for comparison. Hmm.

Reply

Answer 6

Doug Metz

Level 2

348 points

Jan 17, 2014 6:28 AM in response to newjerseydan

Mine is used as a file server for a couple of video suites, so I only run AFP.

Been doing some testing, and when it quits working, it really quits working! After mounting the share, trying to copy anything or use quicklook will cause the Finder to hang for several minutes, after which time the volume unmounts itself and the Finder comes back to normal. I end up with a zombie AFP process on the NAS with a socket connection that I can't kill (via web GUI or telnet).

I've got a support ticket in with Synology... seems to have started happening after I applied their latest DSM update.

Reply

Answer 7

newjerseydan Author

Level 1

0 points

Jan 17, 2014 7:43 AM in response to Doug Metz

I've had that zombie process thing happen to Doug.

It's really frustrating. I can't figure out what the trigger is that brings it down. Sometimes the mounts are really fast, other times they're horrendous and others they just block like Doug.

Right now I am re-trying a test against my CIFS (SMB1) mounted volume and it's barely cracking 1MB/s.

I just stopped the test, kicked the mounts from the Synology side, remounted, and now it's going along at 60MB/s.

Whatever is happening, it seems to be time based.

Reply

Answer 8

newjerseydan Author

Level 1

0 points

Jan 17, 2014 7:54 AM in response to newjerseydan

I just did another round...

Read/write a 3GB file:

58MBs/20MBs CIFS

90MBs/50MBs AFP

05MBs/??? SMB2

The SMB2 was so bad I lost the patience for it to write the 3GB file before it could read it back.

The problem is I have to unmount/mount the AFP for CIFS volumes recurringly to keep that performance level, the longer they stay connected, the crappier they become.

Reply

Answer 9

Jan 17, 2014 7:59 AM in response to newjerseydan

should we use AFP then? I am having trouble with NAS+10.9.

I have modified the preference to use CIFS as default, little better but still fails from time to time.

might find this helpful?

http://support.apple.com/kb/HT4700

Reply

Answer 10

newjerseydan Author

Level 1

0 points

Jan 19, 2014 4:05 PM in response to phoneuser

I am sticking with AFP for now though I've stopped using network Time Machine and moving it to a local drive for now.

When it starts to lag, I just kill the mount and remount it. Annoying, but kind of holding it over.

That link is for authenitcation errors, we're not having that.

Reply

Answer 11

Doug Metz

Level 2

348 points

Jan 25, 2014 2:47 PM in response to newjerseydan

The response I got from Synology Tech Support, after a few rounds of testing and sending them debug files, is that my NAS has some file system corruption which is likely the result of improper shutdown. We had a couple of instances of power going out and the NAS isn't on UPS. The solution offered is to backup the entire volume, wipe it out, and start over.

This is going to take some time. Get yourself a decent battery backup and use it. I know I will... 😐

Reply

Answer 12

newjerseydan Author

Level 1

0 points

Jan 25, 2014 3:41 PM in response to Doug Metz

Really... interesting. I do have mine on a UPS now, but it's a new one because I had a UPS go bad that reset on me a few times while my gear was on. How were they able to show the file corruption? I've got no errors in the NAS logs.

Reply

Answer 13

Jan 30, 2014 12:03 PM in response to newjerseydan

I updated the system to stick with AFP by default. So far the connection is fine and time machine works fine as well.

Reply

Answer 14

newjerseydan Author

Level 1

0 points

Jan 30, 2014 2:20 PM in response to phoneuser

What do you mean "updated the system" ?

My time capsule and any large number of small file functions still end up slowing down tremendously. I've got local disk for time machine at the moment.

Reply

Answer 15

chain86

Level 1

8 points

Feb 8, 2014 3:26 AM in response to newjerseydan

Updated DSM to Update 4 AND setup privacy settings for spotlight to exclude network volumes (which should the default behavior imho)! Tip is from https://discussions.apple.com/thread/5500165?answerId=24721511022#24721511022 by -KEPHSTER-

this combo does the trick for me!

Reply