[Info-vax] DNFS1ACP using 100% of CPU

[Stephen Hoffman]

On 2013-10-11 04:31:03 +0000, milton.baar at swoose.com.au said:

> <snip>
> 
> It would appear that I need to increase the working set of the NFSACP.  
> Reading through TCPIP$NFS_CLIENT_STARTUP.COM is is clear that the 
> NFSACP is installed as a driver during TCP/IP startup and examining the 
> running image shows it with a UIC [1,1] and a working set of 16384.  
> Clearly this is inadequate and causing the system to soft-fault itself 
> to a standstill.
> 
> How do I increase the WS to something like 3000?  I have never played 
> with installed drivers in this way before and haven't found anything to 
> guide me....

NFSACP is not a driver, it is an ACP; an ancillary control process.  
Briefly: an ACP is a process that has a working set and related quotas 
and settings.  The process quotes and related are established when the 
ACP is launched.   There's no consistent way to launch an ACP on VMS 
(other than the VMS file system ACPs, which use the MOUNT command), so 
each project establishes its own process creation mechanism.  That 
process creation establishes the quotas explicitly (better programming 
practice), or the quotas are defaulted from the PQL values (rather more 
unreliable programming practice).   More details: 
<http://labs.hoffmanlabs.com/node/213>

It is unusual for an ACP to be very active, and that behavior would 
imply either very heavy driver load — the driver asks the ACP for 
services that are difficult to perform in the context of a device 
driver — as the device driver authors strongly prefer to avoid 
involving the transitions and context switches inherent in involving 
the ACP.  In general, the driver author wants to use the ACP for slow 
stuff and occasional stuff and stuff the driver just can't do for 
itself, but preferably not within the main I/O path of the device 
driver.

It is also very unusual for the NFS ACP to be active — at all — with a 
quiescent NFS connection.

Put another way, you're probably not chasing an ACP quota issue here, 
there's something in the NFS traffic that's exposing a bug in the NFS 
client or ACP.  Go ahead and increase the process quotas, but I'd 
suspect there's a leak or other error lurking, and you'll just (and 
likely only briefly) forestal the manifestation of the latent errors 
here.

But to answer your question, find what I expect will probably be a RUN 
command buried in the TCPIP startup DCL for NFS that starts the ACP (or 
maybe via a sys$creprc call somewhere?  haven't looked), and tweak it 
to increase the quotas.  Or logical names if NFS has those, or via PQL 
parameters if all else fails.  But don't expect the quota changes to 
resolve what looks to be the run-away ACP activity here.  There's very 
likely a bug or an incompatibility lurking here somewhere, either in 
the NFS client driver, in the ACP, or potentially in the Apple NFS 
server.

Um, what do I mean by an "incompatibility" here?  Standards and specs 
can and variously do have some ambiguities and this can lead to 
differing and arguably equally valid interpretations.  So potentially 
not technically a bug.  Well, not unless you count an ACP that faults 
itself silly in certain contexts as a bug.

There have been various recent updates to TCP/IP Services NFS support 
including some updates that themselves introduced some bugs, though I 
don't know if any are related to the behavior reported here.  Your most 
likely approach here might be switching to one of the Process IP stacks 
and the Process NFS client, assuming this isn't the Apple NFS server at 
fault, and assuming you don't have access to the HP OpenVMS patches, 
and that you're an OpenVMS hobbyist.  If this is commercial and you 
have HP support, load the TCP/IP Services patches and then call HP 
support.


-- 
Pure Personal Opinion | HoffmanLabs LLC