toasters January 2003

toasters@lists.teaparty.net

69 participants
78 discussions

Backup performances
by matej.moskon＠ourspace.si 27 Jan '03

27 Jan '03

Hi toasters! I'm facing with very odd performance issue during the backup of snapshots. I have OmniBak Disk Agent instaled on HP-UX 11.0 and F740 DOT 6.0.1R3 when I start with backup procedure, the performances are as follow (sysstat 2): CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache 21% 179 12 0 113 1061 2205 0 0 0 1 19% 207 8 0 167 1153 1132 0 0 0 1 21% 127 8 0 114 555 1473 868 0 0 1 17% 128 51 0 118 514 525 0 0 0 1 16% 114 15 0 124 319 353 0 0 0 1 16% 109 11 0 116 347 656 0 0 0 1 16% 123 5 0 127 308 369 0 0 0 1 20% 168 10 0 117 894 878 844 0 0 1 16% 115 5 0 143 331 543 0 0 0 1 16% 123 12 0 138 283 241 0 0 0 2 18% 147 9 0 131 623 1370 0 0 0 2 29% 364 7 0 183 2970 6333 0 0 0 2 As you can see, there is practicaly no network traffic. When I perform more load on Filer thrue HP server (such as tar or copy data on filer), the speed of writing on LTO is about 10 times faster: CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache 76% 1093 41 0 388 23459 22188 1114 0 0 0 69% 1065 8 0 296 23111 22049 0 0 0 0 65% 735 6 0 342 20897 20332 0 0 0 0 58% 673 14 0 270 17603 17106 0 0 0 0 68% 869 48 0 257 22127 21323 0 0 0 0 82% 1020 50 0 7776 14957 13749 1315 0 0 0 77% 925 15 0 3213 13063 13185 8583 0 0 0 76% 1163 10 0 350 25681 24400 0 0 0 0 67% 986 63 0 389 19134 19058 0 0 0 0 68% 922 288 0 315 19461 18464 0 0 0 0 66% 943 101 0 248 20260 18998 0 0 0 0 75% 1067 9 0 277 23741 23182 458 0 0 0 79% 1025 14 0 270 22664 22671 4621 0 0 0 76% 891 24 0 236 26903 25523 0 0 0 0 80% 1064 164 0 314 26847 25485 0 0 0 0 Do you have any idea what is going on? Matej ---------------------------------------- Matej Moškon Our Space Appliances d.o.o. Tbilisijska 59, 1111 Ljubljana email: matej.moskon(a)ourspace.si tel: + 386 01 24 25 392 faks: + 386 01 24 25 382 http://www.ourspace.si ----------------------------------------

2 1

[Fwd: CORR PROC ERR 86]
by Dan OBrien 27 Jan '03

27 Jan '03

Resend due to list errors last week. -- Dan O'Brien, dmobrien(a)lcsi.net Cell: 614-783-4859 Work: 614-476-8473 Home: 740-927-2178 Pataskala, OH

2 1

RE: Filer setting tcp.wsize to 0 -> NFS timeouts
by Aldrich David S 24 Jan '03

24 Jan '03

Here's the description and workaround from NOW for Bug ID 29146. It might help with your problem. Description: In Data ONTAP 5.3.4 and earlier releases the default UDP transfer size is 8192. In 5.3.5 and later releases the default is 32768. This larger value improves performance in some situations, but may cause problems in others. Problem 1 - 100-Mbit client is reading from Gigabit interface With the larger default, problems may result when the Gigabit interface on the filer is sending to a 100-Mbit client. Switches can drop packets on the outbound 100-Mbit port because too many packets become queued due to the difference in line speeds and the larger transfer size. Few complete 32K UDP datagrams are received by the client, and the client assumes the filer has gone away and increases its delay between retries. Poor performance may be seen. If a client does not specify the rsize and wsize parameters in the mount command, the filer's default UDP transfer size is used. If a client does specify rsize and wsize, and the values are larger than the default, then the default is used. This means that you may see problems after you upgrade from 5.3.4 (or earlier release) to 5.3.5 (or later release) if the resulting transfer size is 32768. Problem 2 - Multiple clients are reading from 100-Mbit interface When the UDP transfer size is 32768 and multiple clients are reading from a 100-Mbit interface, the driver transmit queue on the filer can overflow more readily and packets may be discarded. This can lead to erratic or poor performance on the clients. Workaround: If you have only 100-Mbit clients, the easiest workaround is to change the default UDP transfer size on the filer. First, display the current value: options nfs.udp.xfersize If the value displayed is greater than 8192, then change the value: options nfs.udp.xfersize 8192 If you have both Gigabit and 100-Mbit clients, instead of doing the above you may just want to insert "rsize=8192,wsize=8192" into the mount commands on your 100-Mbit clients and set the filer's default transfer size to 32768. By doing this, the Gigabit clients can benefit from the larger transfer size. If you have only Gigabit interfaces on the filer and the clients, the default UDP transfer size can be set to 32768 to improve performance. Regardless of the transfer size, if you have Sun clients with Sun Gigabit/2.0 NICs, you should enable transmit flow control on the Sun NIC and ensure that receive flow control is enabled on the switch port. The Sun Gigabit/2.0 NIC drops packets because it can't keep up with the filer. In such situations, enabling flow control can substantially improve performance. If you are using an FDDI interface in the filer and a UDP transfer size of 32768, you might want to make sure that all FDDI clients attached to the ring can handle the larger burst in traffic due to the increased transfer size. Dave -----Original Message----- From: Jeff Bryer [mailto:bryer@sfu.ca] Sent: Friday, January 24, 2003 12:47 PM To: Pawel Rogocz Cc: toasters(a)mathworks.com Subject: Re: Filer setting tcp.wsize to 0 -> NFS timeouts We've experienced the same behaviour. On two separate systems. An F740 running 6.1.2R3 connected to a 420R running Sol 8 using a SUN GigE card. And on an F810 running 6.2.1R2 connected to a V880 running Sol 8 using the onboard GigE port. We've switched to running NFS v3 over UDP on the F740 (which is the only GigE we have in production on our NetApps). We haven't had any performance issues since. This filer is housing DB/2. We do have a co-locate F740 connected via GigE to a Linux RedHat machine, but it has only ever been configured to use NFS v2 over UDP with an 8K window size. There is some interest to switch it over to TCP to see if the problems with reducing window size happen there. On Thu, Jan 23, 2003 at 10:49:49PM -0800, Pawel Rogocz wrote: > I have been having NFS performance problems with our F820 / 6.2.1R2 > for quite some time now. The filer has a GigE card, but when we start > pushing about 10MB/sec ( 50 % CPU load ) we get numerous NFS timeouts from solaris > clients mounting the filer via tcp. None of the filer stats (statit et all) > show any bottleneck on any of the disks. > Looking at network traces from a mirrored port, I see the filer > at some point reducing tcp window size to 0, down from its normal > value - 26280. Looks like it is running out of juice. > Any ideas what might be causing this ? > > > Pawel > > > - -- Jeff Bryer bryer(a)sfu.ca Systems Administrator (604) 291-4935 Academic Computing, Simon Fraser University

1 0

UDP vs. TCP
by Charles Bartels 24 Jan '03

24 Jan '03

> We've switched to running NFS v3 over UDP on the F740 (which is the > only GigE we have in production on our NetApps). We haven't had > any performance issues since. This filer is housing DB/2. What are the pros/cons of running UDP as opposed to TCP ? UDP doesn't have the same error correction, ja? Isn't that inherently unstable or dangerous? -Charles Bartels

1 0

Filer setting tcp.wsize to 0 -> NFS timeouts
by Pawel Rogocz 24 Jan '03

24 Jan '03

