Re: [Netatalk-admins] Performance issues in OS X Finder, 10.8 and 10.9

[Ralph B. <rb...@ne...>]

Hi Chris

Am 29.07.2014 um 16:47 schrieb cf...@fe...:
> I'm trying to troubleshoot performance issues on a netatalk server, 
> version 3.1.2 running on SmartOS (release joyent_20140613T024634Z).

I feel your pain! ;)

> Performance is as expected when copying large files in the finder, 
> opening and saving them in applications, or copying them to and from 
> the server using rsync. However, browsing directories on the server 
> from the Finder is sometimes extremely slow, especially if multiple 
> subdirectories containing many files are involved. Most of the files 
> are media files, e. g. .jpg, .tiff, .mov and .mp4.
> 
> After opening a folder, the window sometimes stays blank for 30 
> seconds or longer (with the spinner running in the bottom right 
> corner) before anything appears, even if the folder contains only 
> 10-20 subfolders or a few hundred files.
> 
> The server is running SmartOS with a large ZFS pool (24 x 4 TB SAS 
> mirrored as 2 x 12), 128 GB RAM and dual 6-core XEON E5 CPUs. It is 
> connected to a NetGear GS752TXS switch via 10GbE (Intel X520), while 
> the workstations are all using 1GbE.
> 
> There are about 20-25 active users. Perhaps 15 work regularly with 
> large media files (e. g. Final Cut Pro).
> 
> As a test, we have configured Samba 3 and connected some clients via 
> SMB (cifs://) rather than AFP.

Beware! If you switch protocol in production without careful evluation whether the metadata you loose is prodcution relevent or not, users may come screaming after you. :)

> These clients are not seeing the 
> slowdowns, so the issue appears to be related to AFP/netatalk in some 
> way.
> 
> I have attempted to observe the client activity on the server by 
> tracking file opens with Dtrace (dtrace-filebyproc.d), and my 
> impression is that the Finder is opening many more files than would 
> seem necessary to display the immediate folder contents. Perhaps it is 
> trying to cache things several levels deep in the folder hierarchy? If 
> so, why are the SMB clients not affected?
> 
> Thanks for any pointers on how to debug this further.

yep, dtrace of course! Attached is a custom dtrace script I wrote but which I didn't include in the Netatalk source tarball yet. I uses both syscall tracepoint as well as application specifc tracepoints, in case the latter are enabled at compile time.

This should show which part of Netatalk and which syscalls consume much time when you see the performance prob.

Otoh, before tracing the problematic behaviour with the dtrace script, you may take a look with Wireshark as to see what the heck the Finder is actually doing at that point.

Good luck!
-Ralph