Sitecore Install Assistant - Everything running smoothly status for long time
Introduction
Today I encountered a weird situation that I haven't experienced in the past with the Sitecore Install Assistant while installing Sitecore 10.3.1. Highlighting right at the start that this is not specific to Sitecore installation but a machine resource issue affecting Sitecore installation.
Machine Specs for reference:
1 TB space
32 GB RAM
The problem
So, straight to the problem: The installation was running fine but then stopped at task 92, I initially thought that this was normal only to find that it hung there for more than 45 minutes. When I checked the installer window, it was smiling back at me with everything running smoothly status:
Analysis
When I checked the installation log, I didn't see anything wrong except this entry:
[-------------- SitecoreXP0_InstallWDP : WebDeploy ---------------------------]
[WebDeploy]:[Path] C:\Program Files\iis\Microsoft Web Deploy V3\msdeploy.exe
This is when I realised something is wrong. I then restarted my machine and ran the installer again. Even this time, the installer stopped at task 92. My brain faculties went in an emergency mode and I opened the task manager to find that the memory usage was at 97% and surprisingly even after restart, this quickly climbed up to 90-100% mark. I sorted the processes based on memory usage, then got rid of some of the processes I thought were extraneous. In my case, since I saw a lot of OpenJDK Platfrom binary processes, I ended a few of those.
Specifically in case of stopping OpenJDK Platform binary processes, the memory went down to about 60% and the installation started moving above the task no. 92 mark. So, beware when you have your Sitecore installation running. That too when you are using your machine like a playground, keep an eye on your task manager and bring down the memory usage if hovering at 90-100% mark.
Although the installer might say everything running smoothly, it doesn't know that your machine is struggling and might be waiting for you to free-up resources in order to move ahead!
Just as an update, list of Solr Services in my machine and each spawned a separate OpenJDK Platform binary process so, stopped all the unused ones:
Once I stopped all unused Solr services and kept only the needed one, my machine had enough resource:
Use Solr services judiciously!
PowerShell script that can bulk start/stop Windows services:
CPU and memory columns in Task Manager
Even generally, as a general old rule, keep a tab on the CPU and memory columns if your machine is running slow or hanging for some reason. Recently, in another virtual machine, I noticed that my CPU column always peaked 100% and I stopped services unrelated to my application and could get back some CPU power but still struggled for processing power in the long run.
Sitecore XPE and processing power
For instance, in this case, the Sitecore application was running on 9.x and every time i accessed XPE, Visual C# Command Line Compiler process was invoked and this hogged about 30% of CPU (shooting from 40-50% to 70-80% range). It was a 16 GB RAM VM. Experience Editor took about 10 minutes to load for the first time or every time compiled code was deployed. This acted as my proof to ask for a virtual machine with better specs.
Animalware Service Executable
One of the processes that hogged a lot of processing power was Animalware Service Executable and I found this link that helped get back processing power. Since this machine was a AWS Workspace and I was using it judiciously, I decided to exclude the MsMpEng.exe.
Skip this section if you are weak-hearted
In my 16
GB RAM AWS Workspace, while I had requested for a space and CPU increment, I
tried this hack and I could live with it. The rogue process that hogged CPU power in
this case was Java (TM) Platform SE Binary. This process was constantly going
up and down in terms of CPU usage and keeping usage at 90-100% mark. So, I
narrowed down that the concerned Solr Service for Sitecore was using this
process.
I took
the chance of totally stopping the concerned Solr service and got back CPU
processing under 40%. After stopping the service and while Sitecore republish
was running this is how it looked:
Since my site isn't heavy on search and also its my own development machine, coding and Sitecore publishing are more important than anything. So, decided to take this chance of stopping Solr service for the site altogether. To my surprise, when I just had the Sitecore instance open in browser and wasn't doing anything, the CPU usage was well under 20% in a 16 GB RAM machine. Also, when I ran a search function at the site-level in PowerShell ISE, returned string search rows in a couple of minutes time and I could live with it since I won't use such a search too often. I thought it is ok to take this chance rather than staring at my development without doing any activities. Only down-side is, I have to be wary that my Solr service is stopped whenever any kind of search functionality is not working.
Resolve Docker Container Startup Errors
Most importantly, if you use Docker and have containers error-out unhealthy while waiting for startup on up.ps1, all the points listed above with regard to CPU usage (inc. Animalware exe folder exclusion as per this link) are still applicable and apart from stopping unused (Solr/Sitecore Processing Engine/Sitecore XConnect Search Indexer) services make respective service startup as manual. I also stop services like SQL Server (hogs a lot of CPU power) since Docker doesn't use it. Be sure not to stop any process/task related to Docker though. This helps drastically improve success of Docker container startup.
Conclusion
With this whole exercise, I realised that if you are working with Sitecore, the Windows task manager is like a calorie monitor, keep it side-by-side and check resource usage pattern in order to take necessary improvement activities and believe me, this could help you optimise resource consumption in higher environments too since you will be aligned to such a line of thinking, you would be in preventive mode rather than on post-mortem!
Comments
Post a Comment