toasters

toasters@lists.teaparty.net

13515 discussions

F760 memory spec
by Ronan Mullally 19 Feb '07

19 Feb '07

For sheer geek purposes, I've got an old F760, long out of warranty, in my garage. One of the DIMMs has developed a fault and I'd like to replace it. Does anybody know what the memory spec is? The DIMM is branded Samsung KM48S16030BT-GL. From what I can gather it's 168 pin 256MB SDRAM, but I don't know what speed (PC-100? PC-133?), and given that it's got 9 chips on it, it's ECC. Is the filer fussy about the memory it will accept? Do I have to replace this with identical memory, or will a pair of similar DIMMS do? -Ronan

1 0

DST files
by admin＠berkcom.net 17 Feb '07

17 Feb '07

5 5

Large Oracle database question
by Miller, Michael CTR USTRANSCOM J2 16 Feb '07

16 Feb '07

(This might show up twice) We are getting ready to stand up a 30+TB GIS app and I was wondering if anyone on the list has done something like this on a filer. The guy who will be running this doesn't think a filer would give him the performance required (not specified) and is also concerned that the parity drives will get beat to hard. He has been told by others that the only way to make this work as needed is to use RAID 1+0. This started out being required for all of the data but has been relaxed to just the indexes and current point of interest data. Any thoughts? Mike Miller General Dynamics Information Technology Michael.Miller.ctr(a)ustranscom.mil Michael.Miller(a)gdit.com Phone: 618-229-1185

4 3

BayLISA meeting tonight - Feb 15 7-10pm NetApp HQ Sunnyvale
by Jennifer Davis 16 Feb '07

16 Feb '07

I know this is late notice, but I forgot that there might be people interested on this forum in this talk. If you are interested, make sure to RSVP: http://www.eventbrite.com/event/46941403 We will be recording the meeting, so if you can't make it in person you can always watch the video recording after the fact. The February General meeting will be held at NetApp HQ. Location: Network Appliance HQ Building 1, Founders' Theater 495 E Java Dr Sunnyvale, CA 94089 Time: 7:00-10:00pm Architecting a Resilient Storage System Steve Strange, NetApp Engineering The job of a storage engineer is to find ways to turn a collection of unreliable disks into a resilient system. In this presentation, NetApp engineer Steve Strange shares his perspective on some of the core technologies that help make NetApp systems reliable and easy to manage. In particular, Steve will discuss the NetApp RAID-DP implementation.which carries no significant performance penalty.versus traditional implementations of RAID-6, as well as other alternative approaches to storage problems. Steve Strange has been a member of the NetApp engineering team for nine years and has worked on numerous resiliency projects including the launch of NetApp's first clustered failover product, the rearchitecture of the RAID subsystem, and the development of SyncMirror. Case Study: Decreasing Data Center Power Utilization Devinder Singh, NetApp IT Architect In a recent upgrade of its corporate datacenter, NetApp IT reduced the physical footprint of its storage by 40% and cut power consumption by up to 75% while doubling performance. All told, the project touched 165 different applications (with as many as 8 environments each), 343 servers, and just under 5000 mounts. In this presentation, IT Architect Devinder Singh describes the reasons for the upgrade, the migration methodology, and the results.

2 1

High disk reads but low network out
by Paul Letta 15 Feb '07

15 Feb '07

I have been having some performance issues on my F880 the past couple of days. Specifically, an NDMP backup that normally takes 2 hours to complete was stuck in the mapping phase for 12 hours before I killed it. What I am seeing is a high disk read, but without a corresponding network out. Here is a sysstat: > CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache > in out read write read write age > 62% 1456 6 0 794 16954 46326 0 0 0 4s > 56% 1418 0 0 597 13689 36506 0 0 0 5s > 64% 1737 3 0 867 17637 43572 0 0 0 5s > 53% 1135 18 0 572 14823 42905 1155 0 0 4s > 73% 2067 20 0 1282 37835 69880 6347 0 0 4s > 69% 2031 24 0 1267 38868 67632 0 0 0 4s > 74% 1921 3 0 1027 26644 50881 7778 0 0 5s > 59% 1459 0 0 774 18843 41313 0 0 0 6s > 60% 1212 2 0 665 16391 38766 0 0 0 7s > 54% 1028 19 0 509 11873 33960 0 0 0 7s > 61% 844 302 0 571 13765 39032 0 0 0 7s > 72% 1164 598 0 1870 16750 39968 0 0 0 5s > 71% 948 640 0 8961 9788 29552 0 0 0 5s > 79% 1297 603 0 24157 5831 26034 0 0 0 4s > 87% 2130 465 0 23581 9794 31269 0 0 0 2s I don't know why the disks are reading so much without it going out the network. This is an F880 running OnTap 7.1. It is somewhat full -- about 92% (1.2TB out of 1.3TB). There isn't any stuck ndmp sessions: > ndmpd status ndmpd ON. No ndmpd sessions active. I haven't really looked at what clients may be doing what due to the low network out numbers- but I am going there next. Does anyone have any suggestions on what to look for ? Thanks, Paul

4 4

weird behaviour on the nfs share plus kernel: nsm_mon_unmon: rpc failed, status=-13
by Linux Admin 15 Feb '07

15 Feb '07

I have user complaining that application fails to write to NFS share The output in syslog Feb 14 17:23:33 host1 kernel: nsm_mon_unmon: rpc failed, status=-13 Feb 14 17:23:33 host1 kernel: lockd: cannot monitor netapp1 Feb 14 17:23:33 host1 kernel: lockd: failed to monitor netapp1 rpcinfo -p netapp1 shows The NSM daemon (statd), RPC program 100024,is not running on the server. 100024 1 tcp 4047 status 100024 1 udp 4047 status The directory has sticky bit set on it or even without they get one 0 size file and nothing else. any pointers on troubleshooting please

2 1

RE: High disk reads but low network out
by Glenn Marsh 14 Feb '07

14 Feb '07

The problem may not be due to a full nisk and/or the lack of contiguous space. It may be due to the type of data on the filer and that your filer may not have enough cache memory. We have cache age issues but we have been having increasing problems with large files (larger than 1GB and some well over 10GB) and the creation of directories with large number of entries (directories with thousands of sub-directories and files). Both of these can cause the cache age to get very low. The real problem occured for us when we added a lot of high end Linux boxes with Gigabit Ethernet connections that really pound on our filers. The only fix is to upgrade to a filer with more cache memory. See Bug ID 3986, there is no fix and if you contact NetApp they will suggest the upgrade. Glenn (yet another one) -----Original Message-----

1 0

ELNK WTF? - Fwd: POST NOT ALLOWED - NETAPP
by Blake Golliher 14 Feb '07

14 Feb '07

Sigh, Earthlink. Please make with the stopping. For the love of God, make it stop! -Blake ---------- Forwarded message ---------- From: Netapp List Owner <netapp-owner(a)lists.corp.earthlink.net> Date: Feb 14, 2007 10:38 AM Subject: POST NOT ALLOWED - NETAPP To: netapp-owner(a)lists.corp.earthlink.net, Blake Golliher <thelastman(a)gmail.com> The message attached could not be sent to "NETAPP" mailing list because of the following error message: -> Domain gmail.com is not allowed to post A copy of this message is being sent to the list owner(s). Thank you, Mordomo Did your number of files dramatically increase? Is there a reconstruction going on? A wafl scan, or an upgrade? Ok that last one might be silly, but you never know.. :) Can you capture a perfstat or at least a few 30 second samples of statit? Perfstat is usually too much, but here's a quick shell script I run to quickly grab what I need. #!/bin/sh # if [ -z $1 ]; then echo " " echo "I need a filer target" echo "An example syntax" echo " get-stats.sh filer01.msg.dcn" echo " " exit 0 fi FILER=$1 # while true do DATAFILE="$FILER`date | awk '{print "_data_" $2 $3 }'`" echo "" >> $DATAFILE date >> $DATAFILE echo "------------------------------" >> $DATAFILE rsh $FILER 'priv set -q diag; statit -b' 2>/dev/null echo "Starting statit sample" >> $DATAFILE rsh $FILER 'priv set -q diag; nfsstat -z' 2>/dev/null echo "Zeroing nfsstat" >> $DATAFILE rsh $FILER 'priv set -q diag; nfs_hist -z' 2>/dev/null echo "Zeroing nfs_hist" >> $DATAFILE rsh $FILER 'priv set -q diag; wafl_susp -z' 2>/dev/null echo "Zeroing wafl_susp" >> $DATAFILE rsh $FILER 'sysstat -xs -c 30 1' >> $DATAFILE # And we wait... rsh $FILER 'priv set -q diag; statit -en' >> $DATAFILE 2>/dev/null rsh $FILER 'priv set -q diag; nfsstat -d' >> $DATAFILE rsh $FILER 'priv set -q diag; nfs_hist' >> $DATAFILE rsh $FILER 'priv set -q diag; wafl_susp -w' >> $DATAFILE echo " ** " >> $DATAFILE done if you don't allow rsh, you can enable passphrase ssh and replace rsh with ssh (I think it's built into 7 for free now..) or just run the commands above in sequence and save them to a text. A few samples of each for about 30 seconds should do it, but only during the problem, not helpful if it's not happening at the moment. I usually run the script for about 5 to 10 minutes, then ctrl+c out of it. Right now I look at it a lot by hand. -Blake On 2/14/07, Paul Letta <letta(a)jlab.org> wrote: > I have been having some performance issues on my F880 the past couple of > days. Specifically, an NDMP backup that normally takes 2 hours to > complete was stuck in the mapping phase for 12 hours before I killed it. > > What I am seeing is a high disk read, but without a corresponding > network out. Here is a sysstat: > > > CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache > > in out read write read write age > > 62% 1456 6 0 794 16954 46326 0 0 0 4s > > 56% 1418 0 0 597 13689 36506 0 0 0 5s > > 64% 1737 3 0 867 17637 43572 0 0 0 5s > > 53% 1135 18 0 572 14823 42905 1155 0 0 4s > > 73% 2067 20 0 1282 37835 69880 6347 0 0 4s > > 69% 2031 24 0 1267 38868 67632 0 0 0 4s > > 74% 1921 3 0 1027 26644 50881 7778 0 0 5s > > 59% 1459 0 0 774 18843 41313 0 0 0 6s > > 60% 1212 2 0 665 16391 38766 0 0 0 7s > > 54% 1028 19 0 509 11873 33960 0 0 0 7s > > 61% 844 302 0 571 13765 39032 0 0 0 7s > > 72% 1164 598 0 1870 16750 39968 0 0 0 5s > > 71% 948 640 0 8961 9788 29552 0 0 0 5s > > 79% 1297 603 0 24157 5831 26034 0 0 0 4s > > 87% 2130 465 0 23581 9794 31269 0 0 0 2s > > I don't know why the disks are reading so much without it going out the > network. > > This is an F880 running OnTap 7.1. It is somewhat full -- about 92% > (1.2TB out of 1.3TB). > > There isn't any stuck ndmp sessions: > > ndmpd status > ndmpd ON. > No ndmpd sessions active. > > I haven't really looked at what clients may be doing what due to the low > network out numbers- but I am going there next. > > Does anyone have any suggestions on what to look for ? > > Thanks, > > Paul >

1 0

RE: High disk reads but low network out
by Glenn Dekhayser 14 Feb '07

14 Feb '07

Look at your cache age. It's very low, meaning that you are not serving data out of memory, only directly from disk. As the cache age does down, see that your network out numbers go down as well. When your filer gets full, it isn't able to find contiguous space to write data to (thus write 'anywhere'), so it starts breaking things up and you lose temporal locality, which eliminates the benefits of Netapp's read-ahead caching mechanism, thus low cache ages and poor performance. That's probably what's happening. You should think about a wafl_scan reallocate when the system utiliziation goes down, or getting a bunch of data off the box. Glenn (the other one) ************************************************************************ Glenn Marsh Lattice Semiconductor Corporation Senior Unix Systems Administrator 5555 NE Moore Court CAD Engineering Hillsboro, Oregon 97124 glenn.marsh(a)latticesemi.com 503-268-8000 503-268-8136 phone - 503-268-8459 fax ************************************************************************

1 0

Snap Manager for SQL / SnapMirror issue.
by Rod Newcomb 14 Feb '07

14 Feb '07

Help! We have a SQL Cluster, running Server 2003, Snapdrive 3.2r1 and Snapmanager SQL 1.5 On node one, we have an sql instance that runs that Snapshots/Snapmirrors the SQL data over to our offsite location twice a day. Works like a champ. On node two, we have a new instance running all the same software, the backup runs and complets with no issues, but for some reason it will not snapmirror. From the logs, it looks like it doesn't even try. There are no errors. On the node that works, we get the following in the backuplogs: *** REQUEST SNAPMIRROR UPDATE AFTER BACKUP *** Starting SnapMirror update... Querying disk list for SnapMirror update... Requesting SnapMirror update for LUN [G:] on volume [musql2k_1_database] of filer [URBFiler2]... Request for SnapMirror update for LUN [G:] was completed successfully. Requesting SnapMirror update for LUN [K:] on volume [musql2k_1_logs] of filer [URBFiler2]... Request for SnapMirror update for LUN [K:] was completed successfully. Requesting SnapMirror update for LUN [I:] on volume [musql2k_1_snapinfo] of filer [URBFiler2]... Request for SnapMirror update for LUN [I:] was completed successfully. There is no such text on Node 2, even though it's set to Snapmirror: Full database backup Maximum databases of concurrent backup: 255 Naming convention: Generic Run transaction log backup after full database backup: Yes Keep the oldest 3 full backups. Retain up-to-the-minute restore ability for older backups in other management groups: No Leave database attached after DBCC: No Run DBCC CHECKDB with Live Database Before Backup: No Run DBCC CHECKDB with Live Database After Backup: No Backup Management Group: Standard Update SnapMirror after operation: Yes <---------------- Run Command after operation: No I have reinstalled SMSQL, and I can even manually kick off a snapmirror from the node inside of Snapdrive so I know were talking on the right ports. I have double checked the RSH access, and it all seems to be in order. Both the SQL instance has access as well as the Snapdrive service account. Any suggestions? I've been fighting this for five days. Netapp support is trying to help, but we're getting no where fast. Rod Newcomb

4 3

Jump to page:

2025

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