System Lockups with ScreenConnect 6.0.11622.6115 on CentOS 7

[scottalanmiller]

HTOP when things are healthy:

[scottalanmiller]

TOP when healthy:

[scottalanmiller]

GLANCES when healthy:

[scottalanmiller]

We know that the process that takes the system resources is mono which is screenconnects parent container.

[hobbit666]

Looks like i'm running the same version:-

On CentOS7 ( I think it's all up to date with patches etc)

Not seeing this problem.
Running on XenServer 7 - 2vCPU 2GB RAM 40GB HD Space

[scottalanmiller]

@hobbit666 take a look at your SAR output, any chance that you have one threading engine hitting the wall and one that is not?

[scottalanmiller]

We are resizing the instance up to 2 vCPU and 2GB RAM right now to see what happens with more resources available at ScreenConnect support's request. But it is not using the resources available to it now, we are afraid of masking the issue and getting the system limping along rather than fixing it.

[gjacobse]

@DustinB3403 said in System Lockups with ScreenConnect 6.0.11622.6115 on CentOS 7:

Any chance you can clone this VM, and downgrade the SC version to the previous version. And monitor both, putting them side by side?

No, can't downgrade that easily as the Client version would be different and not likely to re-sync

[scottalanmiller]

Resized and the issue remains. Look at that CPU load for an idle box!!

[hobbit666]

Sorry @scottalanmiller i'm a Linux newb

How do I run the SAR stuff?

[gjacobse]

@hobbit666 said in System Lockups with ScreenConnect 6.0.11622.6115 on CentOS 7:

Sorry @scottalanmiller i'm a Linux newb

How do I run the SAR stuff?

If it is installed, form CLI just run

sar

[gjacobse]

@gjacobse said in System Lockups with ScreenConnect 6.0.11622.6115 on CentOS 7:

@hobbit666 said in System Lockups with ScreenConnect 6.0.11622.6115 on CentOS 7:

Sorry @scottalanmiller i'm a Linux newb

How do I run the SAR stuff?

If it is installed, form CLI just run

sar

If it is not installed

$ yum install sysstat

[gjacobse]

Example of $ sar

$ sar
Linux 3.10.0-327.10.1.el7.x86_64 (dny-lnx-sc)   12/15/2016      _x86_64_        (2 CPU)

10:56:35 AM       LINUX RESTART

11:00:02 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
11:10:01 AM     all     22.30      0.00      0.85      0.16      3.05     73.64
Average:        all     22.30      0.00      0.85      0.16      3.05     73.64

Or as above from @scottalanmiller with $ sar -b

[hobbit666]

This is all i'm getting from SAR

[root@screenconnect6 ~]# sar
Linux 3.10.0-327.28.3.el7.x86_64 (screenconnect6) 15/12/16 x86_64 (2 CPU)

16:20:43 LINUX RESTART

[hobbit666]

@scottalanmiller said in System Lockups with ScreenConnect 6.0.11622.6115 on CentOS 7:

Resized and the issue remains. Look at that CPU load for an idle box!!

How do you get that pretty picture??

Funny I was about to start a thread about tuning Linux systems for resources so I can free some up for more VM's

[scottalanmiller]

@hobbit666 said in System Lockups with ScreenConnect 6.0.11622.6115 on CentOS 7:

This is all i'm getting from SAR

[root@screenconnect6 ~]# sar
Linux 3.10.0-327.28.3.el7.x86_64 (screenconnect6) 15/12/16 x86_64 (2 CPU)

16:20:43 LINUX RESTART

Takes ten minutes to accumulate the first line of data.

[scottalanmiller]

@hobbit666 said in System Lockups with ScreenConnect 6.0.11622.6115 on CentOS 7:

@scottalanmiller said in System Lockups with ScreenConnect 6.0.11622.6115 on CentOS 7:

Resized and the issue remains. Look at that CPU load for an idle box!!

How do you get that pretty picture??

Command is htop, it's in the EPEL. Then I just screenshot it. It's the default terminal on Ubuntu 16.10.

[hobbit666]

OK so i'll leave my VM running over night as i'll be heading home soon.

I've put a sticky note on my monitor to remind me to run the commands and post screenshots

[scottalanmiller]

Tagging @LG-at-ConnectWise

[scottalanmiller]

Current status, SC wants us to run a DB maintainance job. But due to some bug in SC, it takes two days to run. So it was scheduled to run early this morning but won't kick off until Saturday. So no way to get feedback on the system till Monday. Considering the need for the maintenance was done Wednesday, could not be kicked off because of their GUI dependency till Thursday, takes two days to run and two days to respond, it has turned into a five day turn around, at best, on what should have been a thirty minute issue.