CPU Utilization Issue

[savin_shetty1]

As referenced in KB article, 
https://community.flexera.com/t5/FlexNet-Manager-Knowledge-Base/High-CPU-usage-by-the-ndtrack-exe-component-of-the-FNMS-agent/ta-p/2290

I have had my customer reporting CPU utilization issue on legacy (RHEL 5.5 to be specific) Linux machines recently and after having look at tracker.log it seems that inventory collection is taking whopping 4 hours daily. Mostly translating to large directories under server.

But then as per the KB article, Has anyone had success by changing(updating) the flag to LOWPROFILE=FALSE and had substantial relief in CPU utilization issue?

[kclausen]

@savin_shetty1 - By default, the agent runs in Low Profile, with a NICE setting of 10. 

Setting LOWPROFILE to "False", is exactly what you WOULD NOT WANT TO DO, as the agent would then run at a higher priority.  You want the default setting of LOWPROFILE=TRUE.

For these servers, you likely need to investigate which folders are being scanned for File Evidence, since the scan is running for several hours.  It is likely that there are some folders on these Linux Servers that are containing Backup Data with several TB of content.  You can configure the agent to EXCLUDE those folders from the agent file scan.

Here is some information from the GatheringFlexNetInventory.pdf guide:

*************************************************************************

LowProfile (inventory component)
Command line | Registry
LowProfile determines the CPU priority of the tracker (ndtrack executable) on the computer device where it is
executing.
• When set to True, the tracker processes run with low priority. For UNIX-like systems, this sets the nice level of
the process to 10. On recent Windows platforms, it uses background processing mode
(PROCESS_MODE_BACKGROUND_BEGIN). On legacy Windows platforms where this is not supported (such as
Windows XP and earlier), it uses a priority of idle (IDLE_PRIORITY_CLASS).
• When set to False, the same processes run with normal priority.
Values
Values / range Boolean (True or False).
Default value No default in registry; default behavior is True.
Preferences
302

[savin_shetty1]

Firstly thanks for response @kclausen.
Many thanks for these leads.

For unix scanning, We havent had any exclusions specified under 'Inventory File Evidence' section. Not sure if this was not done with a reason.

Also i confirmed from application team that the disks are cumulatively 1600GB(atleast 70% of them being utilized) on these affected servers.

Am further investigating why it was not reported so far if the disks were scanned like this since beginning.

Am also assuming this is because these servers are running legacy 5.5 version of RHEL. Are there any chances for this being notable reason?

[kclausen]

It may simply be that these legacy servers have older hardware and slow disk i/o.

How many of these legacy linux 5.5 servers do you have?

Depending on the number of servers, another option to consider would be to:

1) Uninstall the agent

2) Use the "Core Executable" method of inventory where you basically put the NDTRACK.SH and some related binary files into a local folder and then create a CRON job to run NDTRACK on a scheduled basis (such as during the weekend).  While the scan may still take 4 hours, you are no longer running the scan on a daily basis, and only running the scan during the weekend (off-peak) and there is less of an impact to the server.

[savin_shetty1]

Thank again @kclausen.
It is reporting on just 2 servers for the moment and even if there are more, I dont think they are more than 10-15 of them.

Looks like this can be done, But instead of daily inventory update we will have weekly update.

By any chance is there any documentation that you know of to get this accomplished( am sorry i know am asking extras now, spare me please 🙂 ).

Honestly asking it because, am no Linux specialist and dont want to run in issues.

[petersmith98]

You should buy a new laptop with a stronger CPU