During import of a large number of products, the CPU of our customer’s server reaches 100%, making the web site more or less unresponsive for a couple of minutes. We get the same behaviour if we choose to rebuild the index from Litium’s backoffice, so the problem is definitely related to the large number of documents being reindexed.
Is there a way to slow down the reindexing? Or to make it run on only one or two processors? Or something else?
I guess more hardware would be a solution, but it feels like a poor solution since the hardware is more than what’s actually needed to run the actual website.
Litium version: 6.1
The appSetting IndexProcessorCount will define how many threads that will be used, defaulted to Environment.ProcessorCount.
The Litium.Foundation.Search.IndexJobConsumer have some settings and methods that can stop/start indexing or change the batch-sizes that should be used (and even change the count of processing threads).
That indexing is taking resources is as it should but it should not take down the server for the visitors and is nothing that I have seen before. Do you have any extra functionality for the indexing that is built in the project?
No extra indexing logic at all. Pretty much a standard accelerator site.
Is there a minimum hardware requirement for the indexing to work without interfering too much with the web site? Number of processors? threads?
System requirements Litium 7 have little information.
Do you have possible to do a recording with Jetbrains dotTrace (timeline option) and provide to me for investigation? (Link where I can fetch can be sent in PM)
I don’t have Jetbrains’ tools, but I can of course get them and do a recording, if needed.
However, I have just talked to some colleagues who have developed another Litium web site, completely independent from the development we’ve done. They’re using Litium 6.2.1, no accelerator, and they have a product catalog of roughly the same size as our customer (10.000 products or so). When I asked them to reindex all the products and look at the CPU, the result was exactly the same as we’ve discovered. The CPU went up to 100% during the reindexing phase, which lasted for a minute or two. So, I’m pretty certain that the problem is not related to our customer’s specific implementation.
That the server is using the CPU that exists to make the indexing as fast as possible is what it should do. The indexing thread is set to priority BelowNormal to let request threads get higher priority so they should go before the indexing threads.
1 Like
I have tested a little bit more and the CPU does actually drop from 100% down to 50-90% if I visit the web site while it is reindexing. And the web site responds in a OK way after that.
However, if I start a slightly larger product import, using the integration framework, then the CPU goes up to a 100% and the entire machine is pretty much unresponsive for a very, very long time.
Is it possible to lower the priority of the import threads or do we have to move the integration to a separate machine? Or any other solution to this problem?
@patric.forsgard Any idea why a large product import will slow down the machine so much that it cannot even be accessed via RD during the import?
From what you are describing it seems to me that you need more servers. Large number of products puts pressure on the CPU then count in integration, surfing the website, indexing and etc…
Yes, we may have to put the integration on a separate server. However, I don’t think that 10.000 products is a lot of products and the system should really behave much better during a product import on a server that meets the minimum requirements…
It can be thousands different reasons and is impossible to say why without deeper investigations.
Deeper investigation is then required.
We imported 6000 products yesterday. The import itself took roughly 8 minutes but the CPU hit 100% for over 30 minutes.
One interesting thing, which may be related, is that there are a couple of error messages like this one logged during the import: “Litium.IWebLog - IWebLog exception 'Cannot access a disposed object. A common cause of this error is disposing a context that was resolved from dependency injection…”
I will send all log files etc to your support mailbox.