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

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

Ресурсы, доступные для оболочки и процессов, могут быть изменены 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.

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

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

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

В 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 будет пытаться поддерживать в любое время.

% 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 является независимой от оболочки программой

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

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 истечь... С поднятыми пределами я увидел 3500+ TIME_WAIT предметы на пике.

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

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

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

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

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 будут автоматически увеличены для удовлетворения требований.