We ran a scheduled job to update 1.5k pages - adding a new property to hold a Google Analytics tag. When we copied those changes to our production database, the CPU spiked to 100%.
Is there any reason anyone can think of to cause this? The episerver cache?
Thanks in advance for any ideas.
A related question would be - what happens when you update a page via the database, rather than the CMS? If we were updating 1.5k pages on one environment, then copying the database over to our prod environment, would that explain high CPU?
The reason is probably because you updated 1.5K pages :) Of course the system is trying to use as much resources as possible to finish its tasks as soon as possible.
If you update the database, and not through supported APIs, you probably have to restart the application to update the cache.
@GOSSO we are on Episerver 9 but do not use Find. We don't think it is indexing. One hypothesis is the high CPU is related to the Episerver output cache invalidating, but we don't actually know. If anyone has any other suggestions, please let us know.
But the CPU stabilizes itself after the import? Then I don't see any issues here.
The output cache has dependencies to the views (if they change on disk) and a global version key for all content in the content repository (i.e. not per content item). So if you work against the database directly and not through the APIs, this cannot be the issue. The object cache on the other hand is dependant on each content item.
Do you have a lot of page views during the import? Otherwise the cache invaldating all the time shouldn't be an issue, given that you import through the API, otherwise the cache is not invalidated.
Saving content is the most resouce heavy you can do in Episerver basically. So imports should be done during night (or when you have less visitors).
I agree with Johan on all points. Is the the CPU never stabilizing?
Please always supply with the minor version no. also.
I would suggest to do some profiling of the site during the. I'm less familiar with Google Analytics and related stuffs, but if you are updating contents, it should be the disk usage which spikes, it's unlikely that the CPU hits 100%.
Thank you for the replies everyone. I really appreciate the help. It turns out the bulk updating of pages was a red-herring. The high CPU was caused by a change that went out in the same deployment - some complex logic to render our navigation. We've reverted the code and all good.