Description
After updating from version 6 to 7. And upgrading Mongo db to version 6. A month later problems began. Rocket chat runs for 5 minutes, then loads the mongo db process at 100%
Server Setup Information
Version of Rocket.Chat Server: 7.1.0
Operating System: 22.04.5 LTS
Deployment Method: tar
Number of Running Instances: 1
DB Replicaset Oplog: enable
NodeJS Version: v20.17.0
MongoDB Version: 6.0.19 / wiredTiger
Proxy: no
Firewalls involved: no
Any additional Information
Active from 30-50
Total registered 1000
GridFS noUse
reetp
December 16, 2024, 9:38am
4
Better start telling us a lot more about you system.
There is not enough information to diagnose anything.
In the first instance I think it is likely you do not really have enough resources.
What is your server spec?
What is in your error logs?
Have some users tried to download/export their information? That can fill mongo and cause issues.
There have been issues about this on github telling you which tables to check.
I would get something like studio3t and check the table sizes.
VPS server is used for rocket chat only
The server starts to experience problems when up to 10 users connect to it
Logs:
https://drive.google.com/drive/folders/18RHI-iS-J7ty9toQPWyVJp8cctxMGlBM?usp=sharing
reetp
December 16, 2024, 1:51pm
7
I suspect that this may be your issue, or closely related:
opened 02:11PM - 06 Dec 24 UTC
Tasked
### Description:
In the Mongo DB exist in Version 7.0.0 an index which can no… t changed in the update procedure to version 7.1.0
Some indexes for collection 'rocketchat_user_data_files' could not be created:
Error:
An existing index has the same name as the requested index. When index names are not specified, they are auto generated and can cause conflicts. Please refer to our documentation. Requested index: { v: 2, key: { userId: 1 }, name: "userId_1", sparse: true }, existing index: { v: 2, key: { userId: 1 }, name: "userId_1" }
### Steps to reproduce:
1. Install RocketChat Version 7.0.0 with Mongo in an Docker Container
(my Rocket Version 7.0.0 has a Update History from Version 6)
3. Make an Update to the RocketChat 7.1.0 Container (docker compose update -d)
4. I have in the startup log from the RocketChat Container the Error
Some indexes for collection 'rocketchat_user_data_files' could not be created:
An existing index has the same name as the requested index. When index names are not specified, they are auto generated and can cause conflicts. Please refer to our documentation. Requested index: { v: 2, key: { userId: 1 }, name: "userId_1", sparse: true }, existing index: { v: 2, key: { userId: 1 }, name: "userId_1" }
### Expected behavior:
Normal Startup from the RocketChat Container without this message.
It ist a problem in the Indexmodel in Mogo Database from RocketChat Schema.
### Actual behavior:
### Server Setup Information:
-+---------------------------------------------------------+
| SERVER RUNNING |
+---------------------------------------------------------+
| |
| Rocket.Chat Version: 7.1.0 |
| NodeJS Version: 20.18.0 - x64 |
| MongoDB Version: 7.0.7 |
| MongoDB Engine: wiredTiger |
| Platform: linux |
| Process Port: 3000 |
| Site URL: https://rocketchat.xxxx.de |
| ReplicaSet OpLog: Enabled |
| Commit Hash: 73af9c5375 |
| Commit Branch: HEAD |
| |
+---------------------------------------------------------+
### Additional context
### Relevant logs:
Full Startup Process
strict mode: use allowUnionTypes to allow union type keyword at "#/properties/count" (strictTypes)
strict mode: use allowUnionTypes to allow union type keyword at "#/properties/offset" (strictTypes)
(node:1) NOTE: The AWS SDK for JavaScript (v2) is in maintenance mode.
SDK releases are limited to address critical bug fixes and security issues only.
Please migrate your code to use AWS SDK for JavaScript (v3).
For more information, check the blog post at https://a.co/cUPnyil
(Use `node --trace-warnings ...` to show where the warning was created)
Some indexes for collection 'rocketchat_user_data_files' could not be created:
An existing index has the same name as the requested index. When index names are not specified, they are auto generated and can cause conflicts. Please refer to our documentation. Requested index: { v: 2, key: { userId: 1 }, name: "userId_1", sparse: true }, existing index: { v: 2, key: { userId: 1 }, name: "userId_1" }
LocalStore: store created at
LocalStore: store created at
LocalStore: store created at
2024-12-06T13:46:47.604Z 40 pid=1 hostname=2e57b0365cd5 name=VoIPAsteriskService msg=Voip is not enabled. Cant start the service
2024-12-06T13:46:47.858Z 51 pid=1 hostname=2e57b0365cd5 name=Migrations msg=Not migrating, already at version 318
[2024-12-06T13:46:47.892Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/BROKER: Moleculer v0.14.35 is starting...
[2024-12-06T13:46:47.907Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/BROKER: Namespace: <not defined>
[2024-12-06T13:46:47.907Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/BROKER: Node ID:
[2024-12-06T13:46:47.913Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/REGISTRY: Strategy: RoundRobinStrategy
[2024-12-06T13:46:47.915Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/REGISTRY: Discoverer: LocalDiscoverer
[2024-12-06T13:46:47.918Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/BROKER: Serializer: EJSONSerializer
[2024-12-06T13:46:47.931Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/BROKER: Validator: FastestValidator
[2024-12-06T13:46:47.933Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/BROKER: Registered 13 middleware(s).
[2024-12-06T13:46:47.934Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/BROKER: Transporter: TcpTransporter
2024-12-06T13:46:47.970Z 51 pid=1 hostname=2e57b0365cd5 name=DatabaseWatcher msg=Using change streams
[2024-12-06T13:46:47.978Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/TRANSIT: Connecting to the transporter...
[2024-12-06T13:46:47.994Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/TRANSPORTER: TCP server is listening on port 33759
[2024-12-06T13:46:47.997Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/TRANSPORTER: UDP Discovery is disabled.
[2024-12-06T13:46:47.999Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/TRANSPORTER: TCP Transporter started.
2024-12-06T13:46:48.750Z 51 pid=1 hostname=2e57b0365cd5 name=License msg=License installed version=3.0 hash=dmcMGo9A
[2024-12-06T13:46:48.975Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/REGISTRY: '$node' service is registered.
[2024-12-06T13:46:48.977Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/REGISTRY: 'matrix' service is registered.
[2024-12-06T13:46:48.977Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/$NODE: Service '$node' started.
[2024-12-06T13:46:48.977Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/MATRIX: Service 'matrix' started.
[2024-12-06T13:46:48.978Z] INFO e74b1b66-9d09-4ce7-9ebd-5faf8e1bc57d/BROKER: ✔ ServiceBroker with 2 service(s) started successfully in 1s.
ufs: temp directory created at "/tmp/ufs"
+---------------------------------------------------------+
| SERVER RUNNING |
+---------------------------------------------------------+
| |
| Rocket.Chat Version: 7.1.0 |
| NodeJS Version: 20.18.0 - x64 |
| MongoDB Version: 7.0.7 |
| MongoDB Engine: wiredTiger |
| Platform: linux |
| Process Port: 3000 |
| Site URL: https://rocketchat.xxxx.de |
| ReplicaSet OpLog: Enabled |
| Commit Hash: 73af9c5375 |
| Commit Branch: HEAD |
| |
+---------------------------------------------------------+
2024-12-06T13:46:50.332Z 51 pid=1 hostname=xxx name=License msg=License installed version=3.0 hash=xxx
No, I don’t know when a fix will be released - follow the bugs and releases.
Also note this:
There is a very good reason to NOT upgrade straight away, and also why you shoudl test thoroughly before committing to a upgrade.
Note:
A release does NOT constitute a guarantee of stability for you.
It is a development cut that the team want to deliver and feel confident enough that it should work most of the time for most people without issues.
Downgrade Rocket.Chat to version 7.0.0. Fixed the problem for now
reetp
December 18, 2024, 5:27pm
9
Downgrades are not really a solution… they are a temporary workaround.
So we don’t know the cause so if you upgrade again it may well reoccur.
Also note that downgrades are extremely risky and likely to fail. Most upgrades make changes to the DB that are not “backwards compatible”…
The ONLY safe way is backup and restore.
One question.
Why are your mongo logs dated 2023?
{“t”:{“$date”:"2023-06-23