Package: apache2
Version: 2.4.66-5
Severity: normal
Dear Maintainer,
When transferring large files (obvious with 48 TB, can be seen with 70
GB) with apache2 as server leads to that apache2 thread using memory at
a rate of at least 0.5% of what has been transferred so far. Can be seen
with 'top' sorted on memory size, and in systemctl status apache2 .
This only happens with https, http is fine. Has been confirmed to occur
with trixie and testing (with just apache2 being the testing version)
and a cloud VPS running trixie.
curl is used as a test client, outputting to /dev/null. On ^C, the
memory footprint of the apache2 thread shrinks by around 5 GB per top
refresh and then settles at the normal (low) level.
File transfer via reverse proxy to another server (as in, apache2 only
handles the SSL) does not increase memory footprint of the apache2 thread.
The machine will suffer memory starvation if the file download
continues, i.e, 64GB RAM test machine stalls at around 980 GB transferred.
The only mitigation found is to add a systemd limit in apache2.service,
killing the thread and the file transfer.
Multiple downloads of the same file are served by different apache2
threads and each thread increases in memory footprint.
Many apache2 options and modules have been tested, reducing the
configuration down to the most minimal I could manage while keeping SSL
and the bug still occurs.
This bug is not seen on Debian 10 machines. I've no SSL enabled Debian
11 or 12 machines test machines to hand.
Can you confirm this?
-- System Information:
Debian Release: 13.1
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.48 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
