AI OnAI Off
High CPU after updating 1.5k pages
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?
Feb 14, 2017 14:21
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.
Edited,
Feb 14, 2017 14:55
<p>Hey Thomas, </p>
<p>What version are you on? </p>
<p>If you update so many pages at once you need to think of the post events like for example Find has to reindex all content, and in some versions there are performance bugs related to that. </p>
<p>/Regards</p>
#175195
Feb 14, 2017 16:08
@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.
Feb 14, 2017 17:05
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).
Feb 14, 2017 17:23
I agree with Johan on all points. Is the the CPU never stabilizing?
Please always supply with the minor version no. also.
Feb 15, 2017 8:25
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%.
Feb 15, 2017 8:56
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.
Mar 31, 2017 11:54
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
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.