ScreenConnect on CentOS is sluggish
-
@JaredBusch said in ScreenConnect on CentOS is sluggish:
Our server definitely does perform better on a Windows OS as we use .NET instead of Mono.
While native .NET does have advantages over Mono, that statement alone doesn't make sense. That's only one piece of the puzzle.
-
@scottalanmiller said in ScreenConnect on CentOS is sluggish:
@JaredBusch said in ScreenConnect on CentOS is sluggish:
Our server definitely does perform better on a Windows OS as we use .NET instead of Mono.
While native .NET does have advantages over Mono, that statement alone doesn't make sense. That's only one piece of the puzzle.
Totally agree here. Mono does a pretty good job in most cases, even performance-wise.
-
@thwr said in ScreenConnect on CentOS is sluggish:
@scottalanmiller said in ScreenConnect on CentOS is sluggish:
@JaredBusch said in ScreenConnect on CentOS is sluggish:
Our server definitely does perform better on a Windows OS as we use .NET instead of Mono.
While native .NET does have advantages over Mono, that statement alone doesn't make sense. That's only one piece of the puzzle.
Totally agree here. Mono does a pretty good job in most cases, even performance-wise.
And why even use Mono? Native .NET is available. I wonder why they don't mention it?
-
Current htop sorted by memory:
-
@scottalanmiller said in ScreenConnect on CentOS is sluggish:
@thwr said in ScreenConnect on CentOS is sluggish:
@scottalanmiller said in ScreenConnect on CentOS is sluggish:
@JaredBusch said in ScreenConnect on CentOS is sluggish:
Our server definitely does perform better on a Windows OS as we use .NET instead of Mono.
While native .NET does have advantages over Mono, that statement alone doesn't make sense. That's only one piece of the puzzle.
Totally agree here. Mono does a pretty good job in most cases, even performance-wise.
And why even use Mono? Native .NET is available. I wonder why they don't mention it?
That is quite new, and they probably have not spent time to change because they prefer windows.
-
@JaredBusch said in ScreenConnect on CentOS is sluggish:
@scottalanmiller said in ScreenConnect on CentOS is sluggish:
@thwr said in ScreenConnect on CentOS is sluggish:
@scottalanmiller said in ScreenConnect on CentOS is sluggish:
@JaredBusch said in ScreenConnect on CentOS is sluggish:
Our server definitely does perform better on a Windows OS as we use .NET instead of Mono.
While native .NET does have advantages over Mono, that statement alone doesn't make sense. That's only one piece of the puzzle.
Totally agree here. Mono does a pretty good job in most cases, even performance-wise.
And why even use Mono? Native .NET is available. I wonder why they don't mention it?
That is quite new, and they probably have not spent time to change because they prefer windows.
I'm not surprised that they've not put time into it, but just saying that it's slow on Linux because of Mono needs a qualifier like "and we've decided to use Mono for now" or "Native .NET isn't ready yet and lacks something we need". The statement that they make is sensible only because we know Mono is being used by them, but on its own, the statement is weird because Linux is a fully viable Microsoft .NET platform now and it's been a big deal.
I'm not upset that they haven't tested or ported yet, but they could present that better, I feel. And it suggests that moving to Windows for .NET isn't a long term thing as we already have it native on Linux now. So we just have to wait for them to start using it.
-
@scottalanmiller said in ScreenConnect on CentOS is sluggish:
@JaredBusch said in ScreenConnect on CentOS is sluggish:
@scottalanmiller said in ScreenConnect on CentOS is sluggish:
@thwr said in ScreenConnect on CentOS is sluggish:
@scottalanmiller said in ScreenConnect on CentOS is sluggish:
@JaredBusch said in ScreenConnect on CentOS is sluggish:
Our server definitely does perform better on a Windows OS as we use .NET instead of Mono.
While native .NET does have advantages over Mono, that statement alone doesn't make sense. That's only one piece of the puzzle.
Totally agree here. Mono does a pretty good job in most cases, even performance-wise.
And why even use Mono? Native .NET is available. I wonder why they don't mention it?
That is quite new, and they probably have not spent time to change because they prefer windows.
I'm not surprised that they've not put time into it, but just saying that it's slow on Linux because of Mono needs a qualifier like "and we've decided to use Mono for now" or "Native .NET isn't ready yet and lacks something we need". The statement that they make is sensible only because we know Mono is being used by them, but on its own, the statement is weird because Linux is a fully viable Microsoft .NET platform now and it's been a big deal.
I'm not upset that they haven't tested or ported yet, but they could present that better, I feel. And it suggests that moving to Windows for .NET isn't a long term thing as we already have it native on Linux now. So we just have to wait for them to start using it.
Looks like they are testing it. I asked about it.
That was a subject of our meeting with development last week. They hit some kind of roadblock, but it's definitely being looked into.
-
@JaredBusch Cool, if they had it out on that in 6-9 months I'd be thrilled. Our performance has been okay with Mono, but the whole Mono-wrapper thing is an unnecessary bit of overhead. I'm guessing the Linux server will surge forward in speed once they get that working. Hopefully no major roadblocks.
-
Alright, upped the memory to 4gb for testing and wiped the sessions.db file.
So far only a single high CPU warning right at boot time, so going to expect/accept that.
2017-02-06 11:41:29 CPU user (82.1/84.6/87.0) -
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..
