ScreenConnect on CentOS is sluggish

[gjacobse]

@JaredBusch said in ScreenConnect on CentOS is sluggish:

@gjacobse said in ScreenConnect on CentOS is sluggish:

@JaredBusch

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.

[JaredBusch]

@gjacobse said in ScreenConnect on CentOS is sluggish:

@JaredBusch said in ScreenConnect on CentOS is sluggish:

@gjacobse said in ScreenConnect on CentOS is sluggish:

@JaredBusch

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.

[JaredBusch]

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

[JaredBusch]

big ba-da boom

[JaredBusch]

Put the new one back and it start up just fine /sigh

[gjacobse]

Well at least the new one is still okay... would be a major pain otherwise.

[JaredBusch]

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.new

Time to test the backup and contact support if it doesn't load.

[JaredBusch]

Worked perfectly this time..

[JaredBusch]

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.

[JaredBusch]

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

[JaredBusch]

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