One of my inn 1.4unoff4 news reader servers started throttlingitself just today with "Interrupted system call writing article file" (happened twice in the past 24 hours).
That's strange. I have no idea what would be causing that. That's usually the result of a signal coming in (e.g., SIGINT generated by hitting ^C) while waiting for the write to complete, but I don't know why you'd be getting such a signal.
BTW, you say one of your *reader* servers is having this problem while *writing*. You do only have one machine doing the writing, don't you? INN has no mechanisms to syncronize multiple machines writing to the news database.
The spool is on an F230 running 4.0.3, 256MB of read cache and 4MB of write cache. The news server is an Ultra 170, 512MB of RAM, ~250 to 300 readers around peak times. The two are on a FDDI ring.
4MB of NVRAM might not be enough with a machine as fast as an Ultra driving it. Give Tech Support a call and they can work with you to determine if you're exhausting this resource.
Do you know what article is being written, and if so, is it a large one (perhaps to one of the alt.binaries groups)? That would stress NVRAM a bit harder, though at worst that should only lead to a slow response by the filer to the write request.
... but the Ultra is reporting 900 to 1200 packets per second both in and out of its FDDI interface. Half of its time is spent in the kernel, according to top(1).
Lots of kernel time isn't surprising for a netnews server.
The mounts are NFSv3 over UDP. Would dropping back down to NFSv2 help any?
Definitely. One of our customers saw active file renumbering drop from 12-14 hours to under 30 minutes just by switching from v3 to v2. This is because NFSv3 clients seem to use READDIRPLUS whenever they can, instead of READDIR following by GETATTR on each file returned by the READDIR. That's good for 'ls -l' but awful for netnews, since it doesn't need the info GETATTR would return and it's expensive to get that stuff.
I'm trying to determine if this is a network congestion problem, or an OS limitation (on either the Netapp or the Sun).
It sounds like something weird happening on the Sun, possibly exacerbated by slow filer responses due to NVRAM starvation. At the loads you're talking about, netnews doesn't stress a network all that much, so unless there's a *lot* of other stuff happening on your net, I wouldn't be inclined to suspect network congestion unless all other plausible avenues had been explored.
-- Karl Swartz - Technical Marketing Engineer Network Appliance kls@netapp.com (W) kls@chicago.com (H)