You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I haven't seen this discussed yet so I thought I would post my findings here. For me at least, it is really driving my install choices.
The default for SFTPGO is to use docker in bridged mode which is also the norm for docker in general. However, every port forward in this mode has a memory cost on the host, which whilst small when we consider that SFTPGO routinely uses over 100 ports ( e.g. FTP ACTIVE MODE) this starts to add up.
Here are some basic top line figures using a clean build single core 1GB VPS Debian 13 Trixie with docker to demonstrate my point:
Scenario 1 (No containers running)
total used free shared buff/cache available
Mem: 984644 401012 132792 124 599184 583632
Swap: 2457596 46016 2411580
Scenario 2 (SFTPGO in host networking mode: 21,22, 50000-50100 total 102 ports)
total used free shared buff/cache available
Mem: 984644 391368 139256 200 602440 593276
Swap: 2457596 46016 2411580
Scenario 3 (SFTPGO in bridge networking mode : 21,22, 50000-50010 total 12 ports)
total used free shared buff/cache available
Mem: 984644 510300 86524 208 536068 474344
Swap: 2457596 46016 2411580
Scenario 4 (SFTP in bridge networking mode: 21,22, 50000-50100 total 102 ports)
total used free shared buff/cache available
Mem: 984644 717512 76336 204 338184 267132
Swap: 2457596 46016 2411580
the container itself is extremely efficient
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
dab500a59210 sftpgo 0.00% 27.31MiB / 961.6MiB 2.84% 0B / 0B 5.34MB / 0B 6
So the docker port mapping is increasing the host memory footprint alone by 83% (~326MB) when compared to the same container deployed in host mode.
Port mapping the defaults increases the container memory footprint by a whopping 12X becoming very memory inefficient.
I would suggest you reconsider the deprecation Docker: remove CAP_NET_BIND_SERVICE from the sftpgo binary. introduced in v2.5.2.
This depreciation essentially forces between the choice of running the container as root or in memory hungry bridged mode, if you require to use internet domain privileged ports.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I haven't seen this discussed yet so I thought I would post my findings here. For me at least, it is really driving my install choices.
The default for SFTPGO is to use docker in bridged mode which is also the norm for docker in general. However, every port forward in this mode has a memory cost on the host, which whilst small when we consider that SFTPGO routinely uses over 100 ports ( e.g. FTP ACTIVE MODE) this starts to add up.
Here are some basic top line figures using a clean build single core 1GB VPS Debian 13 Trixie with docker to demonstrate my point:
Scenario 1 (No containers running)
Scenario 2 (SFTPGO in host networking mode: 21,22, 50000-50100 total 102 ports)
Scenario 3 (SFTPGO in bridge networking mode : 21,22, 50000-50010 total 12 ports)
Scenario 4 (SFTP in bridge networking mode: 21,22, 50000-50100 total 102 ports)
the container itself is extremely efficient
So the docker port mapping is increasing the host memory footprint alone by 83% (~326MB) when compared to the same container deployed in host mode.
Port mapping the defaults increases the container memory footprint by a whopping 12X becoming very memory inefficient.
I would suggest you reconsider the deprecation
Docker: remove CAP_NET_BIND_SERVICE from the sftpgo binary.
introduced in v2.5.2.This depreciation essentially forces between the choice of running the container as root or in memory hungry bridged mode, if you require to use internet domain privileged ports.
Beta Was this translation helpful? Give feedback.
All reactions