TCP: out of memory -- consider tuning tcp_mem
Это сообщение означает, что суммарная память под сокеты превысила предел ядра. Ядро начинает отбрасывать данные и рвать соединения. Признаки со стороны службы — обрывы и таймауты без ошибок в её собственном журнале.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Соединений больше, чем рассчитано
Каждое соединение занимает буферы. Рост числа соединений упирается в общий предел памяти под сокеты.
-
Буферы на соединение заданы слишком большими
Крупные буферы ускоряют одиночную передачу, но при тысячах соединений съедают память быстрее предела.
-
Соединения накапливаются в состоянии ожидания закрытия
Незакрытые соединения держат буферы. Это выглядит как утечка памяти ядра.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Память, занятая сокетами, и число соединений.
cat /proc/net/sockstatСводка по сокетам и состояниям.
ss -sПределы памяти под сокеты.
sysctl net.ipv4.tcp_memРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Каждое соединение занимает буферы. Рост числа соединений упирается в общий предел памяти под сокеты.
- Как проверить
-
Посмотрите число соединений и использование памяти сокетами.
ss -s | head -5 cat /proc/net/sockstat
- Как исправить
- Поднимите предел памяти под сокеты и уменьшите размеры буферов на соединение. Одновременно стоит понять, откуда столько соединений: часто это отсутствие закрытия на стороне клиента.
- Почему происходит
- Крупные буферы ускоряют одиночную передачу, но при тысячах соединений съедают память быстрее предела.
- Как проверить
-
Посмотрите настройки буферов.
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem net.ipv4.tcp_mem
- Как исправить
- Приведите размеры буферов в соответствие с числом соединений. Значения, годные для одного быстрого канала, вредны на тысяче соединений.
- Почему происходит
- Незакрытые соединения держат буферы. Это выглядит как утечка памяти ядра.
- Как проверить
-
Посмотрите распределение состояний.
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn | head
- Как исправить
- Исправьте закрытие соединений в приложении. Сокращать сроки ожидания в ядре — полумера, маскирующая причину.
Пример вывода
Тысячи соединений исчерпали память под буферы. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
kernel: TCP: out of memory -- consider tuning tcp_mem
kernel: net_ratelimit: 214 callbacks suppressed
nginx[1200]: 2026/09/15 16:31:02 [error] 1200#0: *84213 recv() failed (104: Connection reset by peer)Связанные ошибки
- No buffer space available в журнале службы Ошибка 105: нет места в буферах ядра. Разбор для сети и таблиц соседей.
- nf_conntrack: table full, dropping packet Соединения обрываются под нагрузкой: заполнена таблица отслеживания соединений ядра.
- Connection reset by peer в журнале службы Соединение сброшено другой стороной: обрыв клиента, перезапуск сервера, промежуточное устройство.
- Elasticsearch: max virtual memory areas vm.max_map_count is too low Elasticsearch отказывается стартовать из-за заниженного vm.max_map_count. Как поднять значение и закрепить его.
- VFS: file-max limit reached: в системе кончились описатели Общесистемный предел числа открытых файлов исчерпан: службы перестают принимать соединения и открывать файлы.
- kernel: TCP: request_sock … overflow Соединения теряются при наплыве: переполнена очередь ожидающих соединений. Как считать somaxconn и backlog.
- kernel: audit: backlog limit exceeded Очередь аудита переполнена: часть событий теряется, система может замедляться.
- Соединения через сокет-активацию висят и не закрываются Клиенты уходят, соединения остаются: проверка живости соединений не включена.
Где встречается чаще всего
Источники
- Документация ядра: настройки IP
-
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено нагрузочным прогоном с тысячами одновременных соединений.