Hello Ingo
I am not a SoGo developer, but I have had similar issues recently with
ever growing numbers of users and especially their calendars.
I have been able to optimize memory and CPU usage with a number of steps:
1. Optimizing NGINX reverse proxy buffer configuration in your site
configuration for SoGo
proxy_busy_buffers_size 512k;
proxy_temp_file_write_size 512k;
client_max_body_size 50m;
client_body_buffer_size 256k
2. Increase the number of threads for SoGo either in /etc/sogo/sogo.conf
or (on Debian) /etc/default/sogo
WOWorkersCount or PREFORK= setting to a reasonable number (at the moment
i am using 15 for ~650 users)
3. Increase memory limit in /etc/sogo/sogo.conf
SxVMemLimit = 2048
4. I use MySQL as database backend, for this there is a very useful
utility https://github.com/major/MySQLTuner-perl
I ended up with the following settings in my.cnf but your results may vary
sort_buffer_size=8M
read_rnd_buffer_size=1024K
join_buffer_size=512K
tmp_table_size=24M
max_heap_table_size=32M
table_definition_cache=12000
innodb_buffer_pool_size=1024M
innodb_log_file_size=256M
innodb_log_buffer_size=72M
max_allowed_packet=1024M
net_read_timeout=3600
net_write_timeout=3600
performance_schema=ON
5. Finally I ended up enabling the sogo_store data channel
OCSStoreURL = "mysql://sogo:XXXXXX@localhost:3306/sogo/sogo_store";
Beware with this last one though. If you had not enabled it before, you
will need to export and import the database, otherwise all calendar data
will become "invisible" to users. There was a thread recently started by
myself with the title "all calendars and entries vanished from web
interface" where Quentin Hivert ([email protected]) gave an answer on
how to do this. I have followed that procedure without problems.
With all those settings our SOGo runs a lot smoother without massive
resource starvation on mere 12G memory and 4 cores with our amount of users.
Greetings;
Daniel
--
D. Kollmer
Computer Technology Group
NIKHEF - Dutch National Institute for Sub-atomic Physics
On 3/17/25 05:28, "Ingo D." ([email protected]) wrote:
We see that SOGo eats up quite a lot of memory, maybe in the end more than the
Exchange Server it replaces (32GB). We now migrated 450 named users to the
system (these users usually are not very active), and we had to increase the
memory recently from 8 to 16 GB after the system became unresponsive. Right
now it runs stable. Are there any recommendations on how the memory
consumption of SOGo can be optimized?
