Где предельные значения по умолчанию, указанные в OS X (10.5)?

nofileОграничение по умолчанию для учетных записей пользователей OS X в наши дни составляет около 256 файловых дескрипторов. Я пытаюсь протестировать какое-то программное обеспечение, которое требует гораздо больше соединений, чем открытое одновременно.

На типичной коробке Debian, на которой запущен модуль ограничений pam, я бы отредактировал, /etc/security/limits.confчтобы установить более высокие ограничения для пользователя, который будет запускать программное обеспечение, но я не уверен, где установить эти ограничения в OS X.

Есть ли где-нибудь графический интерфейс для этого? Где-нибудь есть файл конфигурации? Какой самый простой способ изменить ограничения по умолчанию на OS X?

Под леопардом начальный процесс launchd. Улиты по умолчанию каждого процесса наследуются от launchd. Для справки: ограничения по умолчанию (собранные в)

$ sudo launchctl limit
    cpu         unlimited      unlimited      
    filesize    unlimited      unlimited      
    data        6291456        unlimited      
    stack       8388608        67104768       
    core        0              unlimited      
    rss         unlimited      unlimited      
    memlock     unlimited      unlimited      
    maxproc     266            532            
    maxfiles    256            unlimited

Чтобы изменить любое из этих ограничений, добавьте строку (сначала вам может понадобиться создать файл) /etc/launchd.conf, аргументы такие же, как переданные в launchctlкоманду. Например

echo "limit maxfiles 1024 unlimited" | sudo tee -a /etc/launchd.conf

Тем launchdне менее , уже запущена ваша оболочка входа в систему, поэтому самый простой способ, чтобы эти изменения вступили в силу, это перезагрузить наш компьютер. (Используйте >> для добавления в /etc/launchd.conf.)

sudo echo "limit maxfiles 1024 unlimited" >> /etc/launchd.conf

не работает, потому что sudo находится не в том месте, попробуйте это:

echo 'limit maxfiles 10000 unlimited' | sudo tee -a /etc/launchd.conf

Ограничения оболочки

Ресурсы , доступные оболочки и процессы могут быть изменены с помощью ulimitкоманды , которые могут быть добавлены в сценарий запуска , такие как ~/.bashrcили ~/.bash_profileдля отдельных пользователей или /etc/bashrcдля всех пользователей . Пример строки для добавления:

ulimit -Sn 4096 && ulimit -Sl unlimited

^{Смотрите: help ulimitи man bashдля получения дополнительной информации.}

Системные ограничения

В общем, системные ограничения контролируются платформой Launchd и могут быть изменены launchctlкомандой, например

launchctl limit maxfiles 10240 unlimited

Чтобы сделать изменения постоянными, вам нужно создать файл списка свойств в определенных папках, совместимых с Launch, который действует как агент запуска.

Вот пример команды, создающей такой файл запуска:

sudo /usr/libexec/PlistBuddy /Library/LaunchAgents/com.launchd.maxfiles.plist -c "add Label string com.launchd.maxfiles" -c "add ProgramArguments array" -c "add ProgramArguments: string launchctl" -c "add ProgramArguments: string limit" -c "add ProgramArguments: string maxfiles" -c "add ProgramArguments: string 10240" -c "add ProgramArguments: string unlimited" -c "add RunAtLoad bool true"

Файл будет загружен при запуске системы, однако для загрузки вручную:

sudo launchctl load /Library/LaunchAgents/com.launchd.maxfiles.plist

Для того, чтобы проверить текущие ограничения, выполните команду: launchctl limit.

^{См .: Создание демонов запуска и агентов .}

Пределы ядра

• Пределы ядра контролируются sysctlкомандой.
• Чтобы увидеть текущие ограничения ядра, выполните команду: sysctl -a | grep ^kern.max.
• Для того, чтобы изменить максимум файлов , разрешенных к открытой перспективе: sudo sysctl -w kern.maxfiles=20480.
• Чтобы сделать изменения постоянными, используйте аналогичный выше метод для создания файла списка свойств в папке автозагрузки системы.

Связанный:

• Как постоянно контролировать максимальное потребление системных ресурсов на Mac?
• Какая команда контролирует пределы открытого файла?

Устаревшие методы

В более ранней версии macOS вы могли устанавливать эти ограничения в /etc/sysctl.confмасштабе всей системы, как это обычно делается в Unix, однако, похоже, это не поддерживается.

Использование ~/.launchd.confили, по- /etc/launchd.confвидимому, также не поддерживается ни в одной из существующих версий macOS. ^вики

То же самое с /etc/rc.localфайлом запуска, он не поддерживается в macOS.

% ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) 6144
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 2560
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 266
virtual memory          (kbytes, -v) unlimited
%

Теперь я должен выяснить, почему существует 2 способа проверки / установки пределов ....

Ладно - похоже ulimitи sysctlдает ложно-позитивное ощущение, что они действительно что-то делают - но вместо этого они кажутся бесполезными . Может ли кто-нибудь это проверить?

Хорошо, я начинаю понимать. Начиная с v10.4, initпроцесс больше не выполняется, его заменили launchd, который также работает с PID 1.

% ps -fu root
  UID   PID  PPID   C     STIME TTY           TIME CMD
    0     1     0   0   0:30.72 ??         0:46.72 /sbin/launchd

И, конечно, стоит упомянуть, что ulimitэто встроенная launchctlоболочка, независимая от оболочки программа.

В OS X, если вы пытаетесь изменить мягкие ограничения для демона, процесса или задачи, правильным способом изменить эти мягкие ограничения является не изменение конфигурации запуска по умолчанию для всех процессов, а установка этого значения для процесса, которым вы являетесь пытаясь бежать.

