toasters February 2002

toasters@lists.teaparty.net

78 participants
92 discussions

Oracle and snapshots - how are you using it?
by Art Hebert 07 Feb '02

07 Feb '02

We haven't implemented snapshots because we have a single volume and it hasn't been manageable. We now have budget to buy some more disk shelves and want to move our database files to another volume and snap this. In looking at white papers on the Netapp site it leads me to beleive that I need to stop the db and snap and then restart. I would like to just run a snap every 15 minutes without stopping the db, so I can always fall back to a previous snapshot, can or are any of you doing this? thanks Art Hebert Email: art(a)arzoon.com <mailto:art@arzoon.com> Arzoon IT Dept. Phone: 650 995-6125 Mobile: 650 444-8667

1 0

RE: Slow write performance
by Edward Hibbert 06 Feb '02

06 Feb '02

Thanks to all of you who replied. Various people pointed me at statit as the particularly useful tool for spotting what's going on. I have two volume groupings, one with 3 disks, and one with 4. My data is only on one of those volume groups, and statit clearly shows the usage on the relevant disks being very high, up to the point where I'm thrashing the cache on the filer. So I'll split my data across both volume groups, which should give me better throughput. Thanks again, Edward. > Disk statistics (over 31 seconds) > ut% is the utilization % of the disk; > chain is avg number of 4K blocks/op; > usecs is round trip time to disk in microseconds per 4K block. > > disk ut% xfers/s urds/s chain usecs cwrs/s chain usecs crds/s chain > usecs > 8.0 93 171.12 118.70 1.06 5711 26.90 3.45 2213 25.51 1.70 > 2592 > 8.1 90 168.80 114.54 1.04 5843 28.09 3.16 2433 26.16 1.71 > 3163 > 8.2 0 0.38 0.00 0.00 0 0.38 3.16 1605 0.00 0.00 > 0 > 8.3 28 79.06 0.25 1.00 9500 38.35 4.08 1340 40.45 1.73 > 1112 > 8.4 90 170.70 118.45 1.05 5771 27.80 3.11 2359 24.45 1.69 > 3009 > 8.5 0 0.67 0.19 1.00 3833 0.19 3.83 1565 0.29 1.22 > 1545 > 8.6 0 0.61 0.12 1.00 7750 0.35 2.81 1580 0.12 1.75 > 1428

1 0

RE: Slow write performance
by Knight, Jason 06 Feb '02

06 Feb '02

It might also be helpful to know how many disks are in the raid group. 2? 10? Apologies if it was mentioned earlier. How much NVRAM? Jason -----Original Message----- From: Kumar, Rahul [mailto:Rahul.Kumar@sdrc.com] Sent: Wednesday, February 06, 2002 12:48 PM To: Chris Thompson; Mike Ball; Edward Hibbert Cc: toasters(a)mathworks.com Subject: RE: Slow write performance Hi All, I think in this case if he could use sysstat -x 1 he would get a output kinda like this which might help diaganosing further... filer1> sysstat -x 1 CPU NFS CIFS HTTP Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk in out read write read write age hit time ty util 2% 55 12 0 67 19 21 24 0 0 0 >60 99% 0% - 2% 8% 150 9 0 159 31 33 112 1309 0 0 >60 100% 15% T 15% 1% 21 4 0 25 28 30 0 0 0 0 >60 100% 0% - 0% 3% 132 0 0 132 1 1 0 0 0 0 >60 100% 0% - 0% 4% 97 71 0 168 26 30 0 0 0 0 >60 100% 0% - 0% 2% 91 0 0 91 36 21 0 0 0 0 >60 100% 0% - 0% 2% 57 20 0 77 14 17 32 0 0 0 >60 96% 0% - 4% 4% 172 10 0 182 31 33 0 0 0 0 >60 100% 0% - 0% 1% 18 4 0 22 31 33 0 0 0 0 >60 100% 0% - 0% filer1> ----------- Rahul Kumar EDS PLM Solutions - EIT (Pune-India) Rahul.Kumar(a)sdrc.com Work: 91-20-2930812 -----Original Message----- From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] Sent: Wednesday, February 06, 2002 9:26 PM To: Mike Ball; Edward Hibbert Cc: toasters(a)mathworks.com Subject: Re: Slow write performance MBall(a)datalink.com (Mike Ball) writes > > I not sure I would be concerned about the 0's on disk writes you are > seeing. As long as Net KB keeps coming in/out. The Netapp may be > recalculating parity and holding the writes in NVRAM before it flushes to > disk, etc.. He should be worried about there being too *few* 0's! As anyone who has done a "sysstat 1" (or just watched the pretty lights on the discs :-]) knows, ONTAP does disk writes in bursts (CPs). It will do a CP about once every 11 seconds unless NVRAM gets half-full (or some other exceptional condition happens) first. Edward's CP's seem to be taking about 5-6 seconds each: that's definitely not normal. If he could do "sysstat -u" (presumably the reason he can't is that he is still on ONTAP 5.x), then he would see something like 50% in the "CP time" column. The cache age being stuck down at 1 minute all the time doesn't look healthy either. It may be that the disc read traffic is what is making the CPs take so long. That's an effect I have observed during dumps when obviously there is a lot of read traffic, but the CP-expansion is not usually as extreme as in this case. Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.

2 1

RE: vol0 question
by Mike Sphar 06 Feb '02

06 Feb '02

I just want to say for the record that we've had vol0 on our filers be 100% full several times and our filers have never crashed because of it, at least not any time I can recall. Not that vol0 being full is a good thing, of course, but it's always been recoverable in my experience without a crash. -- Mike Sphar - Sr Systems Administrator - Engineering Support Peregrine Systems, Inc. -----Original Message----- From: Jim Harm [mailto:jharm@llnl.gov] Sent: Tuesday, February 05, 2002 1:23 PM To: toasters(a)mathworks.com Subject: Re: vol0 question An argument for isolating root volume is that we are still warned in the netapp admin classes that if the root volume gets full, the filer will crash. We can build qtress to limit client to just under 100% or we can reserve 1% snap and turn off snaps. But will either of those really work? Will the filer potentially crash on a full volume even if it is not root volume? At 6:12 AM -0800 2/5/02, Jeff Kennedy wrote: >I don't disagree but this seems to be a paradigm of the past. With the >R100 out, and OT 6.2 comming soon, the limitations are quickly >disappearing. Currently I plan to just snapmirror volumes to the R100, >but with 6.2 I plan to create volumes in the 1TB+ range and snapmirror >the qtrees (everything we do is in qtrees). I used to be a volume nazi >for probably the same reasons you mention (no volume was to *ever* get >above 400GB's non-snapshot), now I don't see that as a problem anymore. >I have no issues with volumes going past 1TB if this works as >advertised, and I have no reason to think it won't. > >So, do you still think vol0 should be seperate? And don't give me the >"That's the way we've always done it..." routine :-] Keep in mind the >R100 does mostly archival, backup/restore, and misc funtions like db >exports and IT tool storage, not traditional production stuff. > >~JK > >Chris Blackmor wrote: >> >> Jeff, >> I personally don't like active data on vol0. In the past I have >> put archive data on vol0 because it is low impact. I happen to >> be a little more paranoid than some but that is just me and we >> have been bitten before by putting highly volatile on the root volume. >> Chris >> >> On Mon, Feb 04, 2002 at 02:02:14PM -0800, Jeff Kennedy wrote: >> > Now that the R100 has come out I was wondering what people think of the >> > seperate vol0 concept? In the old days it wasn't quite so bad; ok, so >> > you wasted a 4gb drive or maybe even an 18gb drive. But now we're >> > looking at tossing a 136gb drive for what? Squat really. >> > >> > So what's the new thought on this? Do you not waste the disk on a >> > seperate vol0 and just keep tight reigns on qtrees? Or is there still >> > an argument for vol0 on it's own? >> > >> > Thanks. >> > -- >> > ===================== >> > Jeff Kennedy >> > Unix Administrator >> > AMCC >> > jlkennedy(a)amcc.com >> >> -- >> ---------------------------------------------------------------------------- - >> * | When you're throwin' your * >> * Chris Blackmor _______ | weight around, * >> * Advanced Micro Devices \____ | | be ready to have it * >> * Phone: (512) 602-1608 /| | | | thrown around by * >> * Fax: (512) 602-5155 | |___| | | somebody else. * >> * Email: chris.blackmor(a)amd.com |____/ \| | Author Unknown* >> ---------------------------------------------------------------------------- - >> * My comments are mine, and mine alone. * >> ---------------------------------------------------------------------------- - > >-- >===================== >Jeff Kennedy >Unix Administrator >AMCC >jlkennedy(a)amcc.com -- }}}===============>> LLNL James E. Harm (Jim); jharm(a)llnl.gov System Administrator Compaq Clusters (925) 422-4018 Page: 423-7705x57152

4 3

exports questions
by neil lehrer 06 Feb '02

06 Feb '02

ontap 6.1.1r2 nfs, cifs, nis, nt4 domain 1. i run both nfs and cifs and i find it easier to edit the exports file from the cifs side. but sometimes things get odd afterwards. what does the parser not like that gets in when using windows editors? i have looked with a hex editor and haven't seen anything unusual. couldn't find anything in NOW knowledgebase. 2. i set up an exports entry using the fully qualified domain name for a host with root access. after i exportfs -a and then do an exportfs the listing comes back with just the hostname, no domain tagged on. is this normal behavior? thanks. -- regards +++++++++++++++++++++++++++++++++++++++++++++++++ + Neil Lehrer + + United States International Broadcasting Bureau + System Development Division + + voice 202 619-2524 + fax 202 619-3576 + nlehrer(a)ibb.gov + + " is this crisis an opportunity or just + another grab the fire extinguisher moment?" + +++++++++++++++++++++++++++++++++++++++++++++++++

5 4

RE: Slow write performance
by Kumar, Rahul 06 Feb '02

06 Feb '02

Hi All, I think in this case if he could use sysstat -x 1 he would get a output kinda like this which might help diaganosing further... filer1> sysstat -x 1 CPU NFS CIFS HTTP Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk in out read write read write age hit time ty util 2% 55 12 0 67 19 21 24 0 0 0 >60 99% 0% - 2% 8% 150 9 0 159 31 33 112 1309 0 0 >60 100% 15% T 15% 1% 21 4 0 25 28 30 0 0 0 0 >60 100% 0% - 0% 3% 132 0 0 132 1 1 0 0 0 0 >60 100% 0% - 0% 4% 97 71 0 168 26 30 0 0 0 0 >60 100% 0% - 0% 2% 91 0 0 91 36 21 0 0 0 0 >60 100% 0% - 0% 2% 57 20 0 77 14 17 32 0 0 0 >60 96% 0% - 4% 4% 172 10 0 182 31 33 0 0 0 0 >60 100% 0% - 0% 1% 18 4 0 22 31 33 0 0 0 0 >60 100% 0% - 0% filer1> ----------- Rahul Kumar EDS PLM Solutions - EIT (Pune-India) Rahul.Kumar(a)sdrc.com Work: 91-20-2930812 -----Original Message----- From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] Sent: Wednesday, February 06, 2002 9:26 PM To: Mike Ball; Edward Hibbert Cc: toasters(a)mathworks.com Subject: Re: Slow write performance MBall(a)datalink.com (Mike Ball) writes > > I not sure I would be concerned about the 0's on disk writes you are > seeing. As long as Net KB keeps coming in/out. The Netapp may be > recalculating parity and holding the writes in NVRAM before it flushes to > disk, etc.. He should be worried about there being too *few* 0's! As anyone who has done a "sysstat 1" (or just watched the pretty lights on the discs :-]) knows, ONTAP does disk writes in bursts (CPs). It will do a CP about once every 11 seconds unless NVRAM gets half-full (or some other exceptional condition happens) first. Edward's CP's seem to be taking about 5-6 seconds each: that's definitely not normal. If he could do "sysstat -u" (presumably the reason he can't is that he is still on ONTAP 5.x), then he would see something like 50% in the "CP time" column. The cache age being stuck down at 1 minute all the time doesn't look healthy either. It may be that the disc read traffic is what is making the CPs take so long. That's an effect I have observed during dumps when obviously there is a lot of read traffic, but the CP-expansion is not usually as extreme as in this case. Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.

1 0

RE: Slow write performance
by Mike Ball 06 Feb '02

06 Feb '02

Edward, I not sure I would be concerned about the 0's on disk writes you are seeing. As long as Net KB keeps coming in/out. The Netapp may be recalculating parity and holding the writes in NVRAM before it flushes to disk, etc.. As for the volume being full, I see a lot of customers only add 1 disk at a time when the volumes get full. This causes a problem because you basically do not stripe across disks. You only are writing to one disk. At this point you become disk bound which could very well be what is happening here. Make sure you add disks a few at a time when you grow your volume to stripe the data among drives. Mike -----Original Message----- From: Edward Hibbert [mailto:EH@dataconnection.com] Sent: Wednesday, February 06, 2002 8:29 AM To: 'Mike Ball' Subject: RE: Slow write performance Mike, I can send you a couple of the outputs straight away. sysstat doesn't recognise the -u option; what's the difference between that and sysstat 1? I take your point about network settings - we've had problems in this area before - but I don't understand why I would get 0 disk writes for a long time while still getting network traffic in and out. I know that my network traffic during such a period includes write requests (from pktt trace), so what I'm wondering is what causes the writes to hang up and then recover. The disk on /vol/vol0 has previously got very full. Although we've now freed up some space, do you think there might be persistant fragmentation? Edward. nacolt1*> df Filesystem kbytes used avail capacity Mounted on /vol/vol0/ 95328924 54170444 41158480 57% /vol/vol0/ /vol/vol0/.snapshot 0 0 0 ---% /vol/vol0/.snapshot /vol/vol1/ 63552616 60599768 2952848 95% /vol/vol1/ /vol/vol1/.snapshot 0 0 0 ---% /vol/vol1/.snapshot Volume vol0 (root) RAID group 0 RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) --------- ----- ------------ ---- -------------- -------------- parity 8.3 8 0 3 FC:A 34500/70656000 35003/71687368 data 8.4 8 0 4 FC:A 34500/70656000 35003/71687368 data 8.1 8 0 1 FC:A 34500/70656000 35003/71687368 data 8.0 8 0 0 FC:A 34500/70656000 35003/71687368 Volume vol1 RAID group 0 RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) --------- ----- ------------ ---- -------------- -------------- parity 8.2 8 0 2 FC:A 34500/70656000 35003/71687368 data 8.6 8 0 6 FC:A 34500/70656000 35003/71687368 data 8.5 8 0 5 FC:A 34500/70656000 35003/71687368 nacolt1*> -----Original Message----- From: Mike Ball [mailto:MBall@DATALINK.com] Sent: Wednesday, February 06, 2002 1:07 PM To: Edward Hibbert Subject: RE: Slow write performance Edward, Trying forcing the switch you plug into to 100Mb Full duplex. In addition, instead of making e0 auto negotiate, force it to 100Mb full duplex. Your network KB/s is pretty low. Also, how full is your file system? Can you send me the output of the following commands: df sysstat -u 1 (run for 20 seconds) sysconfig -r Thank you, Mike -----Original Message----- From: Edward Hibbert [mailto:EH@dataconnection.com] Sent: Tuesday, February 05, 2002 5:27 PM To: 'Mike Ball' Subject: RE: Slow write performance Here's the sysstat. Interesting that this shows periodic 0 writes. Tue Feb 5 22:22:30 GMT [tn_login_0]: root logged in from host: 192.168.21.16 sysstat 1 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 54% 1012 0 1 393 1494 2430 2446 0 0 1 43% 1012 0 0 431 1549 2302 3947 0 0 1 46% 1278 0 0 471 1787 2708 1116 0 0 1 57% 1080 0 0 611 2019 2078 5177 0 0 1 31% 726 0 0 439 1056 840 1028 0 0 1 37% 962 0 0 388 1872 1561 0 0 0 1 32% 919 0 0 404 1786 1688 0 0 0 1 33% 1050 0 0 407 1815 1529 0 0 0 1 43% 1102 0 0 623 2148 1264 0 0 0 1 43% 857 0 1 347 1585 2154 0 0 0 1 38% 746 0 0 430 1878 1704 0 0 0 1 58% 463 0 1 255 800 2610 3675 0 0 1 52% 997 0 0 517 1544 2840 2084 0 0 1 48% 792 0 0 401 1350 2222 5365 0 0 1 50% 1028 0 0 429 2055 2264 2108 0 0 1 37% 864 0 0 304 1864 1893 2210 0 0 1 39% 1053 0 0 566 2154 988 8 0 0 1 45% 1143 0 0 604 2309 1733 0 0 0 1 35% 1034 0 0 420 2123 1860 0 0 0 1 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 42% 1000 0 0 550 2016 1264 0 0 0 1 52% 1118 0 1 575 2541 1589 0 0 0 1 30% 791 0 0 327 1648 1880 0 0 0 1 48% 880 0 0 382 1896 2022 1905 0 0 1 47% 745 0 1 354 1354 2196 2828 0 0 1 57% 1287 0 0 581 1772 2366 3583 0 0 1 51% 1136 0 0 595 1929 2488 1168 0 0 1 48% 987 0 0 419 1273 2348 3504 0 0 1 35% 768 0 0 421 1623 1597 720 0 0 1 45% 1237 0 0 624 2465 1869 0 0 0 1 38% 1112 0 0 390 1995 1688 0 0 0 1 44% 1044 0 0 585 1817 1697 0 0 0 1 ifconfig output: e0: flags=240043<UP,BROADCAST,RUNNING,UP_1ARY,LINK_UP> mtu 1500 inet 192.168.21.81 netmask 0xffffff00 broadcast 192.168.21.255 ether 00:a0:98:00:97:67 (auto-100tx-fd-up) lo: flags=240049<UP,LOOPBACK,RUNNING,UP_1ARY,LINK_UP> mtu 1536 inet 127.0.0.1 netmask 0xff000000 broadcast 127.0.0.1 Regards, Edward. -----Original Message----- From: Mike Ball [mailto:MBall@DATALINK.com] Sent: 05 February 2002 19:58 To: Edward Hibbert; toasters Subject: RE: Slow write performance Edward, Telnet to the netapp and type "sysstat 1". Let it run for about 20 seconds and send us the output. Also, type "ifconfig -a" and send us the output. Mike -----Original Message----- From: Edward Hibbert [mailto:EH@dataconnection.com] Sent: Tuesday, February 05, 2002 2:24 PM To: toasters Subject: Slow write performance We're seeing some performance problems on an F720 which you guys might be able to help with (even though it's not exactly top of the range nowadays). What we see is: - We're driving it over NFS v3. - We get about 1500 ops/sec out of it, of which one third are writes and two thirds are reads. There aren't many file open/close operations. - The operations are to random locations in large (10GB) files. - The CPU is running about 75%, and the network input and output below the throughput of the link we have to it. We've seen both CPU and network go higher if we do simple copy tests. - Looking it it via pktt trace, something approaching 15% of WRITE operations take long enough for the clients to time out and retransmit (so at least 1 second). None of the READ operations do. - The retransmissions appear to come in bunches. For example we'll see a few seconds where the filer doesn't respond, during which time the retransmissions will come in, then it will wake up and send some responses back. - The rest of the time, the WRITES are very fast (sub-ms). This appears to have worsened recently. We tried a couple of things: - We thought that this might be because the disk had got full and fragmented, so we zapped a bunch of data. - We rebooted. Neither of these seemed to help much. sysstat consistently shows a cache age of 1. This, and the bursty nature of the delays, suggest to me that I'm just hitting it too hard, and there's some kind of periodic cache-flushing operation going on, but do any of you folk have any other suggestions? Edward Hibbert Internet Applications Group Data Connection Ltd Tel: +44 131 662 1212 Fax: +44 131 662 1345 Email: eh(a)dataconnection.com Web: http://www.dataconnection.com

3 2

RE: what disks can i use in an F330?
by Knight, Jason 06 Feb '02

06 Feb '02

Brian, To address your last concern I believe the OS for the F330 goes up to DOT version 5.3.7R3. That is the version we run on our F330. If anyone knows of a later version please let me know. Jason Jason Knight Citadel Investment Group L.L.C. -----Original Message----- From: Brian Hechinger [mailto:wonko@arkham.ws] Sent: Wednesday, February 06, 2002 3:59 AM To: toasters(a)mathworks.com Subject: what disks can i use in an F330? i've got an F330 that i'd like to get online one of these days, and i'd like to get the most storage onto it that i possibly can. it's got 5 narrow SCSI channels on it, and i have a whole slew of DEC BA350 StorageWorks shelves to hook up to it. what is the largest size drives i can put on this thing? is there a particular model of drive that i am limited to? also, what are my options for a wide scsi controller or two in this thing? several of the BA350 shelves have 16-bit personality cards in them, and i'd love to be able to take advantage of that rather than downgrade them to 8-bit personality cards. i think that's all the questions i have for now. next step after getting disks on it, find a copy of the OS for it. -brian

1 0

RE: Slow write performance
by Edward Hibbert 05 Feb '02

05 Feb '02

Here's the sysstat. Interesting that this shows periodic 0 writes. Tue Feb 5 22:22:30 GMT [tn_login_0]: root logged in from host: 192.168.21.16 sysstat 1 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 54% 1012 0 1 393 1494 2430 2446 0 0 1 43% 1012 0 0 431 1549 2302 3947 0 0 1 46% 1278 0 0 471 1787 2708 1116 0 0 1 57% 1080 0 0 611 2019 2078 5177 0 0 1 31% 726 0 0 439 1056 840 1028 0 0 1 37% 962 0 0 388 1872 1561 0 0 0 1 32% 919 0 0 404 1786 1688 0 0 0 1 33% 1050 0 0 407 1815 1529 0 0 0 1 43% 1102 0 0 623 2148 1264 0 0 0 1 43% 857 0 1 347 1585 2154 0 0 0 1 38% 746 0 0 430 1878 1704 0 0 0 1 58% 463 0 1 255 800 2610 3675 0 0 1 52% 997 0 0 517 1544 2840 2084 0 0 1 48% 792 0 0 401 1350 2222 5365 0 0 1 50% 1028 0 0 429 2055 2264 2108 0 0 1 37% 864 0 0 304 1864 1893 2210 0 0 1 39% 1053 0 0 566 2154 988 8 0 0 1 45% 1143 0 0 604 2309 1733 0 0 0 1 35% 1034 0 0 420 2123 1860 0 0 0 1 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 42% 1000 0 0 550 2016 1264 0 0 0 1 52% 1118 0 1 575 2541 1589 0 0 0 1 30% 791 0 0 327 1648 1880 0 0 0 1 48% 880 0 0 382 1896 2022 1905 0 0 1 47% 745 0 1 354 1354 2196 2828 0 0 1 57% 1287 0 0 581 1772 2366 3583 0 0 1 51% 1136 0 0 595 1929 2488 1168 0 0 1 48% 987 0 0 419 1273 2348 3504 0 0 1 35% 768 0 0 421 1623 1597 720 0 0 1 45% 1237 0 0 624 2465 1869 0 0 0 1 38% 1112 0 0 390 1995 1688 0 0 0 1 44% 1044 0 0 585 1817 1697 0 0 0 1 ifconfig output: e0: flags=240043<UP,BROADCAST,RUNNING,UP_1ARY,LINK_UP> mtu 1500 inet 192.168.21.81 netmask 0xffffff00 broadcast 192.168.21.255 ether 00:a0:98:00:97:67 (auto-100tx-fd-up) lo: flags=240049<UP,LOOPBACK,RUNNING,UP_1ARY,LINK_UP> mtu 1536 inet 127.0.0.1 netmask 0xff000000 broadcast 127.0.0.1 Regards, Edward. -----Original Message----- From: Mike Ball [mailto:MBall@DATALINK.com] Sent: 05 February 2002 19:58 To: Edward Hibbert; toasters Subject: RE: Slow write performance Edward, Telnet to the netapp and type "sysstat 1". Let it run for about 20 seconds and send us the output. Also, type "ifconfig -a" and send us the output. Mike -----Original Message----- From: Edward Hibbert [mailto:EH@dataconnection.com] Sent: Tuesday, February 05, 2002 2:24 PM To: toasters Subject: Slow write performance We're seeing some performance problems on an F720 which you guys might be able to help with (even though it's not exactly top of the range nowadays). What we see is: - We're driving it over NFS v3. - We get about 1500 ops/sec out of it, of which one third are writes and two thirds are reads. There aren't many file open/close operations. - The operations are to random locations in large (10GB) files. - The CPU is running about 75%, and the network input and output below the throughput of the link we have to it. We've seen both CPU and network go higher if we do simple copy tests. - Looking it it via pktt trace, something approaching 15% of WRITE operations take long enough for the clients to time out and retransmit (so at least 1 second). None of the READ operations do. - The retransmissions appear to come in bunches. For example we'll see a few seconds where the filer doesn't respond, during which time the retransmissions will come in, then it will wake up and send some responses back. - The rest of the time, the WRITES are very fast (sub-ms). This appears to have worsened recently. We tried a couple of things: - We thought that this might be because the disk had got full and fragmented, so we zapped a bunch of data. - We rebooted. Neither of these seemed to help much. sysstat consistently shows a cache age of 1. This, and the bursty nature of the delays, suggest to me that I'm just hitting it too hard, and there's some kind of periodic cache-flushing operation going on, but do any of you folk have any other suggestions? Edward Hibbert Internet Applications Group Data Connection Ltd Tel: +44 131 662 1212 Fax: +44 131 662 1345 Email: eh(a)dataconnection.com Web: http://www.dataconnection.com

1 0

vol0 question
by Jeff Kennedy 05 Feb '02

05 Feb '02

Now that the R100 has come out I was wondering what people think of the seperate vol0 concept? In the old days it wasn't quite so bad; ok, so you wasted a 4gb drive or maybe even an 18gb drive. But now we're looking at tossing a 136gb drive for what? Squat really. So what's the new thought on this? Do you not waste the disk on a seperate vol0 and just keep tight reigns on qtrees? Or is there still an argument for vol0 on it's own? Thanks. -- ===================== Jeff Kennedy Unix Administrator AMCC jlkennedy(a)amcc.com

4 6

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 February 2002