- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- concerns Queue_manager and UCX$FTPD I/O counts
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-01-2015 05:26 PM
01-01-2015 05:26 PM
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-01-2015 08:57 PM
01-01-2015 08:57 PM
Re: concerns Queue_manager and UCX$FTPD I/O counts
> [...] 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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-01-2015 10:50 PM
01-01-2015 10:50 PM
SolutionPid 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2015 06:55 AM
01-02-2015 06:55 AM
Re: concerns Queue_manager and UCX$FTPD I/O counts
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2015 11:43 AM
01-02-2015 11:43 AM
Re: concerns Queue_manager and UCX$FTPD I/O counts
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.