Это выполняется в вашем файле launchd .plist для вашего процесса.

Если у вас запущен демон или процесс, для которого вам нужно иметь больше открытых файлов, создайте для него файл plist и добавьте в него следующие параметры:

    <key>SoftResourceLimits</key>
    <dict>
        <key>NumberOfFiles</key>
        <integer>1024</integer>
    </dict>

Пример использования mongodb. Я создаю файл .plist с именем org.mongo.mongodb.plist и сохраняю его в /Library/LaunchDaemons/org.mongo.mongodb.plist. Файл выглядит так:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Disabled</key>
  <false/>
  <key>Label</key>
  <string>org.mongo.mongod</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/lib/mongodb/bin/mongod</string>
    <string>--dbpath</string>
    <string>/Users/Shared/mongodata/</string>
    <string>--logpath</string>
    <string>/var/log/mongodb.log</string>
  </array>
  <key>QueueDirectories</key>
  <array/>
  <key>RunAtLoad</key>
  <true/>
  <key>UserName</key>
  <string>daemon</string>
  <key>SoftResourceLimits</key>
  <dict>
    <key>NumberOfFiles</key>
    <integer>1024</integer>
    <key>NumberOfProcesses</key>
    <integer>512</integer>
  </dict>
</dict>
</plist>

Теперь у вашего процесса есть ресурсы, в которых он нуждается, без использования глобальной конфигурации системы. Это будет автоматически установлено при перезапуске. Или, если вы не хотите перезапустить, вы можете запустить

sudo launchctl load /Library/LaunchDaemons/org.mongod.plist

Если ваш процесс или задача скорее агент, чем демон, вы можете вместо этого поместить .plist в / Library / LaunchAgents. Различные правила применяются для того, как launchd будет контролировать ваш процесс в любом случае. LaunchDaemons, похоже, зарезервирован для процессов, которые launchd будет пытаться поддерживать в любое время.

Следующее должно решить большинство решений (и перечислены в порядке их иерархии):

echo 'kern.maxfiles=20480' | sudo tee -a /etc/sysctl.conf
echo -e 'limit maxfiles 8192 20480\nlimit maxproc 1000 2000' | sudo tee -a /etc/launchd.conf
echo 'ulimit -n 4096' | sudo tee -a /etc/profile

Заметки:

1. Вам нужно будет перезапустить, чтобы эти изменения вступили в силу.
2. AFAIK, вы больше не можете устанавливать ограничения на «безлимитный» под OS X
3. Максимальные файлы launchctl ограничены максимальными файлами sysctl и поэтому не могут превышать их
4. sysctl, кажется, наследует kern.maxfilesperproc от запускаctfl maxfiles
5. ulimit, по-видимому, наследует значение «открытых файлов» от launchctl по умолчанию
6. вы можете установить пользовательский ulimit в / etc / profile или ~ / .profile; пока это не требуется, я привел пример
7. Будьте осторожны при установке любого из этих значений на очень большое число по сравнению с их значениями по умолчанию - существуют функции стабильности / безопасности. Я взял эти цифры примера, которые я считаю разумными, написанные на других сайтах.
8. Когда пределы launchctl ниже, чем sysctl, появляются сообщения, что соответствующие sysctl будут автоматически увеличены для соответствия требованиям.

Мой опыт показывает, что моя задача с большим количеством процессов была успешной только с:

kern.maxproc=2500  # This is as big as I could set it.

kern.maxprocperuid=2048

ulimit -u 2048

Первые два могут войти в /etc/sysctl.confи значение ulimit в launchd.conf для надежной настройки.

Так как tcp / ip был частью того, что я делал, мне также нужно было увеличить

kern.ipc.somaxconn=8192

по умолчанию 128.

До того, как я увеличил лимиты процесса, у меня возникали «ложные» сбои, не хватало ресурсов. До того, как я увеличил kern.ipc.somaxconn, я получал ошибки "сломанной трубы".

Это было во время выполнения достаточного количества (500-4000) отдельных процессов на моем монстром Mac, ОС 10.5.7, затем 10.5.8, теперь 10.6.1. Под Linux на компьютере моего босса это просто работало.

Я думал, что число процессов будет ближе к 1000, но кажется, что каждый запущенный мной процесс включал свою собственную копию оболочки в дополнение к фактическому элементу, выполняющему реальную работу. Очень празднично

Я написал игрушку для показа, которая пошла примерно так:

#!/bin/sh

while[ 1 ]

do

    n=netstat -an | wc -l

    nw=netstat -an | grep WAIT | wc -l

    p=ps -ef | wc -l

    psh=ps -ef | fgrep sh | wc -l

    echo "netstat: $n   wait: $nw      ps: $p   sh: $psh"

    sleep 0.5

done

и наблюдал максимальное количество процессов в ps -ef и зависание в netstat в ожидании TIME_WAITистечения срока действия ... С увеличенными пределами я увидел TIME_WAITна пике 3500+ элементов.

До того, как я поднял лимиты, я мог «подкрасться» к порогу отказа, который начинался ниже 1 КБ, но вырос до высокого значения 1190… каждый раз, когда он выдавался до отказа, в следующий раз это могло занять немного больше, вероятно из-за чего-то кэшируется, что расширяется до своего предела каждый раз, когда это не удалось.

Несмотря на то, что мой тестовый пример имел «ожидание» в качестве последнего утверждения, все еще было МНОЖЕСТВО отсоединенных процессов, зависших после его выхода.

Я получил большую часть информации, которую я использовал из сообщений в Интернете, но не все это было точно. Ваш пробег может варьироваться.