Has anybody had any success using a 630 as a back end for inn? We are experiencing some horrible thruput issues with large files. The Inn machine is a multi processor sparc 20s w 512 meg ram running 2.6.
Nettapp is a 630 8meg nvram 256meg system ram 100bt full duplex connection between the sparc and the netapp. System load is around 10% Systat 1 shows writes are flushed at around 10 sec intervels, cache age is sitting between 11 and 20.
To quote my sys admin.
"When INN writes an article, it opens it (O_WRONLY|O_CREAT|O_TRUNC), fills the buffer, then writev's to write out the buffer.
This works great on small files, but large files are making the writev just hang for a second or so (not coincidentally at the same time that the dnewslink process sleeps in diablo).
I tried changing the open to O_WRONLY|O_NONBLOCK|O_CREAT|O_TRUNC, but apparently non-blocking writes don't happen over NFS.
Anyway, the key to solving this is getting the Netapps to write big files faster. Any ideas?"
David Power V-P Operations Insync Internet Services Inc.
Yes, I am, works fabulous once I got enough RAM in that baby.
I find best results with v2/UDP NFS, and disable v3 and TCP mounts completely.
Also, trim your misc.jobs.offered, and control directories regularly, large dirs still kill the Netapp until they get their Btree directory implementation running.
On Wed, 18 Mar 1998, David Power wrote:
Has anybody had any success using a 630 as a back end for inn? We are experiencing some horrible thruput issues with large files. The Inn machine is a multi processor sparc 20s w 512 meg ram running 2.6.
Nettapp is a 630 8meg nvram 256meg system ram 100bt full duplex connection between the sparc and the netapp. System load is around 10% Systat 1 shows writes are flushed at around 10 sec intervels, cache age is sitting between 11 and 20.
To quote my sys admin.
"When INN writes an article, it opens it (O_WRONLY|O_CREAT|O_TRUNC), fills the buffer, then writev's to write out the buffer.
This works great on small files, but large files are making the writev just hang for a second or so (not coincidentally at the same time that the dnewslink process sleeps in diablo).
I tried changing the open to O_WRONLY|O_NONBLOCK|O_CREAT|O_TRUNC, but apparently non-blocking writes don't happen over NFS.
Anyway, the key to solving this is getting the Netapps to write big files faster. Any ideas?"
David Power V-P Operations Insync Internet Services Inc.
On Wed, 18 Mar 1998, David Power wrote:
"When INN writes an article, it opens it (O_WRONLY|O_CREAT|O_TRUNC), fills the buffer, then writev's to write out the buffer.
This works great on small files, but large files are making the writev just hang for a second or so (not coincidentally at the same time that the dnewslink process sleeps in diablo).
Are you running INN or Diablo? You mention both in your message. AFAIK, Diablo is not worth running with an NFS spool just yet, because of its heavy reliance on file locking.
Both the feeder and reader news servers here have their history on local disk and the spool (and overviews on the reader) on Netapps. The feeder is sharing an F220 with 256MB, and the reader has an F230 with 256MB to itself. I don't accept articles larger than 512K though, so I probably don't encounter the same problem you do. Overviews files get into the multi-megabyte range though, and there aren't any problems reading from or writing to them.
The connection in both cases is through a Cisco Cat2900 with full-duplex 100baseT.
-
Brian Tao -
David Power -
Jaye Mathisen