## Description
This systemd unit is installed on every self-hosted Linux install
(copied by `deployment/setup_18.04.sh` / `setup_20.04.sh`) as well as
our own worker hosts, so the memory cap has to be correct across a wide
range of box sizes.
It is currently a fixed `MemoryMax=1.2G`, chosen when workers ran on 2GB
hosts (#12915). On larger hosts that fixed cap sits at a high fraction
of the limit under normal load, so transient spikes hit the hard limit
and the worker is OOM-restarted more often than necessary (each restart
drops the jobs in-flight at that instant).
Switching to `MemoryMax=60%` makes the cap scale with the host's
physical memory instead of being fixed:
- 2GB host: 60% = 1.2G, identical to today (no regression for small
installs)
- 4GB host: 60% = ~2.4G, room to absorb spikes without a premature
restart
- larger hosts scale proportionally
`MemoryHigh=infinity` is unchanged, so the worker is still never
throttled by cgroup reclaim (kept intentionally since #12871 to avoid
reclaim-induced worker stalls). Only the hard cap changes, and only its
scaling.
Fixes https://linear.app/chatwoot/issue/INF-100
## Type of change
- [x] Performance (non-breaking change which improves performance)
## Summary
- Adds `LimitNOFILE=65536` to both web and worker systemd service units
- Fixes recurring `Errno::EMFILE` (Too many open files) errors during
peak traffic after deploys
## Context
Puma workers idle at 720-770 open FDs against the default soft limit of
1024, leaving ~250 FDs of headroom. During deploy-triggered instance
refreshes at peak traffic, concurrent requests exhaust the remaining
FDs, causing EMFILE across all web instances.
3 incidents in March 2026 with escalating event counts. The hard limit
is already 524288, so this just raises the soft limit to a standard
production value.
Self-hosted instances pick this up automatically via `cwctl --upgrade`.
Fixes
https://linear.app/chatwoot/issue/CW-6685/errnoemfile-too-many-open-files-rb-sysopen
- set MemoryHigh to infinity in deployment/chatwoot-worker.1.service so
the worker is throttled only by the existing
MemoryMax hard limit
- prevents cgroup reclaim from slowing Sidekiq under transient spikes
while still keeping the hard stop at 1.5 GB
* chore: update to ruby 3.1.3
* chore: ping docker version to alpine3.16 for nodev16.x
Starting with Node 17, nodejs switched to OpenSSL3. The docker builds
are installing node18.xx with alpine-3.1.3.
From Node.js 17's announcement post:
If you hit an ERR_OSSL_EVP_UNSUPPORTED error in your application
with Node.js 17, it’s likely that your application or a module you’re
using is attempting to use an algorithm or key size which is no longer
allowed by default with OpenSSL 3.0. A new command-line option,
--openssl-legacy-provider, has been added to revert to the legacy
provider as a temporary workaround for these tightened restrictions.
Looks like a webpack issue. This is fixed in webpacl 5+ and we are on
webpack4 at the moment.
Solutions
Upgrade webpack.
Pin nodejs version to be 16.x.x
Use --openssl-legacy-provider as a workaround.
Pin docker version to alpine3.16 branch to have node16.x by default
ref:
https://github.com/chatwoot/chatwoot/pull/5555#issuecomment-1379778532
* chore: update webmock
* chore: fix ruby gem path in dockerfile
* chore: switch to node16 in circleci
* chore: update ruby version in linux installer script
* chore: update ruby version in linux installer script
* chore: fix circleci
* chore: fix circleci
* feat: upgrade node version to 16.x in linux installer
* chore: update systemd files
Co-authored-by: Sojan Jose <sojan@chatwoot.com>
* chore: Update ruby version to 3.0.4
* chore: update ruby version in docker workflow
* chore: update ruby version to 3.1.2
* Upgrade vue-jest to remove deasync
* Revert to 3.0.4 to see if deasync issue is fixed
* fix: script failure if pg/redis not opted in
Co-authored-by: Pranav Raj S <pranav@chatwoot.com>
