CPU spikes after upgrading to another instance

We migrate our pritunl server in AWS from Oracle Linux 7.9 (t3.nano) to Oracle Linux 9.3 (t3.micro).
To maintain users, we dumped mongodb and restored it to the new instance
old-instance-OL7.9 (pritunl v1.30.3157.70 and mongodb version 4.4.15):
mongodump --db=pritunl

new-instance-OL9.3 (pritunl v1.32.3805.95 and mongodb version 6.0.15):
mongorestore dump

After this migration, the new instance is behaving very differently, with CPU spikes approximately every 2 hours taking 20 to 40 minutes and this causes the client to disconnect from pritunl during this period.

In the mongodb log it appears that PeriodicTaskRunner was triggered, and things like this appear:

{"t":{"$date":"2024-06-07T17:15:56.893-03:00"},"s":"I",  "c":"COMMAND",  "id":20499,   "ctx":"ftdc","msg":"serverStatus was very slow","attr":{"timeStats":{"after basic":862,"after activeIndexBuilds":4067,"after asserts":7486,"after batchedDeletes":10262,"after bucketCatalog":11068,"after catalogStats":16917,"after connections":21424,"after electionMetrics":26007,"after extra_info":27024,"after featureCompatibilityVersion":29350,"after flowControl":33638,"after globalLock":38656,"after indexBulkBuilder":44002,"after indexStats":46950,"after locks":57366,"after logicalSessionRecordCache":60056,"after mirroredReads":62115,"after network":70903,"after opLatencies":76382,"after opcounters":83991,"after opcountersRepl":91594,"after oplog":99192,"after oplogTruncation":107563,"after readConcernCounters":117856,"after readPreferenceCounters":127173,"after repl":132083,"after scramCache":144101,"after security":194144,"after storageEngine":231501,"after tcmalloc":386373,"after tenantMigrations":412724,"after trafficRecording":425033,"after transactions":445070,"after transportSecurity":461052,"after twoPhaseCommitCoordinator":485772,"after wiredTiger":2021358,"at end":2023622}}}
{"t":{"$date":"2024-06-07T17:15:57.544-03:00"},"s":"I",  "c":"WRITE",    "id":51803,   "ctx":"LogicalSessionCacheRefresh","msg":"Slow query","attr":{"type":"update","ns":"config.system.sessions","command":{"q":{"_id":{"id":{"$uuid":"fa77242a-7eb6-4d28-af42-9fef3fc6a444"},"uid":{"$binary":{"base64":"47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=","subType":"0"}}}},"u":[{"$set":{"lastUse":"$$NOW"}}],"multi":false,"upsert":true},"planSummary":"IDHACK","keysExamined":1,"docsExamined":1,"nMatched":1,"nModified":1,"nUpserted":0,"keysInserted":1,"keysDeleted":1,"numYields":2,"locks":{"ParallelBatchWriterMode":{"acquireCount":{"r":6}},"FeatureCompatibilityVersion":{"acquireCount":{"r":3,"w":6}},"ReplicationStateTransition":{"acquireCount":{"w":6}},"Global":{"acquireCount":{"r":3,"w":6}},"Database":{"acquireCount":{"w":6}},"Collection":{"acquireCount":{"w":6}},"Mutex":{"acquireCount":{"r":3}}},"flowControl":{"acquireCount":6,"timeAcquiringMicros":22480618},"storage":{},"durationMillis":1205075}}
{"t":{"$date":"2024-06-07T17:15:58.394-03:00"},"s":"I",  "c":"COMMAND",  "id":51803,   "ctx":"LogicalSessionCacheRefresh","msg":"Slow query","attr":{"type":"command","ns":"config.$cmd","command":{"update":"system.sessions","ordered":false,"writeConcern":{"w":"majority","wtimeout":15000},"$db":"config"},"numYields":7,"reslen":171,"locks":{"ParallelBatchWriterMode":{"acquireCount":{"r":14}},"FeatureCompatibilityVersion":{"acquireCount":{"r":5,"w":14}},"ReplicationStateTransition":{"acquireCount":{"w":14}},"Global":{"acquireCount":{"r":5,"w":14}},"Database":{"acquireCount":{"w":14}},"Collection":{"acquireCount":{"w":14}},"Mutex":{"acquireCount":{"r":8}}},"flowControl":{"acquireCount":14,"timeAcquiringMicros":22480629},"writeConcern":{"w":"majority","wtimeout":15000,"provenance":"clientSupplied"},"waitForWriteConcernDurationMillis":38,"storage":{},"protocol":"op_msg","durationMillis":2072093}}
{"t":{"$date":"2024-06-07T17:15:59.488-03:00"},"s":"I",  "c":"INDEX",    "id":5479200, "ctx":"TTLMonitor","msg":"Deleted expired documents using index","attr":{"namespace":"pritunl.tasks","index":"timestamp_1","numDeleted":189,"durationMillis":2028922}}

After the migration, do you need to do anything specific that wasn’t done?
Could there be a problem upgrading mongodb 4 to 6?

The t3 instance shapes will not be large enough for most use cases. The command sudo pritunl repair-database will clear temporary data in the database and rebuild the IP pool. This could fix the issue. The server must be stopped with sudo systemctl stop pritunl before running this command.

We have always used a t3.nano and we never had a problem, we only have 5 users, so we don’t use the VPN much. I will test the repair-database.

Hi Zach, we tested this and it didn’t work, after stopping pritunl and running repair-database, we started pritunl and around 50 minutes later there was a cpu spike.

The CPU is around 50%, probably using 1vcpu, and out of memory happened in the process, so we believe that the things that are happening in mongodb are using a lot of memory, and as a result the machine is very compromised.

For comparison, the graph below is our CPU usage for approximately 1 month of continuous VPN use using Oracle Linux 7.9, with Pritunl V1.30 and mongodb 4.4 on a t3.nano instance.

Below is after we created a new Oracle Linux 9.3 instance on a t3.micro and installed pritunl v1.32, mongodb 6.0 and restored the old database.

Monitor the usage on the system to find what process is creating the CPU usage.