Снять ограничение на размер стека на linux
Обновлено: 06.07.2024
Я хотел бы попробовать некоторые шелл-коды и отключить защиту Linux.
Я знаю, что могу компилировать, используя флаги, но я знаю, что существует другой способ отключить эти защиты в общем, я просто не могу вспомнить. Вы можете помочь мне?
Защита стека осуществляется компилятором (добавьте некоторые дополнительные данные в стек и спрячьте некоторые при вызове, проверьте работоспособность при возврате). Не могу отключить это без перекомпиляции. Это часть дела, правда .
ASLR требует, чтобы ОС делала это во время выполнения. Биты NX также требуют системной поддержки. Какую часть нельзя отключить во время выполнения?Чтобы расширить то, что сказал vonbrand (правильно, +1), есть две части защиты стека Linux.
Стек канареек
Канарские стеки - это обязательная для компилятора функция, на которую ссылается vonbrand. Они не могут быть отключены без перекомпиляции.
Чтобы доказать это себе и посмотреть, как они работают, возьмите следующий код:
Теперь скомпилируйте this ( gcc -fstack-protector -masm=intel -S test.c ) во что-то gnu, которое будет радо собрать и прочитать вывод. Важным моментом является то, что при выходе из mybadfunction функции есть небольшой фрагмент кода:
Как вы можете догадаться, это берет cookie из стека [ebp-12] и сравнивает его со значением в gs:20 . Не совпадает? Затем он вызывает функцию __stack_chk_fail в glibc, которая тут же убивает вашу программу.
Есть способы обойти это с точки зрения написания эксплойтов, но самый простой способ с точки зрения создания тестового примера шелл-кода - это скомпилировать вашу программу -fno-stack-protector .
Неисполняемые страницы
Есть несколько других соображений о современных системах Linux. Если вы берете обычную заглушку тестирования шелл-кода:
современный GCC / Linux будет отображать .rodata раздел PE-файла только для чтения без каких-либо разрешений на выполнение. Вы должны отключить это, что можно сделать с помощью примера кода из этого поста в блоге . Основная идея: вы используете mprotect для добавления необходимых разрешений на страницы, на которых находятся данные шеллкода.
Неисполняемые стеки
Если вы собираетесь протестировать традиционный сценарий эксплойта, например мой неверный код выше, с вашим шелл-кодом, то вам также необходимо убедиться, что стек является исполняемым для простых случаев. Формат файла PE содержит поле для определения, является ли стек исполняемым - вы можете запросить и контролировать это с помощью execstack . Чтобы включить исполняемый стек, запустите
Это может быть сделано на произвольных программах без необходимости перекомпиляции, но не будет автоматически отключать канареек стека, так как они запекаются при компиляции.
Добавленный бонус: aslr:
Чтобы отключить это echo 0 > /proc/sys/kernel/randomize_va_space .
Ты только что рассказал кому-нибудь, как эксплуатировать моего драгоценного пингвина?
Нет. Любой эксплойт должен работать с канареками стека (очень нетривиально) и либо находить программу с execstack set, либо устанавливать ее (то есть она может выполнять произвольные команды в любом случае), либо использовать более сложные методы, такие как return to libc / return. ориентированное программирование.
С помощью этих опций вы можете отключить некоторые средства защиты (обнаружение разрушения стека и сделать исполняемый стек).
Вы также можете отключить ASLR (рандомизацию размещения адресного пространства) с помощью Bash с помощью команды:
ulimit -a говорит что размер стека процесса не может превышать 8ми мегабайт.
Есть ли способы увеличить размер стека процесса доступные из под контекста обычного пользователя (без всяких настроек через su, и тем более без перекомпиляции чего-либо системного)
В виндоуз 64битной, по умолчанию размер стека 1мб, но при потребности (если прога скомпилирована с соответствующим ключом) - то можно нарастить стековое пространство до 1гигабайта
Есть ли что-то похожее в linux? (да, понятное дело что то что не влазит - можно в кучу перенести, но код не мой, а задачу хотелось бы решить с минимумом правок оригинального кода, который в винде работает, а в лине переполняет стек)
Не работает такое на Linux. Как я понял, этот ключ работает на Windows.
Но зато перечитал ключи для gcc и нашел -fsplit-stack
С ним стек стал больше. 1 гигабайт по крайней мере работает. Только для linux.
fsb4000 ★★★★★ ( 29.06.18 13:42:04 )Последнее исправление: fsb4000 29.06.18 13:51:20 (всего исправлений: 1)
ulimit -s unlimited
На openvz каком-нить ругнется - мол, хер вам, жрите 8 Мбайт.
Просто интересно - это кто-то пишет ПО, которое на размер стэка завязано используя какие-то особые техники оптимизации и построения архитектуры ПО?
Видимо, всякие go поделия легко могут на такое дело ругаться.
Видал я, как тип в процессинге транзакций финансовых, свои потоки со скуки запилил. Я думал, вдруг это какой то полезный тренд?
Да и в go наверное всё же как во всяких доморощенных корутинах, весь стек на куче, со своим планировщиком в юзерспейсе не?
да нет, я взялся пофрилансить, и портирую код, который замечательно работает в винде под линукс.
И вот в этом коде за раз (в конструкторе объекта) выделяется на стеке три массива длинной в WCHAR_MAX (WCHAR_MAX == 2147483647). При этом два из массивов состоят из элементов длинной 4 байта, а один - состоит из элементов, где каждый имеет размер в 16 байт.
Прикол в том что на винде это работает, и даже память не жрет, что в стековом варианте, что я когда в кучу перенес хранение этих массивов (судя по двум разным системным мониторам (один такой современный, стандартный виндовый, другой такой больше легаси-но функциональное легаси).
Причем перенеся в кучу в линуксе всеравно на таких объёмных массивах крошится в сегфолт. Что пробовал я ключи компиляции которые подсказали выше, что задавать unlim на стек через
В итоге я просто от фонаря поделил WCHAR_MAX на 8 и этого уже хватило и для того что бы не падало и для работы алгоритма на тестовом множестве данных.
Алгоритмика там сложная (для меня) вряд ли буду вникать, нужны ли им такие объемы или нет, просто на днях сделаю туда класс обёртку над массивами, чтобы внешне класс был как обычный массив, но выход за индексы выделял бы новую память - т.е. чисто по потребности выделял а не сразу огромную кучу.
Устранение предупреждения в 1С:Битрикс - "Замечание. Возможны проблемы в работе с длинными строками из-за системных ограничений".
Устранение предупреждения БУС, размер стека и pcre.recursion_limit
Довольно часто в результатах штатной проверки системы можно увидеть такое предупреждение:
К сожалению текст ошибки мало информативен, для web разработчика:
Для устранения, необходимо выполнить следующие действия.
Первое, что нужно сделать - это найти файл "/etc/php.d/bitrixenv.ini" - он содержит основные настройки php для веб окружения и заменить в нем "pcre.recursion_limit = 14000" на "pcre.recursion_limit = 100000".
В секции "Change default values of important constants":
Проведем замену "pcre.recursion_limit = 14000" на "pcre.recursion_limit = 100000":
Так же потребуется модифицировать скрипт запуска сервера HTTP Apache "/etc/rc.d/init.d/httpd". В файле необходимо модифицировать функцию запуска веб-сервера "start()", добавив в нее еще одну строку (ulimit -s unlimited).
После проделанных действий необходимо перезапустить web сервер:
Если все сделано верно, можно повторно запустить штатную проверку системы и увидеть результат:
Размер стека и pcre.recursion_limit в CentOS 7
В CentOS 7 больше не используется init.d и выше описанные действия справедливы только для CentOS 6 и ниже.
Для CentOS 7, последовательность действий практически такая же, за исключением, правки файла "/etc/rc.d/init.d/httpd", теперь потребуется создать новую директорию:
После успешного создания директории, в ней потребуется создать файл с произвольным именем, но с обязательны окончанием .conf:
После успешного создания файла, в него потребуется добавить две строки:
После успешного добавления строк и файла, потребуется перезагрузить "демонов" для этого необходимо выполнить команды:
Приглашаем всех желающих посетить открытый демо-урок «Практикум по написанию Ansible роли». На этом вебинаре участники вместе с экспертом будут писать, тестировать и отлаживать ansible роли. Это важно для тех, кто хочет автоматизировать настройку инфраструктуры, поскольку это один из инструментов, который это позволяет сделать. Сетевой стек — одна из самых запутанных вещей в Linux. И не только из-за сложности некоторых концепций и терминов, но и из-за изменения смысла некоторых параметров в разных версиях ядра. В этой статье приведена информация для ядра 2.2 и выше, а также, там где это возможно, указано различие между версиями вплоть до 5.5.
Очередь приема и netdev_max_backlog
Очередь ожидающих запросов на соединение и tcp_max_syn_backlog
Соединения создаются для SYN-пакетов из очереди приема и перемещаются в очередь ожидания (SYN Backlog Queue). Также соединение помечается как "SYN_RECV" и клиенту отправляется "SYN+ACK". Эти соединения не перемещаются в очередь установленных соединений ожидающих обработки accept() (accept queue) до тех пор, пока не будет получен и обработан соответствующий ACK. Максимальное количество соединений в этой очереди устанавливается параметром net.ipv4.tcp_max_syn_backlog .
Для просмотра очереди приема используйте команду netstat . На правильно настроенном сервере при нормальной нагрузке значение не должно быть больше 1. При большой нагрузке значение должно быть меньше размера очереди ожидания (SYN Backlog):
Если в состоянии "SYN_RECV" находятся много соединений, то можно также подстроить продолжительность нахождения SYN-пакета в этой очереди.
SYN Cookie
Повторы SYN+ACK
Что происходит, если SYN+ACK отправлен, но ответа ACK нет? В этом случае сетевой стек сервера повторит отправку SYN+ACK. Задержка между попытками вычисляется таким образом, чтобы обеспечить восстановление сервера. Если сервер получает SYN и отправляет SYN+ACK, но не получает ACK, то тайм-аут повторной передачи вычисляется по экспоненте (Exponental Backoff) и, следовательно, зависит от количества повторных попыток. Количество повторных попыток отправки SYN+ACK задается параметром ядра net.ipv4.tcp_synack_retries (по умолчанию равно 5). Повторные попытки будут через следующие интервалы: 1с, 3с, 7с, 15с, 31с. При шести попытках последняя будет примерно через 63 секунды после первой. Это позволяет удержать SYN-пакет в очереди ожидания более 60 секунд до истечения времени ожидания пакета. Если очередь SYN backlog мала, то не требуется большого количества соединений, чтобы возникла ситуация, когда полуоткрытые соединения никогда не завершатся и тогда никакие соединения не смогут быть установлены. Установите количество повторных попыток SYN+ACK равным 0 или 1, чтобы избежать такого поведения на высоконагруженных серверах.
Повторы SYN
Несмотря на то что повторные SYN-пакеты отправляются клиентом во время ожидания SYN+ACK, они могут влиять и на высоконагруженные серверы, работающие с прокси-соединениями. Например, сервер nginx, устанавливающий несколько десятков прокси-соединений к бэкенд-серверу, из-за всплесков трафика может на некоторое время перегрузить сетевой стек, а повторные попытки создадут дополнительную нагрузку на бэкэнд как в очереди приема, так и в очереди ожидания (SYN backlog). Это, в свою очередь, может повлиять на клиентские соединения. Повторные попытки SYN контролируются параметром net.ipv4.tcp_syn_retries (по умолчанию 5 или 6 в зависимости от дистрибутива). Ограничьте количество повторных попыток SYN до 0 или 1, чтобы не было долгих повторных попыток отправки в течение 63–130 с.
Более подробно о проблемах с клиентскими соединениями при обратном прокси-сервере читайте в статье Linux Kernel Tuning for High Performance Networking: Ephemeral Ports.
Очередь установленных соединений ожидающих принятия (accept queue) и somaxconn
Очередь запросов на соединение создает приложение, используя listen() и указывая размер очереди в параметре "backlog". Начиная с ядра 2.2 поведение этого параметра изменилось с максимального количества неоконченных запросов на соединение, которое может удерживать сокет, на максимальное количество полностью установленных соединений, ожидающих, пока они будут приняты. Как описано выше, максимальное количество неоконченных запросов на соединение теперь задается с помощью параметра ядра net.ipv4.tcp_max_syn_backlog .
somaxconn и параметр backlog в listen()
Хотя за размер очереди для каждого слушателя отвечает приложение, есть ограничение на количество соединений, которые могут находиться в очереди. Размером очереди управляют два параметра: 1) параметр backlog в функции listen() и 2) параметр ядра net.core.somaxconn , задающий максимальный размер очереди.
Значения по умолчанию для очереди
Значение по умолчанию для net.core.somaxconn берется из константы SOMAXCONN, которая в ядрах Linux вплоть до версии 5.3 имеет значение 128, но в 5.4 она была увеличена до 4096. Однако, на момент написания этой статьи, ядро 5.4 еще не очень распространено, поэтому в большинстве систем значение будет 128, если вы не модифицировали net.core.somaxconn.
Часто приложения для размера очереди по умолчанию используют константу SOMAXCONN, если этот размер не задается в конфигурации приложения. Хотя некоторые приложения устанавливают и свои значения по умолчанию. Например, в nginx размер очереди равен 511, который автоматически усекается до 128 в ядрах Linux до версии 5.3.
Изменение размера очереди
Многие приложения позволяют указывать размер очереди в конфигурации, указывая значение параметра backlog для listen() . Если приложение вызывает listen() со значением backlog , превышающим net.core.somaxconn, то размер очереди будет автоматически усечен до значения SOMAXCONN.
Потоки
Соединения и файловые дескрипторы
Системные ограничения
Любое сокетное соединение использует файловый дескриптор. Максимальное количество дескрипторов, которые могут быть созданы в системе, задается параметром ядра fs.file-max. Посмотреть количество используемых дескрипторов можно следующим образом:
Пользовательские ограничения
Помимо системного ограничения количества файловых дескрипторов, у каждого пользователя есть свои лимиты. Они настраиваются в системном файле limits.conf (nofile) или, при запуске процесса под управлением systemd, в unit-файле systemd (LimitNOFILE). Чтобы увидеть значение по умолчанию запустите:
Для systemd (на примере nginx):
Настройка
Для настройки системных ограничений установите параметр ядра fs.max-file в максимальное количество файловых дескрипторов, которое может быть в системе (с учетом некоторого буфера). Например:
Для настройки пользовательского лимита установите достаточно большое значение, чтобы хватило сокетам и файловым дескрипторам рабочих процессов (также с некоторым буфером). Пользовательские ограничения устанавливаются в /etc/security/limits.conf, в conf-файле в /etc/security/limits.d/ или в unit-файле systemd. Например:
Количество worker'ов
Аналогично файловым дескрипторам, количество worker'ов или потоков, которые может создать процесс, ограничено как на уровне ядра, так и на уровне пользователя.
Системные ограничения
Процессы могут создавать рабочие потоки. Максимальное количество потоков, которые могут быть созданы, задается параметром ядра kernel.threads-max . Для просмотра максимального и текущего количества потоков, выполняющихся в системе, запустите следующее:
Пользовательские ограничения
Есть свои ограничения и у каждого пользовательского процесса. Это также настраивается с помощью файла limits.conf (nproc) или unit-файла systemd (LimitNPROC). Для просмотра максимального количества потоков, которое может создать пользователь запустите:
Для systemd (на примере nginx):
Настройка
Как и в случае с nofile , ограничения для пользователей ( nproc ) устанавливаются в /etc/security/limits.conf, в conf-файле в /etc/security/limits.d/ или в unit-файле systemd. Пример с nproc и nofile :
Обратный прокси и TIME_WAIT
При большом всплеске трафика прокси-соединения, застрявшие в "TIME_WAIT", суммарно могут потреблять много ресурсов при закрытии соединения. Это состояние говорит, что клиент получил последний FIN-пакет от сервера (или вышестоящего worker'а) и находится в ожидании для корректной обработки пакетов. Время нахождения соединения в состоянии "TIME_WAIT" по умолчанию составляет 2 x MSL (Maximum Segment Length — максимальная длина сегмента), что составляет 2 x 60 с. В большинстве случаев это нормальное и ожидаемое поведение, и значение по умолчанию в 120 с вполне приемлемо. Однако много соединений в состоянии "TIME_WAIT" может привести к тому, что приложение исчерпает эфемерные порты для соединений к клиентскому сокету. В этом случае следует уменьшить FIN тайм-аут.
Управляет этим тайм-аутом параметр net.ipv4.tcp_fin_timeout . Рекомендуемое значение для высоконагруженных систем составляет от 5 до 7 секунд.
Собираем все вместе
Очередь приема (receive queue) должна быть рассчитана на обработку всех пакетов, полученных через сетевой интерфейс, не вызывая отбрасывания пакетов. Также необходимо учесть небольшой буфер на случай, если всплески будут немного выше, чем ожидалось. Для определения правильного значения следует отслеживать файл softnet_stat на предмет отброшенных пакетов. Эмпирическое правило — использовать значение tcp_max_syn_backlog, чтобы разрешить как минимум столько же SYN-пакетов, сколько может быть обработано для создания полуоткрытых соединений. Помните, что этот параметр задает количество пакетов, которое каждый процессор может иметь в своем буфере, поэтому разделите значение на количество процессоров.
Размер SYN очереди ожидания (SYN backlog queue) на высоконагруженном сервере должен быть рассчитан на большое количество полуоткрытых соединений для обработки редких всплесков трафика. Здесь эмпирическое правило заключается в том, чтобы установить это значение, по крайней мере, на максимальное количество установленных соединений, которое слушатель может иметь в очереди приема, но не выше, чем удвоенное количество установленных соединений. Также рекомендуется отключить SYN cookie, чтобы избежать потери данных при больших всплесках соединений от легитимных клиентов.
Очередь установленных соединений, ожидающих принятия (accept queue) должна быть рассчитана таким образом, чтобы в периоды сильного всплеска трафика ее можно было использовать в качестве временного буфера для установленных соединений. Эмпирическое правило — устанавливать это значение в пределах 20–25% от числа рабочих потоков.
Параметры
В этой статье были рассмотрены следующие параметры ядра:
И следующие пользовательские ограничения:
Заключение
Все параметры в этой статье приведены в качестве примеров и не должны вслепую применяться на ваших продакшн-серверах без тестирования. Есть и другие параметры ядра, которые влияют на производительность сетевого стека. Но в целом, это наиболее важные параметры, которые я использовал при настройке ядра для высоконагруженных систем.
Системные настройки Linux: подробное объяснение команды ulimit
команда ulimitИспользуется для ограничения доступа пользователей системы к ресурсам оболочки. Если вы не понимаете, что это значит, следующий параграф поможет вам понять:
Предположим, что существует такая ситуация, когда 10 человек одновременно входят в систему на хосте Linux, при условии неограниченных системных ресурсов, эти 10 пользователей одновременно открыли 500 документов, и предполагая, что размер каждого документа равен 10 М, это Ресурсы памяти системы будут сильно оспорены.
Реальная прикладная среда намного сложнее, чем это предположение. Например, во встроенной среде разработки различные ресурсы очень скудны. Для числа дескрипторов открытых файлов, размера выделенного стека, времени ЦП, Размер памяти и т. Д. Предъявляет очень строгие требования. Разумное ограничение и распределение ресурсов является не только необходимым условием обеспечения доступности системы, но и неразрывно связано с производительностью программного обеспечения, работающего в системе. В настоящее время ulimit может сыграть большую роль, это простой и эффективный способ добиться ограничения ресурсов.
ulimit используется для ограничения ресурсов, занимаемых процессом запуска оболочки, и поддерживает следующие типы ограничений: размер создаваемого файла ядра, размер блока данных процесса, размер файла, создаваемого процессом оболочки, размер блокировки памяти, резидентная память Размер набора, количество дескрипторов открытых файлов, максимальный размер выделенного стека, время ЦП, максимальное количество потоков для одного пользователя и максимальная виртуальная память, которую может использовать процесс Shell. В то же время он поддерживает жесткие и мягкие ограничения ресурсов.
В качестве временного ограничения ulimit может применяться к сеансам оболочки, вошедшим в систему с помощью его команд, заканчивая ограничение по окончании сеанса и не влияя на другие сеансы оболочки. Для долгосрочных фиксированных ограничений оператор команды ulimit может быть добавлен в файл, читаемый оболочкой входа в систему, действующей на конкретного пользователя оболочки.
грамматика
Опции
Примеры
Каждая строка вывода состоит из имени ресурса (единицы измерения, параметра команды ulimit) и мягкого ограничения. объяснить подробно:
Используйте команду ulimit для ограничения размера файла, что приводит к сбою команды копирования
ls: temp.txt: нет файла или каталога
Размер файла превышает лимит
Размер файла a.c составляет 5002 байта, а размер файла, который мы устанавливаем, составляет 512 байтов x 1 блок = 512 байтов.
1. Измените ограничение на количество файлов, которые могут быть открыты пользовательским процессом.
На платформе Linux, независимо от написания клиентских или серверных программ, при выполнении обработки TCP-соединений с высоким параллелизмом максимальное количество одновременных подключений должно быть ограничено количеством файлов, которые могут быть открыты системой для одного процесса пользователя одновременно (это происходит потому, что система Каждое TCP-соединение должно создавать дескриптор сокета, и каждый дескриптор сокета также является дескриптором файла). Вы можете использовать команду ulimit для просмотра системного ограничения на количество файлов, которые разрешено открывать текущему пользовательскому процессу:
Это означает, что каждому процессу текущего пользователя разрешено открывать до 1024 файлов одновременно. В этих 1024 файлах должны быть удалены стандартный ввод, стандартный вывод, стандартная ошибка, которую должен открыть каждый процесс. Сервер прослушивает сокет и сокет домена unix для межпроцессного взаимодействия. Дождитесь файлов, тогда оставшиеся файлы, доступные для подключения клиентского сокета, будут только около 1024-10 = 1014. Другими словами, по умолчанию коммуникационная программа на основе Linux допускает до 1014 одновременных TCP-соединений.
Для обработчиков связи, которые хотят поддерживать большее количество одновременных TCP-соединений, вы должны изменить мягкое ограничение и жесткое ограничение количества файлов, которые процесс текущего пользователя может открыть одновременно. Среди них, мягкое ограничение означает, что Linux может дополнительно ограничивать количество файлов, которые пользователь может открыть одновременно в пределах текущего диапазона системы, а жесткое ограничение - это количество файлов, которые система может открывать одновременно в соответствии с состоянием ресурсов аппаратного обеспечения системы (главным образом, системной памяти). Обычно мягкий предел меньше или равен жесткому пределу.
Самый простой способ изменить указанное выше ограничение - использовать команду ulimit:
В приведенной выше команде укажите максимальное число открытых файлов, разрешенное для одного процесса, которое должно быть установлено в <file_num>. Если система отображает что-то вроде «Операция не разрешена», это означает, что изменение вышеуказанного предела не удалось, фактически, потому что значение, указанное в <file_num>, превышает мягкое или жесткое ограничение количества файлов, открытых системой Linux для пользователя. Поэтому вам необходимо изменить мягкие и жесткие ограничения на количество открытых файлов для пользователей в системе Linux.
Первый шаг - изменить файл /etc/security/limits.conf и добавить в него следующую строку:
Среди них speng указывает ограничение на количество открытых файлов, которые должны быть изменены пользователем. Знак «*» может использоваться для изменения предела всех пользователей, «soft» или «hard» указывает, следует ли изменять «мягкий» или «hard limit»; , Которое является максимальным количеством открытых файлов (обратите внимание, что значение мягкого предела должно быть меньше или равно жесткому пределу). Сохраните файл после модификации.
Второй шаг - изменить файл /etc/pam.d/login и добавить в него следующую строку:
Это говорит Linux, что после того, как пользователь завершит вход в систему, должен быть вызван модуль pam_limits.so, чтобы установить максимальное ограничение системы на количество различных ресурсов, доступных пользователю (включая максимальное количество файлов, которые пользователь может открыть), и модуль pam_limits.so Прочитает конфигурацию из файла /etc/security/limits.conf, чтобы установить эти ограничения. Сохраните этот файл после модификации.
Третий шаг - проверить ограничение максимального количества открытых файлов на системном уровне Linux, используя следующую команду:
Это показывает, что эта система Linux позволяет открывать до 12158 файлов одновременно (то есть, включая общее количество файлов, открытых всеми пользователями), что является жестким ограничением на уровне системы Linux. Все ограничения на открытые файлы уровня пользователя не должны превышать это значение. Как правило, этот жесткий предел на уровне системы - это оптимальное максимальное количество одновременно открытых файлов, рассчитываемое системой Linux в соответствии с состоянием системных аппаратных ресурсов при запуске. Если в этом нет особой необходимости, этот предел не следует изменять, если вы не хотите ограничивать количество открытых файлов для уровня пользователя. Установите значение, которое превышает этот предел. Чтобы изменить это жесткое ограничение, нужно изменить скрипт /etc/rc.local и добавить в него следующую строку:
Это заставит Linux принудительно установить ограничение на количество открытых файлов на уровне системы до 22158 после завершения загрузки. Сохраните этот файл после модификации.
После выполнения описанных выше шагов перезапустите систему.В общем случае вы можете задать для указанного значения максимальное количество файлов, которые система Linux может одновременно открыть для указанного процесса указанного пользователя. Если вы используете команду ulimit-n для проверки количества открытых файлов, которые пользователь может открыть после перезапуска, ограничение все равно будет ниже максимального значения, установленного на предыдущем шаге. Это может быть связано с тем, что команда ulimit -n использовалась для одновременного открытия пользователя в сценарии входа пользователя в систему / etc / profile Количество файлов ограничено. Когда система ограничивает максимальное количество файлов, которые пользователь может открыть одновременно через ulimit-n, вновь измененное значение может быть меньше или равно значению, установленному ulimit-n в прошлый раз, поэтому с помощью этой команды невозможно увеличить это предельное значение из. Поэтому, если вышеуказанные проблемы существуют, вы можете открыть только файл сценария / etc / profile, найти в файле, используется ли ulimit-n для ограничения максимального количества файлов, которые пользователь может открыть одновременно, и, если он найден, удалить эту строку команды, Или измените установленное значение на соответствующее значение, затем сохраните файл, и пользователь сможет выйти и снова войти в систему.
Посредством вышеупомянутых шагов системное ограничение на количество открытых файлов снимается для программы обработки связи, поддерживающей обработку одновременных высокопроизводительных соединений TCP.
2. Измените ограничения на соединение TCP ядром сети
При написании обработчика клиентских коммуникаций, который поддерживает высокопараллельные TCP-соединения в Linux, иногда я обнаруживаю, что, хотя система сняла ограничение на количество одновременно открытых пользовательских файлов, все равно будет количество одновременных TCP-соединений, которое увеличится до определенного числа. Явление, что новое соединение TCP не может быть успешно установлено. Есть много причин для этого.
Обратите внимание на управление доступом к переменной sysctl_local_port_range в приведенной выше функции. Инициализация переменной sysctl_local_port_range задается в следующей функции в файле tcp.c:
Диапазон номеров локальных портов, установленный по умолчанию при компиляции ядра, может быть слишком мал, поэтому вам нужно изменить это ограничение диапазона локальных портов.
Первый шаг - изменить файл /etc/sysctl.conf и добавить в него следующую строку:
Это указывает на то, что система ограничивает диапазон локальных портов между 1024 и 65000. Обратите внимание, что минимальное значение диапазона локального порта должно быть больше или равно 1024, максимальное значение диапазона порта должно быть меньше или равно 65535. Сохраните этот файл после модификации.
Второй шаг - выполнить команду sysctl:
Первый шаг - изменить файл /etc/sysctl.conf и добавить в него следующую строку:
Это указывает на то, что система ограничивает максимальное количество отслеживаемых соединений TCP до 10240. Обратите внимание, что этот предел должен быть как можно меньше, чтобы сохранить использование памяти ядра.
Второй шаг - выполнить команду sysctl:
sysctl -p сообщает об ошибке net.ipv4.ip_conntrack_max "- неизвестный ключ: modprobe ip_conntrack
1. Мягкие и жесткие могут быть установлены вместе так, чтобы
Если установлен только один, он не будет работать
2. Когда вступает в силу настройка ulimit
Выйдите из текущего сеанса, войдите снова или выполните напрямую из командной строки
Читайте также: