Solved

High CPU after Collector Upgrade to 33.002

Barb
Rank
Userlevel 4
Badge +2
  • Barb Processor Participant
  • Processor Participant
  • 30 replies

Hi

We have seen a couple of collectors CPU increase by between 20 -30% after this upgrade and just interested if anyone else has seen this behaviour ?

icon

Best answer by Ajay 24 March 2023, 12:58

View original

10 replies

Ajay
Rank
Userlevel 4
Badge +6

Hello Barb,

We have not heard this yet, however if you are concerned, this will need to be investigated and is best resolved going through LM support.

Please contact support by raising a ticket or chat through your portal. Please provide the logs and further details in the ticket.

Support link found top right hand side of your LM portal.

Thanks

Premier Technical Engineer | LM Community Champion
Stuart Weenig
Rank
Userlevel 7
Badge +19

We have the same problem with 33.001 and 33.002. Our high CPU causes the collector to lose its connection to LM making the collector “down”. We just go into the box and restart the service and everything is normal again.

Rebuilding my stuff here: https://github.com/sweenig/lm http://bit.ly/sweenigresume
Paul Jeffries
Rank
Userlevel 3
Badge +2

Just to follow up here, we have become aware that in a small number of cases the scriptcache file on the collector can get corrupted. This can lead to excessive CPU usage.
 
Stop the collector services from the OS of the collector - remove the scriptcache file from its location (as per the below) and restart the collector services. This will rebuild the scriptcache

file=C:\Program Files\LogicMonitor\Agent\tmp\scriptCache

We have built an EA collector (33.301) with a fix for the problem, and it is hoped that this will be built into the General release of the collector shortly.

Stuart Weenig
Rank
Userlevel 7
Badge +19

Is there a way to know if this procedure is actually necessary? Is there a way of detecting that the scriptcache file on the collector is actually corrupted? Does this apply to all versions before 33.301 or just certain versions?

Rebuilding my stuff here: https://github.com/sweenig/lm http://bit.ly/sweenigresume
Paul Jeffries
Rank
Userlevel 3
Badge +2

Hi @Stuart Weenig 

Great questions.  You can usually see in the wrapper log files that the file is corrupted, an example is shown here;
 

We’ve only seen it on 33.001 and there are some details provided in our release notes

https://www.logicmonitor.com/release-notes/ea-collector-33301

Stuart Weenig
Rank
Userlevel 7
Badge +19

Alright, who’s going to build the configsource to check the wrapper log for presence of that string?

Not sure if it’s just me, but the image didn’t come through.

Rebuilding my stuff here: https://github.com/sweenig/lm http://bit.ly/sweenigresume
Paul Jeffries
Rank
Userlevel 3
Badge +2

Not sure a configsource is required at this stage as once the collector is updated to EA 33.301 or GD 33.003 it “self checks’ and if corruption is found the file gets deleted.

 

Stuart Weenig
Rank
Userlevel 7
Badge +19

Yeah, but if we’re not planning on upgrading the collector for a while, having a logicmodule will give us a compelling reason to argue for fast-tracking the collector upgrade.

Besides, the answer to “who” is me. It’s me, I’m going to build it. Unless you can build it faster than me. Ready, set, go!

Taking bets here.

Rebuilding my stuff here: https://github.com/sweenig/lm http://bit.ly/sweenigresume
Barb
Rank
Userlevel 4
Badge +2

Update on progress here - Upgrading to 33.002 or 33.400 has mostly worked except for customers that are 100% in Azure. We have had to upgrade the CPU’s from D8s v3 to B8ms which is double the cost so not a suitable resolution. Is anyone else finding this ? 

Paul Jeffries
Rank
Userlevel 3
Badge +2

@Barb 

Thanks for coming back here and sorry to hear you’re still having some frustrations

May I ask that you raise a support case so we can investigate this for you?

Kind regards

Paul

Reply


Terms & ConditionsCookie settings