Linux максимальное количество сокетов

Максимальное количество сокетов в Linux

Кажется, что сервер ограничен в

32720 сокетов. Я пробовал каждое известное изменение переменной, чтобы поднять этот предел. Но сервер остается ограниченным на 32720 открытых сокетов, даже если все еще есть 4Go свободной памяти и 80% простаивающего процессора.

8 ответов

Если вы имеете дело с openssl и потоками, проверьте ваш /proc/sys/vm/max_map_count и попробуйте поднять его.

В IPV4 уровень TCP имеет 16 бит для порта назначения и 16 бит для порта источника.

Учитывая, что ваш лимит составляет 32 КБ, я ожидаю, что вы на самом деле видите лимит исходящих TCP-соединений, которые вы можете установить. Вы должны быть в состоянии получить максимум 65K сокетов (это будет предел протокола). Это ограничение на общее количество именованных соединений. К счастью, для привязки порта для входящих подключений используется только 1. Но если вы пытаетесь проверить количество подключений с одного компьютера, вы можете иметь только 65 КБ исходящих подключений (для TCP). Чтобы проверить количество входящих соединений, вам понадобится несколько компьютеров.

Примечание: вы можете вызывать сокет (AF_INET. ) с количеством доступных файловых дескрипторов, но вы не можете связать их без увеличения количества доступных портов. Чтобы увеличить диапазон, сделайте это:

echo «1024 65535″> / proc / sys / net / ipv4 / ip_local_port_range (кошка, чтобы увидеть, что у вас есть в настоящее время — по умолчанию от 32768 до 61000)

Возможно, пришло время для нового протокола, подобного TCP, который позволит использовать 32 бита для портов источника и приемника? Но скольким приложениям действительно нужно более 65 тысяч исходящих соединений?

Следующее позволит 100 000 входящих подключений на Linux Mint 16 (64-разрядная версия) (вы должны запустить его как root, чтобы установить ограничения)

Источник

Денис Туляков — блог о том, что мне интересно

Заметки о *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

Источник

Что ограничивает максимальное количество соединений на сервере Linux?

Какой параметр ядра или другие параметры определяют максимальное количество сокетов TCP, которые могут быть открыты на сервере Linux? Каковы компромиссы, позволяющие больше подключений?

Во время нагрузочного тестирования сервера Apache с ab я заметил, что довольно просто максимально увеличить количество открытых соединений на сервере. Если вы отключите опцию ab’s -k, которая разрешает повторное использование соединения, и отправит более 10 000 запросов, то Apache будет обрабатывать первые 11 000 запросов или около того, а затем останавливается на 60 секунд. Просмотр вывода netstat показывает 11 000 соединений в состоянии TIME_WAIT. Видимо, это нормально. Соединения остаются открытыми по умолчанию в течение 60 секунд даже после того, как клиент покончит с ними по соображениям надежности TCP .

Кажется, что это был бы простой способ сделать сервер DoS, и мне интересно, каковы обычные настройки и меры предосторожности для него.

Вот мой тестовый вывод:

Вот команда netstat, которую я запускаю во время теста:

Я наконец -то нашел установку , которая была действительно ограничивающее количество соединений: net.ipv4.netfilter.ip_conntrack_max . Для этого было установлено значение 11 776, и все, что я установил, — это количество запросов, которые я могу обслуживать в своем тесте, прежде чем придется ждать tcp_fin_timeout несколько секунд, чтобы стало доступным больше подключений. conntrack Таблица является то , что ядро использует для отслеживания состояния соединения , так как только она полна, ядро начинает падать пакетов и печать этого в журнале:

Следующим шагом было заставить ядро ​​перерабатывать все эти соединения в TIME_WAIT состоянии, а не отбрасывать пакеты. Я мог добиться этого либо включением, tcp_tw_recycle либо увеличением, ip_conntrack_max чтобы оно превышало количество локальных портов, доступных для соединений ip_local_port_range . Я думаю, что когда ядро ​​выходит из локальных портов, оно начинает перерабатывать соединения. При этом используется больше соединений для отслеживания памяти, но кажется, что это лучшее решение, чем включение, tcp_tw_recycle поскольку документы подразумевают, что это опасно.

С этой конфигурацией я могу работать ab весь день и никогда не заканчиваться соединения:

tcp_max_orphans Установка не оказывает никакого влияния на моих тестах , и я не знаю , почему. Я бы подумал, что он закроет связи в TIME_WAIT штате, когда их будет 8192, но для меня это не так.

Вы действительно хотите посмотреть, что файловая система / proc может предложить вам в этом отношении.

На этой последней странице вам может быть интересно следующее:

• / proc / sys / net / ipv4 / tcp_max_orphans , который контролирует максимальное количество сокетов, удерживаемых системой, не прикрепленной к чему-либо. Увеличение этого значения может потреблять до 64 Кбайт памяти, не подлежащей замене, на каждый потерянный сокет .
• / proc / sys / net / ipv4 / tcp_orphan_retries , который контролирует количество попыток, прежде чем сокет будет потерян и закрыт. На этой странице есть отдельная заметка о веб-серверах, которая вас непосредственно интересует .

Источник

Максимальное количество сокетов в Linux

Кажется, что сервер ограничен в

32720 сокетов . Я пробовал каждое известное изменение переменной, чтобы поднять этот предел. Но сервер остается ограниченным на 32720 открытых сокетов, даже если все еще есть 4Go свободной памяти и 80% простаивающего процессора .

