Filesystem Size Used Avail Use% Mounted on
udev 4.9G 0 4.9G 0% /dev
tmpfs 999M 18M 982M 2% /run
/dev/mapper/ubuntu--vg-ubuntu--lv 1.3T 517G 710G 43% /
tmpfs 4.9G 52K 4.9G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 4.9G 0 4.9G 0% /sys/fs/cgroup
tmpfs 4.9G 0 4.9G 0% /run/shm
/dev/loop0 92M 92M 0 100% /snap/core/8689
/dev/sda2 976M 145M 765M 16% /boot
tmpfs 999M 0 999M 0% /run/user/1000
/dev/loop2 94M 94M 0 100% /snap/core/8935
You should probably check database processes and see if anything takes too long.
Let me check that and revert. there are other database on the server but no issues.. I actually tried vacuuming the tc_positions table and got an error can that be the issue? Deleting some of the records, will try and vacuum again and update
Well, if you just remove all of the positions, it will almost definitely cause some issues. You need to keep the ones that are referenced from devices or clear those references as well.
delete from tc_positions where devicetime < '2020-03-01 00:00:00+00';
delete from tc_events where servertime < '2020-03-01 00:00:00.000';
delete from tc_statistics where capturetime < '2020-03-01 00:00:00.000';
This is what am running at the moment.
if I went ahead and cleared all the lastPositionId on tc_devices will it automatically update with new values
Yes.
There was an issue with our tc_positions tables, during db restoration something much have corrupted it. It was not vacuuming.. On truncating the table things are now okay.
It gets stuck here, it used to start after 20-30mins sometimes, but today it has just refused. I have restarted the server. Restarted the database service
Here is my service file ExecStart: