Де вказані обмеження за замовчуванням в OS X (10.5)?

За замовчуванням nofileмежі для облікових записів користувачів OS X , здається, близько 256 файлових дескрипторів в ці дні. Я намагаюся перевірити деяке програмне забезпечення, яке потребує набагато більше підключень, ніж те, що відкрито одразу.

У типовому вікні Debian, в якому працює модуль обмеження пам’яті, я би редагував, /etc/security/limits.confщоб встановити більш високі обмеження для користувача, який буде запускати програмне забезпечення, але мені загадано, де встановити ці обмеження в OS X.

Чи є десь GUI для цього? Чи є десь файл конфігурації для нього? Який найзручніший спосіб змінити обмеження за замовчуванням для 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

не працює, оскільки судо не в тому місці, спробуйте це:

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 Framework і можуть бути змінені launchctlкомандою, наприклад

launchctl limit maxfiles 10240 unlimited

Щоб зміни були стійкими, вам потрібно створити файл списку властивостей у специфічних папках, що відповідають сумісності, який виконує функції агента запуску.

Ось приклад команди створення такого файлу запуску:

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це програма, незалежна від оболонок.

У ОС X, якщо ви намагаєтесь змінити м'які межі для демона чи процесу чи завдання, правильний спосіб змінити ці м'які межі полягає не в зміні конфігурації запуску за замовчуванням для всіх процесів, а шляхом встановлення цього процесу для цього процесу. намагається бігти.

Це робиться у вашому запуску .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. Для того, як запуск буде контролювати ваш процес в будь-якому випадку, застосовуються різні правила. LaunchDaemons, схоже, зарезервований для процесів, які запускатимуться намагатися йти в ногу завжди.

Далі слід вирішити більшість рішень (і перераховані в порядку їх ієрархії):

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 ви більше не можете встановлювати обмеження на "необмежений" в ОС X
3. maxctfile startctl обмежені maxfilesми sysctl, і тому їх не можна перевищувати
4. Схоже, sysctl успадковує kern.maxfilesperproc від maxfiles startctl
5. ulimit, схоже, успадковує це значення "відкритих файлів" від запуск за замовчуванням
6. ви можете встановити користувацьку polimit в / etc / profile або ~ / .profile; хоча це не потрібно, я наводив приклад
7. Будьте обережні, встановлюючи будь-яке з цих значень на дуже високе число в порівнянні з їх замовчуванням - функції існують стабільність / безпека. Я взяв ці приклади, які, на мою думку, є розумними, написані на інших веб-сайтах.
8. Коли межі startctl нижчі, ніж обмеження sysctl, з'явилися повідомлення про те, що відповідні sysctl будуть автоматично підбиватися для задоволення вимог.

Мій досвід полягає в тому, що моє завдання з високою кількістю процесів вдалося досягти лише з:

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

kern.maxprocperuid=2048

ulimit -u 2048

Перші два можуть увійти /etc/sysctl.confі змінити значення ulimit в startd.conf для надійного налаштування.

Оскільки tcp / ip був частиною того, що я робив, мені також потрібно було піддаватися

kern.ipc.somaxconn=8192

від замовчування 128.

Перш ніж я збільшив ліміти технологічних процесів, я отримував збої "вилки", недостатньо ресурсів. Перш ніж я збільшив kern.ipc.somaxconn, я отримував помилки "зламаної труби".

Це було в той час, коли на моєму монстері Mac, OS 10.5.7, потім 10.5.8, зараз 10.6.1, на моєму Mac Monster Mac, OS 10.5.7, потім 10.5.8, зараз працювало неабияке число (500-4000). У 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 .. щоразу, коли його натискали на невдачу, наступного разу це може зайняти трохи більше, ймовірно, через щось кеш, який розширювався до межі кожного разу, коли не вдалося.

Хоча мій тестовий випадок мав "зачекати", оскільки його остаточне твердження все ще залишалося ВІДБУДУВАННЯ відокремлених процесів після його виходу.

Я отримав більшу частину інформації, яку я використав із публікацій в Інтернеті, але не вся вона була точною. Ваш пробіг може відрізнятися.