Hi Anton,
Thank you for sharing your insights. To address your points:
On my end, I will continue to monitor key metrics that might shed light on the root cause of this issue. Please do not hesitate to reach out if you have any further questions or require additional information.
Hello B.Ihab,
did you happen to find a solution? We have the same problem happening, usually, during the night. Traccar stops writing into the database (and into the logs) until we restart the database, we can't find any specific error in the logs before it stops working.
We have the following system configuration:
Frontend (where traccar is installed)
OS: CentOS Stream 9
CPU 4 CPU Cores
RAM 8 GB RAM
Storage 70 GB
Backend (DB)
OS: CentOS Stream 9
CPU 6 CPU Cores
RAM 32 GB RAM
Storage 920 GB
We have followed the optimization guide and also increased the "innodb_buffer_pool_size" to 24GB.
Thank you and have a good day
Hi @twin,
On my case I was giving too much RAM to buffer pool which lead my system to use the swap, but it clearly not the issue on your side on the database side, I'll expect more the 8GB on the Frontend, I don't know how much devices you have, but the ratio between 8gb on frontend and 32 gb in DB is just irrational, there is two possible issue I can think of:
1- You have too much device that a 8gb instance couldn't handle ( supposing you tweaked the heap and stack )
2- You have multiple database, app ... on you DB server that 24 GB on the buffer pool + the memory system usage + the memory that other db/app exceed the 32 GB dedicated and start using the swap.
You can monitor your both systems using atop or htop ...
Hi there,
I am writing to request assistance with an issue we are encountering in Traccar, which we have been using for approximately 3 years (starting from version 4.xx).
We are currently managing over 1,000 GPS devices communicating with the server every 10s. Unfortunately, we are experiencing intermittent data loss for these devices. After a certain period - days sometimes weeks -, data reception for all devices stops. Restarting either the database temporarily resolves the issue but not in all cases.
For your reference, I have attached relevant logs, our configuration server details, and database configuration. Any insight or suggestions you may have regarding this issue would be greatly appreciated.
Thank you for your time.
Log:
VPS Backend configuration:
VPS database configuration:
Database configuration:
Traccar configuration:
Linux configuration:
We did all the recommended optimization, but only on the traccar server not on the Database server:
https://www.traccar.org/optimization/
Nothing wrong on : mysql-error.log, mysql-slow.log, traccar.log
We tried with 2 traccar instance on the same time, and we noticed the same behavior, which made us think that the problem is on the database side.