concerns Queue_manager and UCX$FTPD I/O counts

[Navipa]

Hi all,

I have pasted the SHOW SYSTEM output of my VAX 4000-50.

OpenVMS 6.1 server. DEC TCP/IP Services for OpenVMS VAX Version V3.2 

I see many people uses this vax sever for many print queus and many nfs mounts. I like to know why queue_manager, security_sever, UCX$FTPD processes I/O, othercounts are too much. Is it OK?, if not how to monitor those activities, and when those counts will be reset (automatically OR manually)?

00000203    SWAPPER HIB 16 0 0 00:03:34.34 0 0
00000201    CONFIGURE HIB 9 36 0 00:00:00.06 121 183
00000205   IPCACP HIB 10 7 0 00:00:00.03 95 154
00000108   ERRFMT HIB 8 2630 0 00:00:05.35 142 234
00000109   OPCOM HIB 9 797 0 00:00:00.92 328 176
0000030A   AUDIT_SERVER HIB 10 120 0 00:00:00.25 524 820
0000031B   JOB_CONTROL HIB 8 82990 0 00:04:56.93 268 398

0000010C   QUEUE_MANAGER   HIB    9     1998392     0    01:17:05.66    1049    1286

0000020D   SECURITY_SERVER  HIB   10    7885    0    00:00:58.85     1980    1664

0000021E   TP_SERVER    HIB    10     18968    0     00:00:05.30     201   308

00000223   NETACP HIB 10 3491 0 00:00:00.33 180 405
00000204   EVL HIB 6 39 0 00:00:00.10 293 402 N
00000208   REMACP HIB 8 8 0 00:00:00.00 81 51

0000020A   UCX$LPD_QUEUE HIB 4 47 0 00:00:00.19 534 475 

0000011F   UCX$INET_ACP HIB 10 159 0 00:00:00.25 351 388 

00000021   UCX$INET_ROUTED LEF 6 30 0 00:00:00.08 280 458 S

00000226   UCX$FTPD   LEF  9    247946   0   00:02:47.49    1452    975 N

Thanks

Navipa

[Steven Schweda]

> [...] I like to know why queue_manager, security_sever, UCX$FTPD

> processes I/O, othercounts are too much.

   Define "too much".

   A process which runs from start-up to shut-down may eventually show

large numbers for CPU time, I/O, and so on.  What's your uptime?

> Is it OK?

   What, exactly, do you think is wrong?  (And why?)

> [...] when those counts will be reset (automatically OR manually)?

   Normally, when you reboot the system?  Why do you care?

[MarkOfAus · Accepted solution]

  Pid    Process Name    State  Pri      I/O       CPU       Page flts  Pages
2CE00401 SWAPPER         HIB     16        0   0 00:00:15.01         0      0
2CE00407 CLUSTER_SERVER  HIB     14    34184   0 00:01:01.33        93    108
2CE00408 SHADOW_SERVER   HIB      6  9787472   0 00:02:09.07        62     96
2CE00409 CONFIGURE       HIB     10       17   0 00:00:00.06        43     27
2CE0040A LANACP          HIB     12       93   0 00:00:00.11       112    138
2CE0040C FASTPATH_SERVER HIB     10        9   0 00:00:00.04        76     92
2CE0040D IPCACP          HIB     10       10   0 00:00:00.09        35     47
2CE0040E ERRFMT          HIB      8   398073   0 00:00:46.23       105    126
2CE0040F CACHE_SERVER    HIB     16       45   0 00:00:00.18        29     40
2CE00410 OPCOM           HIB      8   137951   0 00:00:11.33     13547     54
2CE00411 AUDIT_SERVER    HIB      9126460569   0 01:41:12.94       167    200
2CE00412 JOB_CONTROL     HIB      8   386796   0 00:00:47.01       173    205

Hey, we have an audit_server process with IO count exceeding the available column width. Is this a problem? Formatting wise, sure. Is it impacting the system? No, it's been running for 142 days, so that's to be expected.

The point I am trying to make, as Steven has also pointed out, is a high count does not necessarily mean anything other than it's a high count.

If, on the other hand you have a known process that has a high count of say IO when it shouldn't then you MAY have a problem.

Details of this problem process and its trail of destruction need to be forthcoming from yourself otherwise, your system is probably functioning ok.

[abrsvc]

I will echo the previous post.  High numbers in and of themselves are not necessarily a problem.  I have machines with very long uptimes that have many processes with high I/O counts.  This is normal expected behavior.  You have to know your environment to determine whether or not these counts are indicators of problems. 

For the processes listed, I don't see a problem.  But, I also don't know your environment.

More information is needed about your site before anyone can comment specifically.

Dan

[Hoff]

You're using completely insecure, decades-old software, and you're focusing on the I/O counts?     Um, OK.

OpenVMS VAX V6.1 is over twenty years old, TCP/IP Services has seen a very large number of stability and security updates and new features since V3.2, and the VAX hardware and storage here is probably at least that old.

OK.  Technically and arguably, any I/O via FTP is too much, as it exposes the users' server login credentials in cleartext to anyone on the network.  That means there's effectively no security here, and no individual accountability.

I'd suggest working toward replacing this configuration with  newer hardware and particularly with newer OpenVMS software. 

While you're working toward replacement, use MONITOR to record system performance information or acquire and install other tools to record system performance, and to determine the performance trends and usage spikes and related patterns.   This data collection will give you a baseline to determine whether what you're seeing is a problem, or not.

A single snapshot of I/O activity unfortunately provides basically no usable information.  If all that I/O activity happened in, say, ten minutes and activities during those ten minutes were business-critical and your system was grinding under the load, then you probably need performance work and more likely an upgrade.   If that I/O activity has happened piecemeal over a year or two of uptime, then your system is probably pretty quiet on average.

If you want to know about performance, the Performance Management manual in the OpenVMS documentation set will provide a high-level overview — OpenVMS VAX V6.1 is older than the oldest versions supported by various tools, unfortunately.