Am 17.02.2010 19:56, schrieb Chuck Swiger: > Hi-- > > On Feb 17, 2010, at 8:03 AM, Harald Schmalzbauer wrote: >> while doing some ZFS tests with RELENG_8 I recognized a mysterious >> performace drop after an hour uptime. >> Now my first idea is to compare MSS and windows sizes before and after the >> performance drop. >> How do I best capture them? tdpcump? It's GbE linkspeed... > > It seems more likely that ZFS is running into slowdowns from resource > contention, memory fragmentation, etc than your network would suddenly drop > out, but tcpdump -w outfile.pcap is a good method of looking....
Thanks, but fisrt tests showed that ZFS is not causing the slowdown. I noticed that disabling window scaling (rfc1323) speeds up the transfer rate by factor 1.5 (rsync transfers start at 75MB/s, settling down at 55MB/s, while rfc1323 enabled leads to half the windows size (8k) and rsync transfers start with 50MB/s and go down to 38MB/s). Now I'm going through "internet core protocols" becaus it's been a long time ago I had such a deep look into TCP/IP and I don't have all the TCP sequences and options in memory. Not falsified yet, but as soon as I open a second high data rate transfer, simultanious to the rsync, (a smb transfer of a large file for example) the shared speed will stay at that level, even if the second transfer has finbished. Meaning: I can rsync with 50MB/s. If I simultaniously transfer another file via samba, I have two 25MB/s transfers. From that moment on I can never get more that 25MB/s per transfer until I reboot the machine. Like mentioned eralier, I first have to refresh some networking basics, but expect some more results soon. Thanks, -Harry
signature.asc
Description: OpenPGP digital signature
