Is there a way to adjust the pm.start_servers, or pm.min/max_spare_servers settings?

[J_Roeleveld]

Hi,

I regularly see messages like:

egroupware            | [18-Aug-2021 10:56:53] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 0 idle, and 75 total children

I know I can extract the www.conf file and configure docker to overwrite it with my own version. But when the PHP-version is updated or any other values have been changed, “my” version may cause issues.

I am thinking of similar values like “EGW_APC_SHM_SIZE”, but for the pm… settings.

[RalfBecker]

I am thinking of similar values like “EGW_APC_SHM_SIZE”, but for the pm… settings.

All the environment variables are documented in the /etc/egroupware-docker/docker-compose.override.yml file, were you can set them.

Other tuning tips are in the wiki page Tuning EGroupware for higher number of users.

That does not include the pm_* settings, which are normally enough for most use-cases, thought you can use the same technic described in the above wiki page, to copy the config file out of the container, modify it for your needs and mount it again into the container, so the modifications are not lost with each new container version.

spawning 32 children, there are 0 idle, and 75 total children

This is quite a high number!

Either we’re are talking about a huge number of users (thousands), or something is slowing down you’re requests a lot. As longer a request takes to process as more processes you need for a constant request rate.

Ralf

[J_Roeleveld]

There are only 3 users, of which I am the one that uses eGroupware the most.
This tends to happen after a restart when I want to open a spreadsheet into Collabora.

The spreadsheet does have a lot (currently 794) of different versions (versioning)

[J_Roeleveld]

I see the same messages when acessing the "Edit settings / Versions " list of this spreadsheet.
If this is caused by “slow” responses, I assume the way the filemanager handles versioning is slow. Are there any suggestions for indexes I can try?

[RalfBecker]

There are only 3 users

That’s unbelievable, we run thousands of users in our hosting with half a docent pods typically around 10 processes permanently running …

Maybe this is an other PostgreSQL quirk, thought we have an other EPL customer running 50 Collabora Sessions with PostgreSQL.

Ralf

Ralf

[J_Roeleveld]

Further testing did show it’s the delay caused by the hundreds of versions. (Same message occurs after restart, with empty caches) when accessing the edit sessions / versions list.

Once that list is cached by the database, the issue doesn’t re-occur.

[J_Roeleveld]

Ralf,

Your comments did lead me to the correct solution:

1. I added a few extra indexes on the “egw_sqlfs” table (These already reduced the amount of processes needed)
2. Increase allowed memory usage of the database. (This reduced the processes even further)

For reference, the added indexes are:

CREATE INDEX egw_sqlfs_fs_created ON public.egw_sqlfs USING btree (fs_created);
CREATE INDEX egw_sqlfs_fs_modified ON public.egw_sqlfs USING btree (fs_modified);
CREATE INDEX egw_sqlfs_fs_dir_fs_name_fs_modified ON public.egw_sqlfs USING btree (fs_dir,fs_name,fs_modified);
CREATE INDEX egw_sqlfs_fs_dir_fs_name_fs_created ON public.egw_sqlfs USING btree (fs_dir,fs_name,fs_created);