Localize the process that generate huge traffic in OpenVMS

[geir_2]

Hi,

I have a server on a remote site that produce huge amount of traffic/packets. My problems is to find or localize the program/process.

On the cisco router the load is 250/255, and I know that it must come from a OpenVMS server.

I hope that someone have some tips to localize
the process/program.

[Wim Van den Wyngaert · Accepted solution]

Simple : find processes doing lots of buffered IO's (mon proc/topb).

More difficult : ucx show dev/fu shows the traffic already done by a link. Monitor this (e.g. in dcl script). When found, show dev bgxxxx/fu will return the process id.

Even more difficult : decnet. Do mc ncl show nsp port * all and monitor PDU sent/received.
When found, do mc ncl show ses con port xxx all (xxx is alue of client of previous output). Then you get the pid in the output.

In ana/sys you can do show lan/count to get all counters of all protocols. It could be AMDS or may be the cluster protocol.

Wim

[geir_2]

hi,
Thnaks for te answrer. Whe I executed the first command:

$ monitor process/topb

I found two process. The values is: 67 & 68.
Is it a high or no accectable value??

When I try to execute the next command, The bugger is to low, to see all output. I tried to write the output to a file, but the output was not readable.

The last command is not possible to execute. maybe the OS, is to old.

Regards geir

[Wim Van den Wyngaert]

To saturate a 10 Mbit line I saw about 40 buffered IO's when doing ftp. So the 89 could be it.

The last command is :
$ ana/sys
SDA> show lan/count
then type a few times return until no more output
SDA> exit

[Bart Zorn_1]

$ MONITOR PROCESS/TOPBIO will show you which processes generate the most buffered IO's. That does not tell you anything about whether those figures are low or high, on an absolute scale. But it does tell you which processes generate the most traffic and that is probably what you want.

In my opinion the suggestions from Wim van den Wyngaert do not help much. Geir does not indicate what type of traffic is in effect here.

MCR NCL SHOW NSP ... can only display information about DECnet phase IV traffic.

MCR NCL SHOW OSI TRANSPORT ... could display traffic using DECnet over TCP/IP.

ANAL/SYS, followed by SHOW LAN/COUNT gives you a lot of information, but not which process is generating (or receiving) what traffic.

Finally, MCR NCL SHOW CSMA-CD STATION * COUNT
or MCR LANCP SHOW DEV/COUNT also give total counts, not broken down per process.

TCPTRACE or TCPDUMP could be helpful also. Both have HELP files.

Regards,

Bart Zorn

[geir_2]

Hi Bart,

Thanks for the e-mail. Since I'm running OpenVMS 6.2, the mcr ncl command is not available. Do you know about simular commandsfor my system.

Geir

[Wim Van den Wyngaert]

Bart,

Most performance problems come from IP and decnet (sorry I forgot OSI, most places don't use it, I don't have ncp so that is missing too).

I personally use ncl show csm stat * all
(in an automated way) to find nodes doing high thruput. I give an alarm when such an event is found.
I also reported processes with high buffered IO.

With these 2 informations I always found (using the commands I gave) which process was guilty.

BTW : how can Geir now which traffic if he doesn't know which protocol is causing it.

Geir : also try to find which exe's are active. Ana/sys show sum/ima might help. Especially search for copy or ftp.

Wim

[Wim Van den Wyngaert]

Geir,

6.2 has ncl too but I guess they are using ncp at your site.
Try mc ncp and use "help show known".

Good luck

Wim

[Robert Gezelter]

geir,

Whether the traffic is appropriate or not is virtually impossible to understand without examining the application in detail.

Verfifying which process the traffic is associated with is far easier.

On 6.2, the DECnet NCP command does not appear to have a way to show traffic on a particular link. However, you can look at the NETxxx devices and see the count of operations completed. If you are looking for one or two particularly large users, it should stand out rather sharply.

Once you have verified what who is generating the traffic, it is a matter of either using (or creating) internal debugging tools or using a LAN monitoring tool to capture and analyze the message traffic on the link.

- Bob Gezelter, http://www.rlgsc.com

[Wim Van den Wyngaert]

Also note that performance advisor has a "decnet I/O rate" that you can show. If traffic was coming from decnet, you could find the node this way.
If you don't have pa, monitor decnet is your friend. Same info.

Wim