- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Announcing Quantum R82.10!
Learn MoreOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hi,
We notice our SmartConsole (R81) becomes quite sluggish over time. Once we upgrade our management appliance to a new version (like when we upgraded from R80.40 to R81), it's fast again, but it degrades over time.
What would be the maintenance actions we could do when it's getting too slow ? Something we can do on the database or else ? Maybe a magic script that would do a set of operations against the management DB and processes ?
We already checked the disk space and log retention, all looks fine and unchanged for years.
Thanks in advance for your advises.
Regards,
A.
My guess is it's the number of database revisions that exist.
When you migrate to a new version, we only take the most recently database version across.
I assume, as you make changes over time, this makes the database...larger.
You can purge revisions using: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
In R81, we added an automatic purge function, which I believe we adjusted the settings for in R81.10.
You can see the settings for it with: https://sc1.checkpoint.com/documents/latest/APIs/#cli/show-automatic-purge~v1.8%20
Note that R81.10 should also be faster for other reasons (namely we eliminate a solr instance).
Maybe it worth to take this with TAC. Could be either DB or SmartConsole cache, or both.
Thats very interesting problem you have...I have few questions, hopefully we can help you with this. So, did this problem happen only after you upgraded from R80.40 to R81? What was the original version of the management? Did it come with R80.40 or is it a VM built with a different code all together? Is it a physical appliance?
Can you share output of show asset all from clish? Also, do you notice any specific process maybe consuming higher percentage of memory/cpu? I believe @Timothy_Hall provided someone with a script to run for similar issue in another post, I just have to search to see if I can find it for you.
K, got it, below is the link...My apologies in advance as it might not be 100% related, but worth checking.
My guess is it's the number of database revisions that exist.
When you migrate to a new version, we only take the most recently database version across.
I assume, as you make changes over time, this makes the database...larger.
You can purge revisions using: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
In R81, we added an automatic purge function, which I believe we adjusted the settings for in R81.10.
You can see the settings for it with: https://sc1.checkpoint.com/documents/latest/APIs/#cli/show-automatic-purge~v1.8%20
Note that R81.10 should also be faster for other reasons (namely we eliminate a solr instance).
I always keep forgetting about DB revisions... @PhoneBoy ...any idea how many revisions are kept in R80.xx or R81 by default? I dont believe there is a manual setting like back in R77.xx where you can choose how long you wish to keep them.
R81.10 set some defaults.
Not sure about previous versions, but we do support the automatic purge API in JHF going back to R80.20: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
Which means: you can ask the API what the settings are.
Thanks as always!
Thanks for your answer, we'll have a look at those revisions and how to automatically purge them after a while.
Do you already recommend upgrading the management to R81.10 ?
Officially, R81 is the recommended release.
That said, we already have several hundred management installations on R81.10 with great feedback so far.
As of “Do you already recommend upgrading the management to R81.10 ?”
I would personally say yes.
When we make release recommended, we recommend both the management and the GW - for simplicity, we avoid recommending mgmt separately from gw.
But mgmt is safer to move to new version and risk of impact on production is much lower, therefore having mgmt on latest is reasonable and it gives you the opportunity to enjoy significant improvements (such as performance and scale of mgmt server as result of removal of solr indexing on mgmt objects, it remains in usage of logs index).
We do already have hundreds of customers that migrated their mgmt and things look good even though the official status to widely recommended happens only once all scenarios of the version pass massive usage and validation.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 21 | |
| 15 | |
| 7 | |
| 6 | |
| 5 | |
| 5 | |
| 4 | |
| 4 | |
| 4 | |
| 4 |
Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY