Количество открытых сокетов linux
Обновлено: 06.07.2024
Какой параметр ядра или другие параметры определяют максимальное количество сокетов TCP, которые могут быть открыты на сервере Linux? Каковы компромиссы, позволяющие больше подключений?
Во время нагрузочного тестирования сервера Apache с ab я заметил, что довольно просто максимально увеличить количество открытых соединений на сервере. Если вы отключите опцию ab's -k, которая разрешает повторное использование соединения, и отправит более 10 000 запросов, то Apache будет обрабатывать первые 11 000 запросов или около того, а затем останавливается на 60 секунд. Просмотр вывода netstat показывает 11 000 соединений в состоянии TIME_WAIT. Видимо, это нормально. Соединения остаются открытыми по умолчанию в течение 60 секунд даже после того, как клиент покончит с ними по соображениям надежности TCP .
Кажется, что это был бы простой способ сделать сервер DoS, и мне интересно, каковы обычные настройки и меры предосторожности для него.
Вот мой тестовый вывод:
Вот команда netstat, которую я запускаю во время теста:
Следующим шагом было заставить ядро перерабатывать все эти соединения в TIME_WAIT состоянии, а не отбрасывать пакеты. Я мог добиться этого либо включением, tcp_tw_recycle либо увеличением, ip_conntrack_max чтобы оно превышало количество локальных портов, доступных для соединений ip_local_port_range . Я думаю, что когда ядро выходит из локальных портов, оно начинает перерабатывать соединения. При этом используется больше соединений для отслеживания памяти, но кажется, что это лучшее решение, чем включение, tcp_tw_recycle поскольку документы подразумевают, что это опасно.
С этой конфигурацией я могу работать ab весь день и никогда не заканчиваться соединения:
tcp_max_orphans Установка не оказывает никакого влияния на моих тестах , и я не знаю , почему. Я бы подумал, что он закроет связи в TIME_WAIT штате, когда их будет 8192, но для меня это не так.
@Codevalley Это может зависеть от системы, но на сервере Ubuntu они находятся в /etc/sysctl.confВы действительно хотите посмотреть, что файловая система / proc может предложить вам в этом отношении.
На этой последней странице вам может быть интересно следующее:
-
, который контролирует максимальное количество сокетов, удерживаемых системой, не прикрепленной к чему-либо. Увеличение этого значения может потреблять до 64 Кбайт памяти, не подлежащей замене, на каждый потерянный сокет . , который контролирует количество попыток, прежде чем сокет будет потерян и закрыт. На этой странице есть отдельная заметка о веб-серверах, которая вас непосредственно интересует .
Я не думаю, что есть возможность настроить это напрямую. Это подпадает под категорию настройки TCP / IP. Чтобы узнать, что вы можете настроить, попробуйте 'man 7 tcp'. Sysctl ('man 8 sysctl') используется для их установки. 'sysctl -a | grep tcp 'покажет вам большую часть того, что вы можете настроить, но я не уверен, покажет ли это все из них. Кроме того, если это не изменилось, сокеты TCP / IP открываются как файловые дескрипторы. Так что этот и следующий раздел в этой ссылке может быть тем, что вы ищете.
Попробуйте установить следующее, а также установить tcp_fin_timeout. Это должно закрыть TIME_WAIT быстрее.
@Henk Я думаю tcp_tw_recycle , это потенциально опасно. tcp_tw_reuse безопаснее, и я не вижу смысла использовать их одновременно.Стандартный apache (1) использовался как предопределенный, чтобы поддерживать только 250 одновременных подключений - если вам нужно больше, нужно изменить один заголовочный файл, чтобы разрешить больше одновременных сеансов. Я не знаю, так ли это до сих пор с Apache 2.
Кроме того, вам нужно добавить опцию, позволяющую загружать больше открытых файловых дескрипторов для учетной записи, на которой работает Apache - на что предыдущие комментарии не смогли указать.
Обратите внимание на настройки своего рабочего и то, какие тайм-ауты активности активности у вас есть внутри самого Apache, сколько резервных серверов у вас работает одновременно и как быстро убиваются эти дополнительные процессы.
Вы можете уменьшить время, проведенное в состоянии TIME_WAIT (установите net.ipv4.tcp_fin_timeout). Вы можете заменить Apache на YAWS или nginx или что-то подобное.
Компромиссы между большим количеством подключений обычно включают использование памяти, и, если у вас есть процесс разветвления, множество дочерних процессов, которые затопляют ваш процессор.
tcp_fin_timeout предназначен не для установки срока действия TIME-WAIT, который нельзя изменить вне перестроения ядра, а для FIN, как видно из названия.Абсолютное количество сокетов, которые могут быть открыты на одном IP-адресе, равно 2 ^ 16 и определяется TCP / UDP, а не ядром.
Нет, это не так. Вы можете открыть больше, так как локальный порт не должен быть уникальным, если удаленные адреса разные. Более того, OP указывает на сервер, и вы можете иметь> 1 адрес на сервер.Заметки о *nix системах о железках о DB и даже о windows, возможно, ещё что то .
2015-02-06
Количество открытых файлов, сокетов
Достаточно часто возникают ошибки связанные с тем, что превышен лимит открытых файлов или общего количества файлов.
Такие лимиты бывают нескольких видов:
- накладываемые ядром
- накладываемые PAM
- накладываются самими программами
1) Ограничения накладываемые ядром:
Просмотр текущего значения максимального количества дескрипторов открытых файлов:
cat /proc/sys/fs/file-max
Может быть легко изменено "на лету" (останется до перезагрузки компьютера):
echo "104854" > /proc/sys/fs/file-max
Если хочется чтобы новое значение использовалось постоянно, его необходимо внести в /etc/sysclt.conf:
fs.file-max=104854
Посмотреть текущее количество дескрипторов открытых файлов:
cat /proc/sys/fs/file-nr
3391 969 104854
| | |
| | |
| | максимальное число открытых файловых дескрипторов
| число занятых(выделенных), но не используемых дескрпиторов
общее число занятых дескрипторов
2) Ограничения накладываемые PAM
Если на машине используются PAM (подключаемые модули авторизации), можно столкнуться с ограничениями
на количество открытых файлов для пользователя (bind, mysql).
Ограничения задаются в /etc/security/limits.conf.
Файл хорошо документирован, есть man-страница limits.conf (5).
Есть 2 типа ограничений:
soft и hard мягкий и жесткий лимита соответственно. soft может быть изменен в самой программе. hard может быть изменен только суперпользователем. Ограничивать можно"
a. пользователя - <тип_ограничения> <ограничеваемый параметр> <значение>
б. группу - @ <тип_ограничения> <ограничеваемый параметр> <значение>
в. всех - * <тип_ограничения> <ограничеваемый параметр> <значение>
Общее количество открытых файлов можно также можно посмотреть с помощью комманды lsof:
lsof | wc -l
Эта же комманда позволяет посмотреть файлы открытые конкретными приложениями:
lsof | grep 29384 (где 29384 - это PID необходимого приложения).
Менее ресурсоёмкая команда, для этой же цели:
ls -l /proc/29384/fd/
Для работы с Unix-сокетами также требуется получение дескриптора файла, поэтому приложения работающие с UNIX-сокетами могут также попадать под ограничение на количество файлов. Для просмотра сокетов можно использовать Perl-скрипт: socklist (8), который входит в состав пакета procinfo (название пакета в Debian, RHEL) или комманду netstat (8): netstat -uxp
Команда ss — это инструмент, который используется для отображения информации о сетевых сокетах в системе Linux. Инструмент отображает более подробную информацию, чем команда netstat, которая используется для отображения активных соединений сокетов.
В этом руководстве мы подробно рассмотрим, как можно использовать команду ss для отображения различной информации о сетевых подключения (сокетах) в Linux.
1. Перечисление всех соединений
Базовая команда ss без каких-либо опций просто выводит список всех соединений независимо от состояния, в котором они находятся.
Если ни одна из опций не используется, ss отображает список открытых не слушающих сокетов (например, TCP/UNIX/UDP), которые установили соединение.
2. Список слушающих и не слушающих портов
Вы можете получить список как слушающих, так и не слушающих портов, используя опцию -a, как показано ниже.
3. Список прослушивающих сокетов
Чтобы отобразить только сокеты прослушивания, используйте флаг -l:
4. Список всех TCP соединений
Чтобы отобразить все соединения TCP, используйте параметр -t:
5. Список всех слушающих TCP соединения
Для просмотра всех слушающих TCP-сокетов используйте комбинацию -lt:
6. Список всех UDP соединений
Для просмотра всех сокетов с UDP соединениями используйте параметр -ua:
7. Список всех слушающих UDP соединений
Для просмотра списка подключений UDP используйте параметр -lu.
8. Отображение у сокетов PID (идентификаторов процессов)
Для отображения идентификаторов процессов, связанных с соединениями сокетов, используйте флаг -p:
9. Показать сводную статистику
Чтобы вывести сводную статистику, используйте опцию -s.
10. Показать сокеты IPv4 и IPv6
Если вам интересны соединения через сокет IPv4, используйте опцию -4.
Чтобы отобразить соединения IPv6, используйте параметр -6.
11. Фильтр соединений по номеру порта
Команда ss также позволяет фильтровать номер порта сокета или номер адреса. Например, для отображения всех соединений сокетов с портом назначения или исходным портом ssh выполните команду.
12. Вывод номеров портов в числовом формате, а не имени в ss
По умолчанию команда ss показывает имена портов, чтобы выводились порты в виде чисел, используйте опцию -n:
13. Поиск открытых портов на Linux
Следующая команда покажет все прослушиваемые порты для TCP и UDP соединений в виде цифровых значений:
14. Поиск программ, которые прослушивают порты на Linux
Если добавить ключ -p, то программа дополнительно покажет процессы, использующие сокет:
300. Сервер написан на Perl. Методика тестирования следующая: клиент (Perl) создает 20 процессов (fork), каждый из которых открывает 50 соединений с сервером. И клиент и сервер запускались на одном компьютере.
Каким образом можно увеличить сабж?
P.S. ОС не имеет значения. Приветствуются любые соображения.
Просто ради интереса завел сервер на Erlang и клиент на Python. Получилось 1020 соеденений на 1 debian linux box. Все настройки TCP/IP были по умолчанию.
mldonkey у меня меньше 500 открытых соединений никогда не держит. Все по дефолту.
Есть такая командачка "ulimit" - с помощью нее можно все зделать (тока пускать под рутом надо)
добавлю свое ню
есть такой раздел /proc
очень полезно читать документацию на ядро
[12:37:45]$ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) 1048576
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 7237
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 262144
cpu time (seconds, -t) unlimited
max user processes (-u) 3618
virtual memory (kbytes, -v) unlimited
Хм-м-м, даже не знаю чего и сказать 7237 это никак не 300 !!
Мыслей 2:
1. Заканчивается лимит системных ресурсов - смотри /proc/sys/fs/file-max, посомтреть сколько сейчас открыто дескрипторов можно гдето так: "echo /proc/*/fd/* | wc -w" (естественно под рутом).
2. Скорее всего у тебя теряются дескрипторы, узнай сколько твоя прога их юзает: "ls /proc/<pid>/fd|wc -w"
Попробовал я на линуксе, получил
510 соединений. После этого клиент стал получать "Connection refused".
после запуска сервера:
echo /proc/*/fd/* | wc -w
715
после запуска клиента:
echo /proc/*/fd/* | wc -w
2625
сам клиент "потребляет" 63 дескриптора. Вобщем, какая-то странная арифметика получается. Это при том, что ulimit показал:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 4086
virtual memory (kbytes, -v) unlimited
Читайте также: