Thus spake Alexei Rodriguez, on Tue, Mar 05, 2002 at 02:25:34PM -0800:
Sorry, I failed to point that out, F760.
Cool. I think the max is 1GB of read cache (RAM). NetApp has been selling them in set configurations, so you might already be at that level.
Yes, sysconfig says:
Memory Size: 1024 MB
Goddamn! You're right, that really passed me by. 76% free now, that should really relieve the CPU a bit :)
Has it made any difference?
Yes, now the cpu usage is nearly 50% most of the time, with peaks at 60% opposed to the 100% that it used to. But this 90% occupation rule really lowers the filer disk space rentability.
Given that this is a mail filer, the deletions and creations of files should balance the load across the raid group and volume. However, your writes still have the single disk bottle neck. My advice is to use 6 disk raid groups if possible for write intensive applications. But that is just me. 14 is still ok.
Ok, but this a decision at volume creation, we couldn't reconfigure the raidsize at this stage without data migration, am I right?
Exactly, I have both, client NFS versions differ slightly. I noticed that also. Should I use only v2 or only v3 ?
I see that the conversation about this has already ensued.
Yes, I raised the question in a separate thread as it seems a pertinent question bv itself.
The main problem with using v3 and directories with lots of files is the readdir+ operations.
You mean the overhead of the returned aditional attributes?
They can kill the filer. Especially given your age in cache of 3 mins. v2 over udp should be adequate for your purposes (same thing for nntp feeds).
I have minra=off, are you talking about this?
No, I meant physical memory in the system. sysconfig should get you that data.
Ok, here it is, filtered:
FILER> sysconfig NetApp Release 6.0.1R2: Fri Feb 9 01:12:44 PST 2001 System ID: 0016809340 (FILER); partner ID: 0016808881 (FILER2) slot 0: System Board Processors: 1 Memory Size: 1024 MB slot 0: Fibre Channel Host Adapter 0a slot 0: SCSI Host Adapter 0b [...] slot 3: Fibre Channel Host Adapter 3 21 Disks: 724.5GB 3 shelves with VEM slot 4: Fibre Channel Host Adapter 4 21 Disks: 724.5GB 3 shelves with VEM slot 7: Gigabit Ethernet Controller II e7 MAC Address: 00:03:47:22:85:5e (auto-1000sx-fd-down) slot 8: Interconnect adapter slot 9: NVRAM Memory Size: 32 MB
Yes, about 40Mbit in peaks. We are considering trunking 2x100Mb or going to Gb.
Doing GigE would probably be preferable, if you have the money. FEC (trunking) still does a 1:1 mapping of a host to a trunk, so your hosts will still be bound to a 100Mbps link.
You mean of a host to a real interface? It bonds hosts to interfaces in a "load-balancing" way, right?
That will increase the performance, although not as much as 1Gb, but good enough.
Linux 2.2.19 only. 2.4.18> possibly soon.
The 2.4 kernel and associated NFS packages are supposed to make a huge difference. I have not tried it myself, but that is something to look at.
My experience with the 2.4 kernel series has not been the best. I'll wait a few more days to get a mrtg "snapshot" of the performance after this last tweaking and possibly next week I'll turn to 2.4.18 (it seem stable now) and try to see the improvements, if any.
alexei
Has it made any difference?
Yes, now the cpu usage is nearly 50% most of the time, with peaks at 60% opposed to the 100% that it used to. But this 90% occupation rule really lowers the filer disk space rentability.
I understand your point and concern. It is one of those situations where you have "good, fast and cheap, pick 2". The 90% is not a hard-fast rule. The nutshell is that as the filesystem fills, there are fewer open spots to write and thus there is potentially more work to do to find a spot and write.
I have not charted the performance hit you take as the filer fills. Might be an interesting graph :)
Ideally you should not be operating at 90% if you can avoid it, on any system. I tend to go with 85% as a comfort level.
Ok, but this a decision at volume creation, we couldn't reconfigure the raidsize at this stage without data migration, am I right?
Correct. And you probably don't want to backup 400GB, destroy the volumes and then restore. That would be a bit much!
To your cost question: you have different knobs to tweak on the filer: raid group sizes, number of spares, disk sizes, etc. They all have some impact on the performace but you need to make the technical and business tradeoffs: do you need more space than you do performance? Do you want to do as much as possible to protect your data vs optimize your disks (smaller vs larger raid groups), etc.
alexei
-
Alexei Rodriguez -
Jose Celestino