cpanelsolr high resource usage after recent cPanel update
Hello,
After the most recent cPanel update (about 14 hours ago), I started noticing that the cpanelsolr process is consistently using system resources for unusually long periods.
The process is not failing or being killed, but it seems to remain active and consuming resources for several hours without apparent release or cycling.
I manually killed the process about 2 hours ago, thinking that restarting it would solve the issue, but the process automatically restarted and the behavior persists.
Here is the process information when I inspected it:
Process: cpanelsolr
Executable: /usr/lib/jvm/java-11-openjdk-11.0.25.0.9-2.el8.x86_64/bin/java
Command Line: /usr/lib/jvm/jre-11/bin/java -server -Xms512m -Xmx512m -XX:+UseG1GC -XX:+PerfDisableSharedMem -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=250 -XX:+UseLargePages -XX:+AlwaysPreTouch -XX:+ExplicitGCInvokesConcurrent -Xlog:gc*:file=/home/cpanelsolr/server/logs/solr_gc.log:time,uptime:filecount=9,filesize=20M -Dsolr.jetty.inetaccess.includes= -Dsolr.jetty.inetaccess.excludes= -Dsolr.log.dir=/home/cpanelsolr/server/logs -Djetty.port=8984 -DSTOP.PORT=7984 -Dhost=127.0.0.1 -Duser.timezone=UTC -XX:-OmitStackTraceInFastThrow -XX:+CrashOnOutOfMemoryError -XX:ErrorFile=/home/cpanelsolr/server/logs/jvm_crash_%p.log -Djetty.home=/home/cpanelsolr/server -Dsolr.solr.home=/home/cpanelsolr/server/solr -Dsolr.install.dir=/home/cpanelsolr -Dsolr.install.symDir=/home/cpanelsolr -Dsolr.default.confdir=/home/cpanelsolr/server/solr/configsets/_default/conf -Xss256k -Djava.security.manager -Djava.security.policy=/home/cpanelsolr/server/etc/security.policy -Djava.security.properties=/home/cpanelsolr/server/etc/security.properties -Dsolr.internal.network.permission=* -DdisableAdminUI=false -Dlog4j2.formatMsgNoLookups=true -Dsolr.autoSoftCommit.maxTime=3000 -Dsolr.log.muteconsole -jar start.jar --module=http --module=requestlog --module=gzip
Current status:
Active: active (running) since Wed 2025-07-02 11:26:32 CST; 2h 27min ago
Memory: 585.8M
System information:
AlmaLinux 8.10 (Cerulean Leopard)
Kernel: el8
I also found a related support case: CPANEL-48037 regarding tzdata-java updates causing Solr to fail to start.
In my case, Solr is starting and running correctly, but it is consuming resources for extended periods and seems to remain "stuck" in high activity indefinitely.
Has anyone else experienced this after the latest update?
Is this expected behavior or could it be a side effect of the recent changes?
Thank you for your help.
-
Any update?
0 -
I don't have any updates on this just yet. I did speak with the developers just now about the issue so I can confirm things are being reviewed, but this case just hasn't been a high priority.
0 -
Any update on this case? I've been having the same issue for a few months now.
0 -
Unfortunately I still don't have anything on my end. If you're able to reproduce this could you please submit a ticket so we can see this in action?
0 -
Unfortunately I am in the same boat as others; I have a 'Partner Supported License' and I have an unsupported plan - I'll reach out to my provider, but it is unlikely anything will come of it.
0 -
Any solution? Or should I just add as exception the cpanelsolr to lfd?
0 -
GT-user- you should exclude this process, yes.
0 -
cPRex Hiding it from your reporting by excluding it doesn’t make the error go away.
0 -
It's not our reporting, and it's not an error :)
0 -
This issue started after an update applied by your team. Since that update, the cpanelsolr process consistently consumes excessive system resources, without releasing them or cycling as it did before.
Historically, cpanelsolr behaved as a short-lived, burst-based background process: after a mailbox change, it would wake up, process a limited batch, and then return to an idle state. That behavior was stable and predictable.
Post-update, that behavior has clearly changed. The process now runs continuously, holding resources indefinitely. This is a regression, not a configuration issue on our side, and it is not acceptable behavior in a production environment.
In addition, instead of actively assisting in diagnosing or resolving the problem, the response so far appears to be moving into a denial phase, rather than acknowledging the behavioral change introduced by the update.
We are looking for acknowledgment of the regression and concrete remediation steps, not deflection.
0 -
Stefan, please don't be too hard on them, they had a lot of work with the price increase plan.
1 -
GT-user - I'm not going to deal with trolling
Stefan Devroey - just because the way the process runs changed doesn't mean it's bad or broken. CSF/LFD just gives warnings about the process because it runs longer than an arbitrary threshold *and* CSF didn't get an update since we released this change. If the only issue you're seeing is the complaint from CSF, you'll need to exclude the process from their checks. That's the only solution that will keep that from happening.
Now, if you're seeing another problem, such as extra resource usage or the service failing, that would be something we can look into.
0
Please sign in to leave a comment.
Comments
42 comments