I have been having NFS performance problems with our F820 / 6.2.1R2 for quite some time now. The filer has a GigE card, but when we start pushing about 10MB/sec ( 50 % CPU load ) we get numerous NFS timeouts from solaris clients mounting the filer via tcp. None of the filer stats (statit et all) show any bottleneck on any of the disks. Looking at network traces from a mirrored port, I see the filer at some point reducing tcp window size to 0, down from its normal value - 26280. Looks like it is running out of juice. Any ideas what might be causing this ? Pawel -

2 1

RE: disappearing CIFS permissions ...
by Waters, G Scott DSTI 24 Jan '03

24 Jan '03

We were running 6.2R2 since it was released and we were seeing the problem occasionally. We recently (in the last week) upgraded to 6.2.2 - it hasn't been in place long enough to say if things have changed. - Scott W. -----Original Message----- From: Nail, Larry [mailto:lnail@ti.com] Sent: Friday, January 24, 2003 11:01 AM To: 'toasters(a)mathworks.com' Subject: RE: disappearing CIFS permissions ... Scott, We had the same set of problems when we were running 5.3.7 on the filers... when we upgraded to 6.x, we stopped seeing those problems. The only problem we did resolve was we had a share name "L&I". When we renamed the share to LnI, it stopped dropping it's permissions. Larry -----Original Message----- From: Waters, G Scott DSTI [mailto:george.scott.waters@us.army.mil] Sent: Friday, January 24, 2003 9:32 AM To: 'toasters(a)mathworks.com' Subject: disappearing CIFS permissions ... Has anyone had any problems with setting CIFS share permissions and then having them disappear?? We have a series of scripts that run at night that manage our users in our NT4 domain. Our users are created and then for each user a home share is created on our filer. Every once in a while we will get a complaint that one of our new users can not access their home share. I check the share and sure enough the permissions are not there. However, when I check the output from our scripts they show that the permissions were set successfully. The user is created in the script by using the NET USER command and the shares are manipulated by the RMTSHARE program from the NT Resource Kit. After the user is created Domain Admins are granted permissions to the SHARE (and those permissions are always there) then the user is granted permissions (and that is where the problem occasionally occurs). It's an annoyance that I can't explain ... and I don't like those. If anyone has any ideas / suggestions / etc, etc ... please let me know. Thanks. - Scott W.

1 0

RE: disappearing CIFS permissions ...
by Waters, G Scott DSTI 24 Jan '03

24 Jan '03

Stacie ... The QTree is NTFS. The script runs on the domain controller and sets share permissions on the filer ... and the problem is *very* intermittent. - Scott W. -----Original Message----- From: sjmontoya [mailto:sjmontoya@micron.com] Sent: Friday, January 24, 2003 11:02 AM To: 'Waters, G Scott DSTI'; 'toasters(a)mathworks.com' Subject: RE: disappearing CIFS permissions ... Scott, What type is assigned to the qtree that is being shared out as CIFS? Where is your script granting the user permissions? On the NetApp itself? Or from NT? I have recently been setting up CIFS shares from qtrees that are "mixed". What I have noticed is that permissions changes made on the UNIX side show up in the NT ACLs and vice versa. I've also noticed that "Special permissions" are given in the case where the user might not be in the NT group that has been given permissions, but is in the UNIX group that owns the file/directory. Stacie Montoya

1 0

RE: disappearing CIFS permissions ...
by Nail, Larry 24 Jan '03

24 Jan '03

