IIS App pool issue - Something is either randomly Spiking the server CPU to 100% or stoping the App pool.

IIS App pool issue - Something is either randomly Spiking the server CPU to 100% or stoping the App pool


IIS server winodws 2016
IIS version 10.0.14393.0

TRIM version 9.2

We have an API intergration with trim (via IIS on a server) This actions a number off things. Calls to and from in house applications to trim and also certain automated jobs loads files into trim via the same API.

For a few years now we have had random IIS spiking to 100% (in task manager it is always the w3wp.exe) an/or the IIS API pool just stops.No pattern has ever been found, weeks or months can go by until happens.

In windows event view - windows logs -  application when ever either spiking or IIS stops we always seem to see the same error. We think this is the crux off the issue but we do not know what it means. Can anyone give any clues as to the spiking/API pool stoping.

The description for Event ID 100 from source TRIMWorkgroup cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
[32544] Warning: Making room in document cache - Wait abandoned for mutex 'TRIM_CCHBaseCache_makeRoom'.

he specified resource type cannot be found in the image file

Parents
  • 0

    I don't have an outright answer to your questions, just some observations based on our experiences with multiple integrations.  The first I will point out is that long searches - especially where a sort or wide searching can result in APIs going long in its response.  In order to know why API performance is sluggish or non-responsive a deeper dive through a tool like Dynatrace would be necessary.  In one particular case, we found that an API was acting up based on a search that did a high number of records with matching criteria and then sort.  This is also a long request in the rich client.  Perhaps asking your developers what kinds of calls they are doing will help in your diagnostics?  Dynatrace was able to give us clues on what was happening in this case.  It also showed us periods in which user frustration and response times were high. 

    Another issue I've observed is any kind of wide batch processing - like a database true up, where an API will hammer us with requests over multiple connections would cause an obvious decrease in performance.  Without discussing the actual processes with the CM API, your developers can do unexpected calls that could be done in more efficient manner.  For example,  the dev wanted to see what records were deleted - so guess what? At 2 AM on a Sunday they decided to download the entire collection's data - where the more efficient effort would have been looking at the audit log searching for URIs that matched their database for deletion events.  

Reply
  • 0

    I don't have an outright answer to your questions, just some observations based on our experiences with multiple integrations.  The first I will point out is that long searches - especially where a sort or wide searching can result in APIs going long in its response.  In order to know why API performance is sluggish or non-responsive a deeper dive through a tool like Dynatrace would be necessary.  In one particular case, we found that an API was acting up based on a search that did a high number of records with matching criteria and then sort.  This is also a long request in the rich client.  Perhaps asking your developers what kinds of calls they are doing will help in your diagnostics?  Dynatrace was able to give us clues on what was happening in this case.  It also showed us periods in which user frustration and response times were high. 

    Another issue I've observed is any kind of wide batch processing - like a database true up, where an API will hammer us with requests over multiple connections would cause an obvious decrease in performance.  Without discussing the actual processes with the CM API, your developers can do unexpected calls that could be done in more efficient manner.  For example,  the dev wanted to see what records were deleted - so guess what? At 2 AM on a Sunday they decided to download the entire collection's data - where the more efficient effort would have been looking at the audit log searching for URIs that matched their database for deletion events.  

Children
No Data