----- Original Message ----- From: Jay Orr orrjl@stl.nexen.com To: Lee Razo lrazo@netapp.com Cc: toasters@mathworks.com Sent: Friday, February 18, 2000 9:08 AM Subject: Re: NVRAM memory
Yea, I figured as such, but I was looking for a more quantative answer. Our CPU isn't that taxed, so in theory would we not notice any performance hit?
Just having extra CPU won't help. A better indication is how often you see the writes on the systat being done. If you just see them in bunches every 5-10 seconds, you'll be fine. (Is it still every 10 seconds?) If you see them more often than that, the less NVRAM will hurt you.
I mean, regardless of the amount of NVRAM, the info has to be written back - I would just imagine that less ram means more writes. How does this factor into the big picture of "performance of the filer" ?
Suppose I write a 7MB file to your F330. You had 8MB of NVRAM. I start writing. At 4MB you switch half of the NVRAM over and start flushing it to disk. I fill up the rest of your NVRAM and the filer returns back success and my client is ready to go do something else while the filer busily commits everything to disk.
Now, same situation, only you have 4MB. After 2 MB you switch, then I fill up the next 2MB, and now I'm stuck waiting for you to finish your disk activity. You do, and I write the next 2MB, and I have to wait again. Instead of being able to write to you at "memory" speeds (basically as fast as I can go and the network will allow), I am stuck waiting on the disks.
The quantitative impact depends on how big the files are being written and how often they are written. If it's just users writing small files and the infrequent large one, at most they'll notice an extra second or two wait when saving something. If it's a database or news server getting written to every second, the whole thing will be slowed down considerably. Maybe 20-40%?
Bruce