Есть предположения ? (Этот вопрос был задан по поводу переполнения стека, но пока не повезло)

Я нашел то, что ограничивало все:

Спасибо всем, кто ответил!

Вы ищете не в том месте для этого; вы не сталкиваетесь с пользовательским пределом, вы работаете с системным лимитом, который обычно является 15-й степенью 2 в 32-битной системе, как я и предполагаю в вашей системе. Проверьте:

Но вы тоже можете это изменить; на 32-битной машине, которая будет 2 ** 22 в качестве абсолютного верхнего предела, так:

Мне было бы интересно узнать, как вы идете.

Если вы на самом деле пытаетесь определить максимальное количество сокетов, с которыми вы можете открывать соединения, вы можете попробовать посмотреть на cat / proc / sys / net / ipv4 / ip_local_port_range; это диапазон портов, которые ядро ​​будет использовать для исходящих сокетов, и оно имеет различные значения по умолчанию в зависимости от вашего дистрибутива. Установка его на что-то вроде «1024 65535» примерно настолько открыта, насколько это возможно; посмотрим, поможет ли это.

Прошу прощения, если что-то подобное говорится в темах, но у меня нет времени читать их сейчас: — Николайдис Фотис
источник

Источник

ulimit настройка частых проблем в Linux

ulimit — ограничения текущего процесса, например количество одновременно открытых файлов. Справка man limits.conf. Конфигурационный файл находится /etc/security/limits.conf.

Установка лимитов с помощью ulimit может предотвратить катастрофу в ваших системах Linux, но вам нужно предвидеть, где ограничения будут иметь смысл, а где они вызовут проблемы.

Чтобы увидеть ограничения, связанные с вашим логином, используйте команду ulimit -a. Если вы используете учетную запись обычного пользователя, вы, скорее всего, увидите что-то вроде этого:

Изменять лимиты вы можете в конфигурационном файле, обычно /etc/security/limits.conf, или при помощи командной строки. Помните что при изменении лимитов через командную строку, ваши изменения не сохранятся после перезагрузки ОС. Например для изменения максимального количества пользовательских процессов (max user processes) используйте ключ u (из листинга вывода команды ulimit -a):

В limits.conf для каждого пользователя или группы можно задать ограничения. Каждое ограничение задается в отдельной строке. Например для группы developers настроим ограничения пределов открытия файлов, где hard жестко задали количество, а при достижении нижнего предела значения soft пользователи будут получать предупреждения):

Too many open files

Нужно увеличить ограничение на количество одновременно открытых файлов в файле limits.conf.

ulimit размеры файлов

В основном при работе в системе UNIX мы считаем, что ее ресурсы безграничны. Например, мы не заботимся о том, что созданный файл получится «слишком большим», а это не так уж редко в персональных компьютерах на гибких дисках. Если же мы занимаемся сопровождением и администрированием системы UNIX, то мы должны быть готовы иметь дело с ситуациями, когда превышаются различные предельные значения системы. Всегда лучше исследовать эти вопросы заранее в некритичных ситуациях, поэтому давайте рассмотрим пределы размеров файлов и их смысл.

Некоторые параметры «зашиты» в ядро системы при ее генерации. Одним из таких значений является максимальный размер файла. Он определяет наибольшее число блоков, которые может занимать файл. Этот параметр тесно связан с принятым в UNIX методом использования индексных дескрипторов файла (inodes). Это наборы указателей, среди которых первые десять указывают на блоки данных, следующий указывает на другую таблицу, следующий — на таблицу, указывающую на таблицу и т.д.

Имеется еще одно ограничение размера файла, которое определено для каждого пользователя во время работы в системе — число ulimit (user limit — пользовательский предел). Это значение устанавливается в момент вашей регистрации в системе и представляет собой число блоков по 512 байт, которые вы можете записать в любой заданный файл. В shell’е имеется команда ulimit, которая при ее вызове без аргументов выводит это число. Эта же команда позволяет вам уменьшить ваше значение ulimit. Только суперпользователь (root) может УВЕЛИЧИТЬ значения ulimit.

Побочным эффектом уменьшения значения ulimit является то, что вы не можете снова увеличить его до регистрационного значения. Значение ulimit остается таким же на все время работы вашего shell, поэтому для восстановления регистрационного значения вам необходимо выйти из системы, а затем снова зарегистрироваться.

Еще одним интересным моментом является то, что если вы установите ваше значение ulimit равным 0, вы не сможете создать никакие файлы! Максимально допустимым размером файла в данном случае является нулевой, поэтому никакой файл не может быть создан. Это представляется достаточно резонным, однако существуют такие ситуации, когда файл нулевого размера МОЖЕТ существовать. Опять же, для восстановления вашего обычного значения ulimit необходимо выйти из системы, а затем снова зарегистрироваться.

Как отмечалось ранее, увеличить значение ulimit может только суперпользователь. Эта процедура довольно проста. Сначала нужно увеличить значение ulimit командой ulimit, а затем запустить shell. Этот новый shell имеет новое значение ulimit. Если мы хотим, чтобы система загружалась с shell, имеющим большее значение ulimit, мы можем установить программу в inittab (таблице инициализации системы), чтобы эта операция выполнялась автоматически.

ulimit количество открытых сокетов

Ограничение на количество одновременно открытых сокетов. Обычно, большая часть nix систем ограничивает количество сокетов до 1024. Эти настройки можно изменить добавив в /etc/security/limits.conf следующие строчки:

Также можно установить лимит вручную, через:

Источник