Note this was a CIFS only filer in this case. -----Original Message----- From: Nail, Larry Sent: Friday, January 24, 2003 10:01 AM To: 'toasters(a)mathworks.com' Subject: RE: disappearing CIFS permissions ... Scott, We had the same set of problems when we were running 5.3.7 on the filers... when we upgraded to 6.x, we stopped seeing those problems. The only problem we did resolve was we had a share name "L&I". When we renamed the share to LnI, it stopped dropping it's permissions. Larry -----Original Message----- From: Waters, G Scott DSTI [mailto:george.scott.waters@us.army.mil] Sent: Friday, January 24, 2003 9:32 AM To: 'toasters(a)mathworks.com' Subject: disappearing CIFS permissions ... Has anyone had any problems with setting CIFS share permissions and then having them disappear?? We have a series of scripts that run at night that manage our users in our NT4 domain. Our users are created and then for each user a home share is created on our filer. Every once in a while we will get a complaint that one of our new users can not access their home share. I check the share and sure enough the permissions are not there. However, when I check the output from our scripts they show that the permissions were set successfully. The user is created in the script by using the NET USER command and the shares are manipulated by the RMTSHARE program from the NT Resource Kit. After the user is created Domain Admins are granted permissions to the SHARE (and those permissions are always there) then the user is granted permissions (and that is where the problem occasionally occurs). It's an annoyance that I can't explain ... and I don't like those. If anyone has any ideas / suggestions / etc, etc ... please let me know. Thanks. - Scott W.

1 0

RE: disappearing CIFS permissions ...
by sjmontoya 24 Jan '03

24 Jan '03

Scott, What type is assigned to the qtree that is being shared out as CIFS? Where is your script granting the user permissions? On the NetApp itself? Or from NT? I have recently been setting up CIFS shares from qtrees that are "mixed". What I have noticed is that permissions changes made on the UNIX side show up in the NT ACLs and vice versa. I've also noticed that "Special permissions" are given in the case where the user might not be in the NT group that has been given permissions, but is in the UNIX group that owns the file/directory. Stacie Montoya -----Original Message----- From: Waters, G Scott DSTI [mailto:george.scott.waters@us.army.mil] Sent: Friday, January 24, 2003 8:32 AM To: 'toasters(a)mathworks.com' Subject: disappearing CIFS permissions ... Has anyone had any problems with setting CIFS share permissions and then having them disappear?? We have a series of scripts that run at night that manage our users in our NT4 domain. Our users are created and then for each user a home share is created on our filer. Every once in a while we will get a complaint that one of our new users can not access their home share. I check the share and sure enough the permissions are not there. However, when I check the output from our scripts they show that the permissions were set successfully. The user is created in the script by using the NET USER command and the shares are manipulated by the RMTSHARE program from the NT Resource Kit. After the user is created Domain Admins are granted permissions to the SHARE (and those permissions are always there) then the user is granted permissions (and that is where the problem occasionally occurs). It's an annoyance that I can't explain ... and I don't like those. If anyone has any ideas / suggestions / etc, etc ... please let me know. Thanks. - Scott W.

1 0

RE: disappearing CIFS permissions ...
by Nail, Larry 24 Jan '03

24 Jan '03

Scott, We had the same set of problems when we were running 5.3.7 on the filers... when we upgraded to 6.x, we stopped seeing those problems. The only problem we did resolve was we had a share name "L&I". When we renamed the share to LnI, it stopped dropping it's permissions. Larry -----Original Message----- From: Waters, G Scott DSTI [mailto:george.scott.waters@us.army.mil] Sent: Friday, January 24, 2003 9:32 AM To: 'toasters(a)mathworks.com' Subject: disappearing CIFS permissions ... Has anyone had any problems with setting CIFS share permissions and then having them disappear?? We have a series of scripts that run at night that manage our users in our NT4 domain. Our users are created and then for each user a home share is created on our filer. Every once in a while we will get a complaint that one of our new users can not access their home share. I check the share and sure enough the permissions are not there. However, when I check the output from our scripts they show that the permissions were set successfully. The user is created in the script by using the NET USER command and the shares are manipulated by the RMTSHARE program from the NT Resource Kit. After the user is created Domain Admins are granted permissions to the SHARE (and those permissions are always there) then the user is granted permissions (and that is where the problem occasionally occurs). It's an annoyance that I can't explain ... and I don't like those. If anyone has any ideas / suggestions / etc, etc ... please let me know. Thanks. - Scott W.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters January 2003