ScreenConnect on CentOS is sluggish
-
Session.db changed dramatically.
[root@bnasc ~]# ls -l /opt/screenconnect/App_Data/Session.* -rw-r--r--. 1 root root 794624 Feb 6 11:41 /opt/screenconnect/App_Data/Session.db -rw-r--r--. 1 root root 322928640 Feb 6 11:29 /opt/screenconnect/App_Data/Session.db.2017.02.06 -rw-r--r--. 1 root root 32768 Feb 6 11:50 /opt/screenconnect/App_Data/Session.db-shm -rw-r--r--. 1 root root 4128272 Feb 6 11:50 /opt/screenconnect/App_Data/Session.db-wal -
Question on that - Do you have the system do DB maintenance?
-
@gjacobse said in ScreenConnect on CentOS is sluggish:
Question on that - Do you have the system do DB maintenance?!
That answer, is no. My bad on that.
-
@JaredBusch said in ScreenConnect on CentOS is sluggish:
@gjacobse said in ScreenConnect on CentOS is sluggish:
Question on that - Do you have the system do DB maintenance?!
That answer, is no. My bad on that.
It wasn't set on the NTG system at first either. But once set, and allowed to cycle it's kept the DB in check. If you set today, it's likely that it won't process until the next run time, which will be Tuesday Night / Wednesday Morning....
At least that is what SC Support explained to me.
-
@gjacobse said in ScreenConnect on CentOS is sluggish:
@JaredBusch said in ScreenConnect on CentOS is sluggish:
@gjacobse said in ScreenConnect on CentOS is sluggish:
Question on that - Do you have the system do DB maintenance?!
That answer, is no. My bad on that.
It wasn't set on the NTG system at first either. But once set, and allowed to cycle it's kept the DB in check. If you set today, it's likely that it won't process until the next run time, which will be Tuesday Night / Wednesday Morning....
At least that is what SC Support explained to me.
I have a clean Session.db, so nothing there now anyway. Debating if I should put the old one back and let this run.
-
ok, just moved the new session DB out and copied the old one back in. going to setup the maintenance task and see what happens.
[root@bnasc ~]# ls -l /opt/screenconnect/App_Data/ total 635964 -rw-r--r--. 1 root root 803 Nov 4 12:41 ExtensionConfiguration.xml drwxr-xr-x. 2 root root 42 Jan 31 17:59 Helper -rw-r--r--. 1 root root 381 Aug 10 01:05 License.xml -rw-r--r--. 1 root root 16220 Jan 31 17:59 Role.xml -rw-r--r--. 1 root root 322928640 Feb 6 17:03 Session.db -rw-r--r--. 1 root root 322928640 Feb 6 11:29 Session.db.2017.02.06.old -rw-r--r--. 1 root root 1163264 Feb 6 16:30 Session.db.2017.02.06.new -rw-r--r--. 1 root root 32768 Feb 6 17:00 Session.db-shm -rw-r--r--. 1 root root 4132392 Feb 6 17:00 Session.db-wal -rw-r--r--. 1 root root 1045 Jul 1 2014 SessionEventTrigger.xml -rw-r--r--. 1 root root 3250 Jun 21 2016 SessionGroup.xml drwxr-xr-x. 2 root root 86 Jan 31 18:09 Toolbox -rw-r--r--. 1 root root 6001 Feb 6 12:07 User.xml -
big ba-da boom
-
Put the new one back and it start up just fine /sigh
-
Well at least the new one is still okay... would be a major pain otherwise.
-
A week later, the database file is still small with 157 devices having reported back in.
-rw-r--r--. 1 root root 1163264 Feb 6 16:30 Session.db.2017.02.06.new -rw-r--r--. 1 root root 322928640 Feb 6 11:29 Session.db.2017.02.06.old -rw-r--r--. 1 root root 1654784 Feb 11 16:03 Session.db.2017.02.11.newTime to test the backup and contact support if it doesn't load.
-
Worked perfectly this time..
-
Going to run the DB maintenance on this and see what happens.
You can only choose one thehour inthe drop down, so the next hour is 17:00.
Currently 16:12 here.
-
Well, that made just a small amount of difference..
-rw-r--r--. 1 root root 322928640 Feb 6 11:29 Session.db.2017.02.06.old -rw-r--r--. 1 root root 4034560 Feb 11 17:00 Session.db -
Little follow up to this as SC on CentOS was discussed in abother thread.. DB size is still small.
[root@bnasc ~]# ls -l /opt/screenconnect/App_Data/Session.db -rw-r--r--. 1 root root 46764032 Jan 26 12:30 /opt/screenconnect/App_Data/Session.db
