Increase MIPS usage

[heitkam...@gmail.com]

We are running a 4390 metered with MCP 17. A number of users and developers have mapped a drive to the mainframe. Over the past 6 month we have noticed an increase in MIPS usage. From an average of 40 to 82 last month. I have noticed that *SYSTEM/NXSERVICES/FILESERVER tasks are running about .90 CPU RATE and never go away as the users PC are rarely powered off. Does anyone have any thoughts on why after years of use the MIPS rate have increase?

I have opened a contact with Unisys and sent them sumlogs, WLM stats database and they have not yet provided any answers.

Thanks

Brian

[Paul Kimpel]

So what happened starting six months ago? Three questions:

1. Did you install an update to the MCP software?

2. What NXSERVICES ports are enabled, SMB (139), CIFS (445)?

3. What changes have taken place on the client systems, e.g., upgrade to
Windows 10?

--
Paul

[heitkam...@gmail.com]

We have not upgraded any MCP software.
I do not know how to determine which ports are enabled
We have upgraded client machines to windows 10.

Typically users drag data files from the mainframe to their local machines for processing using windows explorer.

Since posting this we have determined that some windows 10 machines act different then others. We have been using AA SORT CPURATE to look at current utilization. Some nxservices entries are between 1 and .80 cpu rate but others drop down to 0.0. The ones from 1 to .8 are not moving an files, the users don't have a windows explorer session open.

[Paul Kimpel]

-------- Original Message --------
Subject: Re: Increase MIPS usage
From: heitkam...@gmail.com
To:

You can determine which NXSERVICES ports are enabled by running the
Administration Center GUI. Usually SMB (139) is enabled by default and
CIFS (445) isn't. I recommend that CIFS be enabled.

I was wondering if Windows 10 might be continuously hitting the MCP to
update Windows Explorer windows, but apparently that's not the case.

What is the possibility that some client systems have anti-malware
packages that are configured to scan network drives in addition to local
drives? That would certainly generate a lot of NXSERVICES activity.
--
Paul

[heitkam...@gmail.com]

Thanks for responding so quickly

I went into administration center, server properties, advanced. ACCEPTPORT445 is not checked. REJECTPORT139 is not checked.

We did take one of the offending workstations, disabled all the antivirus and mapped a drive. These was no change in it behavior. Still consumed a high rate of processor.

Regarding your comment on continuously hitting the MCP. One of the workstation's MCP usercode became suspended. Following the suspension, we received a security violation every 5 seconds from that workstation trying to connect to MCP. We got the violations until we un-suspended the usercode.

Our workaround now is to have the users disconnect their mapped drives when they were done using them.

[heitkam...@gmail.com]

a followup. Our tech thinks it may have to do with the SMBv1 which they had to install on the workstations to allow them to map to the MCP.

Thanks again

[Paul Kimpel]

On 8/7/2018 10:28 AM, heitkam...@gmail.com wrote:
> a followup. Our tech thinks it may have to do with the SMBv1 which they had to install on the workstations to allow them to map to the MCP.
>
> Thanks again
>

Right, this is why I recommend that you enable ACCEPTPORT445 in
Administration Center. Windows systems since Win2000 are by default
configured to try port 445 first, which usually takes many seconds
before falling back to port 139.

You might experiment to see whether disabling SMBv1 on the clients has
any effect, and then see what happens when you enable REJECTPORT139 in
Administration Center.
--
Paul

[heitkam...@gmail.com]

I have checked ACCEPTPORT445 and REJECTPORT139. There is no change in the behavior of nxservices. They stay in the mix with high processor usage.

We can't disable SMBv1 as that is the version supported by our level of MCP.

[todd.f...@gmail.com]

Brian,

We had a similar issue, noticing the NXServices was hogging up the CPU for long amounts of time. We finally figured out that a PC that runs Automate software had a directory monitor setup to watch a mapped mainframe drive. It was connecting every 15 seconds monitoring for a new file which was not really ever letting the nxservices task go back to 0.0 and really caused it to grab CPU. Once we changed it to monitor that mapped drive every 4 hours instead of 15 seconds, it was like night and day. Literally everyone commented on how much faster the system seem to be running. Only took us 6 months to figure it out!

thanks,
Todd

[heitkam...@gmail.com]

An update,

First thanks to all who read and offered suggestions.

It is related to the number of times our windows 10 pc's update their mapped drives.

Unisys's suggestion is to disconnect mapped drives when not in use.

We have instructed our uses to disconnect their mapped drives when not in use and our mips usage has returned to "normal" levels.

We are looking at an ftp application to distribute output and eliminating the use of mapped drives.

Thanks again

Brian