[SOGo] BTS activities for Thursday, September 05 2019

2019-09-05 Thread SOGo reporter
Title: BTS activities for Thursday, September 05 2019





  
BTS Activities

  Home page: http://www.sogo.nu/bugs
  Project: SOGo
  For the period covering: Thursday, September 05 2019

  
  
idlast updatestatus (resolution)categorysummary
	
	
	  
	
2506
	2019-09-05 12:43:28
	resolved (fixed)
	Web Calendar
	Expand group for free/busy check
	
	  
	
  
  


-- users@sogo.nuhttps://inverse.ca/sogo/lists

Re: [SOGo] Performance Tuning

2019-09-05 Thread Ludovic Marcotte

On 2019-09-05 8:10 a.m., bdus...@luzerne.edu wrote:

I have created the info.plist file at 
/var/lib/sogoeas/GNUstep/Defaults as described in step 3.   I believe 
my new instance of sogod isn't reading this file.


With recent versions of GNUstep, the file probably needs to be called:

/var/lib/sogoeas/GNUstep/Defaults/sogod.plist

with the following content:


  http://www.gnustep.org/plist-0_9.xml";>
  

WOPort
3






Make sure permissions are OK and retry to restart. It should be fine now.

--
Ludovic Marcotte
lmarco...@inverse.ca  ::  +1.514.755.3630  ::  https://inverse.ca
Inverse inc. :: Leaders behind SOGo (https://sogo.nu), PacketFence 
(https://packetfence.org) and Fingerbank (https://fingerbank.org)

--
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Performance Tuning

2019-09-05 Thread bdus...@luzerne.edu


Ludovic,

 

Thanks for the information.   I've followed the link you've provided and have created a second instance of sogod.   Unfortunately, my new instance still attempted to listen on tcp 2. 

 

I have created the info.plist file at /var/lib/sogoeas/GNUstep/Defaults as described in step 3.   I believe my new instance of sogod isn't reading this file.  

 


To correct this problem I modified the service file for my original instance as well as the new instance.   Within each of these files I added the -WOPort option to the ExecStart line.   I specified port 2 for my original instance and 3 for the new instance.   Within this change I was able to start both instances and each listened on the correct port.

 

Should this change be avoided?   If so, can you suggest any troubleshooting steps to determine why my plist file for the new instance is being ignored?

 

Thanks,

Bob

 



Bob Dushok
Director of Enterprise Systems and Computer Labs
Luzerne County Community College

1-800-377-5222 ext 7327
bdus...@luzerne.edu

 

 

- Original message -
From: ""Ludovic Marcotte (lmarco...@inverse.ca)" 
Sent by: users-requ...@sogo.nu
To: users@sogo.nu
Cc:
Subject: Re: [SOGo] Performance Tuning
Date: Wed, Sep 4, 2019 11:44 AM
 


Hi,

If you've got over 650 EAS users, a PREFORK of 400 will never work.

EAS clients will fight to get sogod workers and will leave nothing to the SOGo web interface.

Dedicate a SOGo instance to EAS and use a handful of workers for the web interface. See https://sogo.nu/support/faq/dedicated-separate-sogo-instance-for-activesync.html for details.

Ludovic
On 2019-09-04 11:30 a.m., bdus...@luzerne.edu wrote: 


	A few months ago we began providing SOGo for our students.   It was summer and the number of students using the server was limited.   I found tuning was needed, especially the prefork value.   I was able to find good values for our installation within a day or two.  
	We started a new semester a few days ago and our full student body is using the product.   We've encountered performance problems several times a day.   I've handled these problems by making a tuning change and rebooting the server.   Within a few hours the problem returns.   I haven't been able to find appropriate configuration settings for our environment. 
	We have a little over 14,000 users.    I wrote some code which attempts to determine how many users are using ActiveSync.   Searching the nginx access logs I'm finding about 650 unique authenticated accounts posting to /Microsoft-Server-ActiveSync?User=.   I'm only searching logs from the past seven days.    I've also attempted to get a rough estimate of current web users by using:
	netstat | grep http | wc -l 
	I get about 700 returned.   I know this isn't completely accurate, but it gives me an estimate. 
	The server running SOGo is Centos 7.6.   It's virtualized with 8 CPU and 16 GB of ram.   We're a VMware environment.   Checking the server performance doesn't show anything significant.   CPU is usually around 10% with some spikes.   RAM usage is <10GB. 
	Currently my SOGO sysconfig file contains:
	PREFORK = 400
	SOGoMaximumPingInterval = 3540
	SOGoMaximumSyncInterval = 3540
	SOGoInternalSyncInterval = 30
	WOWatchDogRequestTimeout = 5
	WOListenQueueSize = 50 
	I've modified the OS kernel parameters as follows in the sysctl.conf file:
	net.ipv4.tcp_max_syn_backlog=8192
	net.ipv4.tcp_fin_timeout=25
	net.core.somaxconn=1280 
	I run NetData on this server.  It was indicating problem with tcp accept queue overflows and drops.  This is why I made the changes to sysctl.conf.  
	It's now indicating tcp syn cookies queue is overflowing.   I'm going to do some research on this and will make appropriate changes. 
	Does anyone have any suggestions?  I'm making changes, but the performance doesn't appear to be improving much. 
	Thanks,
	Bob 
	Bob Dushok
	Director of Enterprise Systems and Computer Labs
	Luzerne County Community College
	
	1-800-377-5222 ext 7327
	bdus...@luzerne.edu
	-- 
	users@sogo.nu
	https://inverse.ca/sogo/lists


-- 
Ludovic Marcottelmarco...@inverse.ca  ::  +1.514.755.3630  ::  https://inverse.caInverse inc. :: Leaders behind SOGo (https://sogo.nu), PacketFence (https://packetfence.org) and Fingerbank (https://fingerbank.org)

 


-- users@sogo.nuhttps://inverse.ca/sogo/lists