Bug 16190 enables the indexer daemon by default for package installations. I just upgraded my test server to 16.05.01. This server has 57 instances on it, so it might be a bit of an outlier. But right after the upgrade started the server maxed out on load, memory usage and swap. To the point where everyting became unbearably slow. I tried setting INDEXER_TIMEOUT=30 in /etc/default/koha-common and rebooting, but the same problem appeared almost at once. Setting USE_INDEXER_DAEMON="no" and rebooting made the server usable again. Not sure if this should be considered a problem, or if the problem is the high number of instances on one server. The server is a "Linode 4096" and it has been running this number of instances (which have very low usage) without any problems for a long time prior to the upgrade.
The indexer timeout wouldn't have any impact (the CPU footprint is small for indexer daemons), problem is memory. I'd say such a highly demanded server is a special situation that the sysadmin should be able to handle. But I'd say you will be trading memory for high CPU usage if you stick to the usual cronjobs on that many instances. For me this is a WORKSFORME
I have ~25 test instances on a small server with 4 GB ram. I upgraded to 16.05.01, so far I can't see anything like that. 3 CPU cores at almost 0, about 2.4 GB RAM used, no swap.
(In reply to Mirko Tietgen from comment #2) > I have ~25 test instances on a small server with 4 GB ram. I upgraded to > 16.05.01, so far I can't see anything like that. 3 CPU cores at almost 0, > about 2.4 GB RAM used, no swap. What I mean, is that someone maintaining a 10+ instances server should be able to make de decision to change the enabled-by-default indexer if it was a problem on its deployment infrastructure. But the feature should definitely remain enabled by default for the average user.
Agreed.
Magnus: do you have a custom cronjob for koha-rebuild-zebra that may be running while you also use the inder daemon? I just found that here and if I had bigger data sets, that would probably make the server sad.
(In reply to Mirko Tietgen from comment #5) > Magnus: do you have a custom cronjob for koha-rebuild-zebra that may be > running while you also use the inder daemon? I just found that here and if I > had bigger data sets, that would probably make the server sad. Not custom, but the standard cronjob set up by the packages in /etc/cron.d/koha-common was enabled: */5 * * * * root test -x /usr/sbin/koha-rebuild-zebra && koha-rebuild-zebra -q $(koha-list --enabled) I just tried commenting out this, setting USE_INDEXER_DAEMON="yes" and rebooting, and load, memory usage and swap went through the roof pretty instantly after the reboot. I am fine with WORKSFORME - as I said, a server with this many instances is probably an edge case. But, should we at least remove or comment out this: */5 * * * * root test -x /usr/sbin/koha-rebuild-zebra && koha-rebuild-zebra -q $(koha-list --enabled) from /etc/cron.d/koha-common (debian/koha-common.cron.d in git) now that the daemon is activated as default?
(In reply to Magnus Enger from comment #6) > But, should we at least remove or comment out this: > > */5 * * * * root test -x /usr/sbin/koha-rebuild-zebra && koha-rebuild-zebra > -q $(koha-list --enabled) > > from /etc/cron.d/koha-common (debian/koha-common.cron.d in git) now that the > daemon is activated as default? i agree Magnus... i got caught out by this just last week! :0)
I can do separate bug and patch for that.
Bug 16823 - Comment out koha-rebuild-zebra in debian/koha-common.cron.d
The koha-rebuild-zebra script skips if the daemon is enabled.
I upgraded my production server last night. It is a beefier server with "just" 35 instances. No sign of anything getting stressed out. I'll conclude that the problem with the test server was too many instances, not enough resources and mark this as WORKSFORME. Bug 16823 remains open, though.