High CPU Utilization on Inventory Central Server 16 Release 6

Follow

Anthony Weiss

• February 08, 2019 13:40

Anyone else experiencing high CPU utilization on most recent inventory release? My CPU is pegged at 100 on my central server. Looking at Windows event logs, I keep seeing a repeat of a warning, 60020. Same thread listed in each one. Wondering if I have a stuck scan or job of some sort.

Current database operations (time in seconds)

Assembly: C:\Program Files (x86)\Admin Arsenal\PDQ Inventory\PDQInventoryService.exe

Version: 16.6.0.0

Process: 13784 PDQInventoryService

AppDomain: PDQInventoryService.exe

Database: C:\ProgramData\Admin Arsenal\PDQ Inventory\Database.db

Thread: 212 Method: Run | C:\AABUILD\Projects\Common 16.18\AdminArsenal.Product.Server\Reports\Engine\Basic\BasicReportDefinition~Server.cs

Statements: 8

Elapsed: 30.08

Begin Wait: 0.00

All Statements: 30.07

Average Statement: 3.76

0.00: begin

0.06: select distinct CollectionComputerId as Key, ComputerId as Value from (select cc.rowid as CollectionComputerId, cc.ComputerId, cc.CollectionId, c.* from Collections c join CollectionComputers cc using (CollectionId) where IsMember) ComputerCollectionView

0.00: select rowid from Collections ComputerCollectionView where ComputerCollectionView.Name = 'Elitebook' collate nocase

0.02: select CollectionComputerId as [_key], Name as [_value] from (select cc.rowid as CollectionComputerId, cc.ComputerId, cc.CollectionId, c.* from Collections c join CollectionComputers cc using (CollectionId) where IsMember) where CollectionComputerId in (

0.00: select rowid from Collections ComputerCollectionView where ComputerCollectionView.Name = 'ProBook' collate nocase

9.67: select rowid from Collections ComputerCollectionView where ComputerCollectionView.Name glob 'Surface'

10.94: select rowid from Collections ComputerCollectionView where ComputerCollectionView.Name glob 'Toshiba'

9.37: select rowid from Collections ComputerCollectionView where ComputerCollectionView.Name glob 'Latitude'

0

• 

  Curtis Hendzell

  • February 08, 2019 19:13

  Having the exact same issue since the 16.6 upgrade.

  0

  Comment actions Permalink
• 

  Anthony Weiss

  • February 08, 2019 19:43

  I have a case open, no engagement on it since yesterday. Just pinged sales to see what is going on. Will update thread with resolution if one is found.

  Glad to know I have company at least.

  0

  Comment actions Permalink
• 

  Jason Seiberlich

  • February 08, 2019 20:29

  Same here.

  0

  Comment actions Permalink
• 

  Anthony Weiss

  • February 11, 2019 15:28

  @Jason & @Curtis_Hendzell Did you guys open cases as well? Where are you in your case if so?

  0

  Comment actions Permalink
• 

  Jason Seiberlich

  • February 11, 2019 16:07

  No I have not, but I can if you think it will speed things along. So slow even just scanning.

  0

  Comment actions Permalink
• 

  Jason Seiberlich

  • February 11, 2019 16:12

  I have a support ticket in now.

  0

  Comment actions Permalink
• 

  Anthony Weiss

  • February 11, 2019 19:56

  Support had me send DB over to them, they report it is being forwarded to development.

  0

  Comment actions Permalink
• 

  Jason Seiberlich

  • February 11, 2019 20:03

  Same here

  0

  Comment actions Permalink
• 

  Jason Seiberlich

  • February 12, 2019 16:04

  They asked if I had rebooted the server PDQ was installed on. I had already rebooted once but did it again and seems to have helped. CPU usage has been between 0% and up to 30% when scanning a large number.

  0

  Comment actions Permalink
• 

  Anthony Weiss

  • February 13, 2019 14:49

  Any other changes?

  0

  Comment actions Permalink
• 

  Jason Seiberlich

  • February 13, 2019 16:16

  They had me turn off "heartbeat" and then do a scan but it didn't change anything

  0

  Comment actions Permalink
• 

  Jason Seiberlich

  • February 14, 2019 16:44

  They had me install an update (16.6.0.2). Seems ok so far.

  0

  Comment actions Permalink
• 

  Anthony Weiss

  • February 14, 2019 16:53

  Just received the same update myself. Definitely helps the situation, but still very CPU intensive.

  0

  Comment actions Permalink
• 

  Jason Seiberlich

  • February 14, 2019 17:03

  My CPU usage stays around 0%-5% only jumps momentarily when doing a large scan, so mine seems good to go.

  0

  Comment actions Permalink
• 

  Erling Johansen

  • March 16, 2019 04:55

  They send me 16.6.0.8, but still 99-100% CPU utilization. They asked for the DB and it has been forwarded to development.

  0

  Comment actions Permalink
• 

  Anthony Weiss

  • March 21, 2019 12:18

  I am running same as you, but no CPU issues. Support did review my DB and provided guidance on performance improvements:

  Last, if you have any collections using the "member of collection" filter, let's change that to its more reliable filter-cousin "computer collection is member" instead. Development has been able to find a performance issue that is directly related to using that particular filter.

  Not totally sure why this is not a little more publicized, but sounds like a good way to improve performance. I have a ton of these in my environment that I am starting to remediate.

  From Ticket #154507

  One of our clever guys here wrote a SQL report to find filters which might need changing:

  Select Collections.Name as "Collection", reportdefinitionfilters.Value as "Filtering for this Collection" from Collections join reportdefinitionfilters on Collections.ReportDefinitionId = reportdefinitionfilters.ReportDefinitionId where reportdefinitionfilters.tablename = 'Collection'

  0

  Comment actions Permalink

Please sign in to leave a comment.