topic Re: concerns Queue_manager and UCX$FTPD I/O counts in Operating System - OpenVMS

concerns Queue_manager and UCX$FTPD I/O counts

Navipa — Fri, 02 Jan 2015 01:26:57 GMT

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

Re: concerns Queue_manager and UCX$FTPD I/O counts

Steven Schweda — Fri, 02 Jan 2015 04:57:17 GMT

> [...] 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?

Re: concerns Queue_manager and UCX$FTPD I/O counts

MarkOfAus — Fri, 02 Jan 2015 06:50:35 GMT

  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.

Re: concerns Queue_manager and UCX$FTPD I/O counts

abrsvc — Fri, 02 Jan 2015 14:55:33 GMT

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

Re: concerns Queue_manager and UCX$FTPD I/O counts

Hoff — Fri, 02 Jan 2015 19:43:05 GMT

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.