[Перевод] Слишком много открытых файлов: лимит Linux, который валит прод в 3 часа ночи

http: Accept error: accept tcp 0.0.0.0:8080: accept4: too many open files; retrying in 5ms

java.io.IOException: Too many open files
      at sun.nio.ch.FileDispatcherImpl.init0(Native Method)

OSError: [Errno 24] Too many open files

• Обычный файл на диске
  
• TCP- или UDP-сокет
  
• Unix-сокет
  
• Канал (pipe)
  
• eventfd, signalfd, timerfd
  
• Экземпляр epoll
  
• Каталог, открытый через opendir
  
• Дескриптор устройства (/dev/null, /dev/random и т. д.)

• 1 файловый дескриптор для сокета прослушивания
  
• 1 файловый дескриптор на каждое принятое соединение
  
• 1 файловый дескриптор на каждое исходящее HTTP-соединение клиента (часто через пул соединений)
  
• Несколько файловых дескрипторов для логов, stdin/stdout/stderr, экземпляров epoll

# Изнутри процесса или shell
ulimit -n           # текущий мягкий лимит
ulimit -Hn          # жёсткий лимит
ulimit -n 65536     # увеличить мягкий лимит (не выше жёсткого

sysctl fs.file-max     # общесистемный максимум (обычно очень большой, например 9_223_372)
sysctl fs.nr_open      # максимальный потолок для одного процесса (обычно 1_048_576)
# Текущее использование по всей системе
cat /proc/sys/fs/file-nr
# Формат вывода: <allocated> <free> <max>
# Например: 4032 0 9223372

cat /sys/fs/cgroup/pids.max     # максимум для этой cgroup
cat /sys/fs/cgroup/pids.current # текущее количество

• kubelet просит контейнерный рантайм — например, containerd или CRI-O — запустить контейнер.
  
• По умолчанию контейнерный рантайм не задаёт процессу ulimit -n. Процесс наследует те значения, которые настроены у самого рантайма.
  
• Значения ulimit по умолчанию зависят от рантайма: containerd, например, не задаёт отдельного переопределения и использует настройки хоста; некоторые дистрибутивы Kubernetes меняют это через конфигурацию kubelet.
  
• Значения по умолчанию на хосте приходят из лимитов unit-файлов systemd (LimitNOFILE). В большинстве современных дистрибутивов Linux они установлены на уровне 1_048_576 или выше.

# Проверка изнутри pod
kubectl exec -it $POD -- sh -c 'ulimit -n; ulimit -Hn'
# Проверка фактического лимита у работающего процесса
PID=$(kubectl exec -it $POD -- pgrep -f myapp | head -1 | tr -d '\r')
kubectl exec -it $POD -- cat /proc/$PID/limits | grep "Max open files"

# /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
 # ... другие параметры ...
 Rlimits = [
   { type = "RLIMIT_NOFILE", hard = 1048576, soft = 1048576 }
 ]
Для CRI-O:
# /etc/crio/crio.conf
[crio.runtime]
default_ulimits = [
   "nofile=1048576:1048576",
]

spec:
  securityContext:
    sysctls:
      - name: fs.file-max
        value: "1048576"

ENTRYPOINT ["/bin/sh", "-c", "ulimit -n 1048576 && exec /usr/local/bin/myapp"]

PID=$(pgrep -f myapp | head -1)
# Какой установлен лимит?
cat /proc/$PID/limits | grep "Max open files"
# Сколько файловых дескрипторов реально используется?
ls /proc/$PID/fd | wc -l

# Группировка файловых дескрипторов по типу
ls -la /proc/$PID/fd | awk '{print $NF}' | grep -oE 'socket|^/.*' | sort | uniq -c | sort -rn | head

# Показать детали сокетов (состояние, удалённые адреса)
ss -tnp | grep "pid=$PID"
# Сокеты в состоянии CLOSE_WAIT часто указывают на утечку
# (удалённая сторона закрыла соединение, а вы — нет)
ss -tnp state close-wait | wc -l

ls -la /proc/$PID/fd | awk '{print $NF}' | grep '^/' | sort | uniq -c | sort -rn | head

• HTTP-клиент без пула соединений

// ПЛОХО: новый клиент на каждый запрос
http.Get(url)   // использует клиент по умолчанию, но создаёт новые соединения
// ЛУЧШЕ: общий клиент с нормально настроенным Transport
var client = &http.Client{
   Transport: &http.Transport{
       MaxIdleConns:        100,
       MaxIdleConnsPerHost: 10,
       IdleConnTimeout:     90 * time.Second,
   },
}

• Реверс прокси вроде NGINX, Envoy или HAProxy, обслуживающий десятки тысяч одновременных соединений
  
• WebSocket-сервер с постоянными соединениями
  
• Сервер базы данных с большим количеством одновременных клиентских подключений
  
• Пограничный CDN-узел

# Соотношение использования файловых дескрипторов для процесса
process_open_fds / process_max_fds > 0.8
# Для pod через cAdvisor / kubelet
container_file_descriptors / container_ulimits_soft{ulimit="open_files"} > 0.8
# Детектор CLOSE_WAIT
# (требуется exporter состояний TCP)
node_netstat_Tcp_CloseWait > 1000

• утечка на уровне приложения (лимит нормальный, но приложение держит файловые дескрипторы, которые должно было закрыть);
  
• или нагрузка, которой действительно не хватает стандартного лимита рантайма (в этом случае нужно исправлять конфигурацию рантайма, а не городить костыли на уровне отдельных pod).

• 2 июня в 20:00. «Введение в Docker: контейнеризация приложений в Linux». Записаться
  
• 18 июня в 20:00. «Основы Bash: пишем простые скрипты для автоматизации в Linux». Записаться