I’ve just read the following tweet regarding ulimit on AWS ECS, however, what ECS document didn’t tell you in fact is the default 1024 nofile limit in the Amazon ECS-Optimized AMI, and this could apparently restrict your container from making connections as much as you expect.
check /etc/sysconfig/docker in your Amazon ECS-optimized AMI
$ cat /etc/sysconfig/docker
# The max number of open files for the daemon itself, and all
# running containers. The default value of 1048576 mirrors the value
# used by the systemd service unit.
DAEMON_MAXFILES=1048576# Additional startup options for the Docker daemon, for example:
# OPTIONS=” — ip-forward=true — iptables=true”
# By default we limit the number of open files per container
OPTIONS=” — default-ulimit nofile=1024:4096"
Please notice the last line the soft limit of nofile is only 1024 and only possible to raised to 4096, which is far from enough in modern web services with docker.
I’ll recommend update the last line to
OPTIONS=” — default-ulimit nofile=1024000:1024000"And when you run your container with ECS, check the ulimit like this
$ docker exec -ti <container_name> bash
root@59cf54c328e1:/root# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 7950
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024000
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 7950
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimitedThen your docker can now burst itself with higher connections as well as the number of open files.
