Wo sind unter OS X (10.5) die Standard-Ulimits festgelegt?


26

Das Standardlimit nofilefür OS X-Benutzerkonten scheint derzeit bei 256 Dateideskriptoren zu liegen. Ich versuche, eine Software zu testen, die viel mehr Verbindungen benötigt, als gleichzeitig geöffnet sind.

Auf einer typischen Debian-Box, auf der das Modul pam limits ausgeführt wird, würde ich bearbeiten /etc/security/limits.conf, um höhere Grenzwerte für den Benutzer festzulegen, der die Software ausführen wird, aber ich bin nicht sicher, wo diese Grenzwerte in OS X festgelegt werden sollen.

Gibt es irgendwo eine GUI dafür? Gibt es irgendwo eine Konfigurationsdatei dafür? Was ist der schnellste Weg, um die Standard-Ulimits unter OS X zu ändern?


Informationen zu Mac OS X Lion finden Sie unter superuser.com/questions/396102/ulimit-does-not-obey-me
David J.,

Antworten:


27

Unter Leopard ist der erste Prozess launchd. Die Standard-Ulimits jedes Prozesses werden von übernommen launchd. Als Referenz sind die Standardgrenzen (kompiliert in)

$ 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

Um eine dieser Beschränkungen zu ändern, fügen Sie eine Zeile hinzu (Sie müssen möglicherweise zuerst die Datei erstellen) /etc/launchd.conf. Die Argumente stimmen mit denen überein, die an den launchctlBefehl übergeben wurden. Beispielsweise

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

launchdIhre Anmeldeshell wurde jedoch bereits gestartet. Der einfachste Weg, um diese Änderungen wirksam werden zu lassen, besteht darin, unseren Computer neu zu starten. (Verwenden Sie >>, um an /etc/launchd.conf anzuhängen.)


2
Könnten Sie einen Link zur offiziellen Dokumentation hinzufügen?
Glyphe

7
Geck, wenn dies war nirgends dokumentiert, diese Seite würde nicht nötig sein
Dave Cheney

1
Scheint nicht auf Snow Leopard zu funktionieren.
Ismail

1
Irgendeine Idee, von der sich das unterscheidet sysctl.maxfiles? (Verwandte Frage: apple.stackexchange.com/questions/33715/too-many-open-files )
Keflavich

2
Kleine Korrektur: Sie laufen echounter sudo, versuchen aber, Ihre nichtprivilegierte Shell an die Datei anzuhängen, wozu sie keine Berechtigung hat. Versuchen Sie es echo "limit maxfiles 1024 unlimited" | sudo tee -a /etc/launchd.confstattdessen.
Vineet

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

funktioniert nicht, weil sudo am falschen Ort ist. Versuchen Sie Folgendes:

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

3
Dies wäre wahrscheinlich besser als "vorgeschlagene Bearbeitung" für die Antwort, auf die Sie sich beziehen.
Chris Johnsen

3

Shell Grenzen

Der Shell und den Prozessen zur Verfügung stehende Ressourcen können per ulimitBefehl geändert werden, der Startskripten wie ~/.bashrcoder ~/.bash_profilefür einzelne Benutzer oder /etc/bashrcfür alle Benutzer hinzugefügt werden kann . Beispielzeile zum Hinzufügen:

ulimit -Sn 4096 && ulimit -Sl unlimited

Siehe: help ulimitund man bashfür weitere Informationen.

Systemgrenzen

Im Allgemeinen werden Systemgrenzen vom Launchd- Framework gesteuert und können per launchctlBefehl geändert werden , z

launchctl limit maxfiles 10240 unlimited

Um die Änderungen dauerhaft zu speichern, müssen Sie eine Eigenschaftslistendatei in bestimmten Start-kompatiblen Ordnern erstellen, die als Start-Agent fungiert.

Hier ist der Beispielbefehl zum Erstellen einer solchen Startdatei:

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"

Die Datei wird jedoch beim Systemstart geladen, um sie manuell auszuführen:

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

Um die aktuellen Grenzwerte zu überprüfen, führen: launchctl limit.

Siehe: Erstellen von Start-Daemons und Agenten .

Kernel-Grenzen

  • Kernel-Limits werden vom sysctlBefehl gesteuert .
  • Um die aktuellen Kernel Grenzen zu sehen, laufen: sysctl -a | grep ^kern.max.
  • Um die maximal zu öffnen, Lauf erlaubt Dateien zu ändern: sudo sysctl -w kern.maxfiles=20480.
  • Verwenden Sie die oben beschriebene Methode, um die Änderungen dauerhaft zu speichern, und erstellen Sie die Eigenschaftslistendatei im Systemstartordner.

Verbunden:


Veraltete Methoden

In früheren Versionen von macOS konnten Sie diese Grenzwerte /etc/sysctl.confsystemweit festlegen, wie Sie es normalerweise unter Unix tun. Es scheint jedoch, dass dies nicht unterstützt wird.

Die Verwendung von ~/.launchd.confoder /etc/launchd.confscheint auch in keiner vorhandenen Version von macOS unterstützt zu werden. wiki

Wie bei der /etc/rc.localStartdatei wird sie unter macOS nicht unterstützt.


2
% 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
%

Jetzt muss ich herausfinden, warum es 2 Möglichkeiten gibt, Grenzen zu prüfen / festzulegen ....


Ok - scheint wie ulimitund sysctlgibt ein falsch-positives Gefühl , dass sie etwas tatsächlich tun - , sondern scheinen sie zu sein nutzlos . Könnte jemand das überprüfen?


Okay, ich fange an zu verstehen. Ab v10.4 gibt es keinen initProzess mehr, er wurde ersetzt durch launchd, der auch mit einer PID von 1 läuft.

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

Und natürlich ist zu erwähnen, dass ulimites sich um ein Shell-eingebautes, launchctlein Shell-unabhängiges Programm handelt.


2

Wenn Sie unter OS X versuchen, die Softwarelimits für einen Dämon oder einen Prozess oder eine Aufgabe zu ändern, müssen Sie diese Softwarelimits nicht für alle Prozesse in der Standardkonfiguration von launchd ändern , sondern für den jeweiligen Prozess festlegen versuchen zu rennen.

Dies geschieht in Ihrer launchd .plist-Datei für Ihren Prozess.

Wenn ein Daemon oder Prozess ausgeführt wird, für den Sie mehr offene Dateien benötigen, erstellen Sie eine plist-Datei und fügen Sie diese Parameter hinzu:

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

Ein Beispiel mit Mongodb. Ich erstelle eine .plist-Datei mit dem Namen org.mongo.mongodb.plist und speichere sie in /Library/LaunchDaemons/org.mongo.mongodb.plist. Die Datei sieht folgendermaßen aus:

<?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>

Jetzt verfügt Ihr Prozess über die Ressourcen, die er benötigt, ohne die globale Konfiguration für das System zu beeinträchtigen. Dies wird beim Neustart automatisch eingerichtet. Wenn Sie nicht neu starten möchten, können Sie ausführen

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

Wenn Ihr Prozess oder Ihre Aufgabe eher ein Agent als ein Daemon ist, können Sie die .plist stattdessen in / Library / LaunchAgents ablegen. In beiden Fällen gelten unterschiedliche Regeln für die Steuerung Ihres Prozesses durch launchd. LaunchDaemons scheint für Prozesse reserviert zu sein, die von launchd ständig aktualisiert werden sollen.


1

Folgendes sollte die meisten Lösungen auflösen (und wird in der Reihenfolge ihrer Hierarchie aufgelistet):

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

Anmerkungen:

  1. Sie müssen neu starten, damit diese Änderungen wirksam werden.
  2. AFAIK Unter OS X können Sie keine Limits mehr auf "unbegrenzt" setzen
  3. launchctl maxfiles werden von sysctl maxfiles begrenzt und dürfen diese daher nicht überschreiten
  4. sysctl scheint kern.maxfilesperproc von launchctl maxfiles zu erben
  5. ulimit scheint standardmäßig den Wert 'open files' von launchctl zu erben
  6. Sie können ein benutzerdefiniertes Ulimit in / etc / profile oder ~ / .profile festlegen. obwohl dies nicht erforderlich ist, habe ich ein Beispiel angegeben
  7. Seien Sie vorsichtig, wenn Sie einen dieser Werte im Vergleich zu den Standardwerten auf einen sehr hohen Wert setzen - die Funktionen sind stabil und sicher. Ich habe diese Beispielzahlen, die ich für vernünftig halte, auf anderen Websites geschrieben.
  8. Wenn die Startlimits niedriger sind als die Systemlimits, wurde berichtet, dass die relevanten Systemlimits automatisch erhöht werden, um die Anforderungen zu erfüllen.

1

Ich habe die Erfahrung gemacht, dass meine Aufgabe mit hoher Prozessanzahl nur erfolgreich war mit:

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

kern.maxprocperuid=2048

ulimit -u 2048

Die ersten beiden können in /etc/sysctl.confdie Datei launchd.conf und der Wert ulimit für eine zuverlässige Einstellung eingegeben werden.

Da TCP / IP ein Teil meiner Arbeit war, musste ich mich auch anstrengen

kern.ipc.somaxconn=8192

von seiner Standardeinstellung 128.

Bevor ich die Prozessgrenzen erhöht habe, gab es Gabelungsfehler, nicht genügend Ressourcen. Bevor ich kern.ipc.somaxconn vergrößerte, bekam ich "broken pipe" -Fehler.

Dies geschah, während auf meinem Monster Mac, OS 10.5.7, dann 10.5.8, jetzt 10.6.1, eine ganze Reihe (500-4000) getrennter Prozesse ausgeführt wurden. Unter Linux auf dem Computer meines Chefs hat es einfach funktioniert.

Ich dachte, dass die Anzahl der Prozesse näher bei 1000 liegen würde, aber es scheint, dass jeder Prozess, den ich gestartet habe, zusätzlich zu dem eigentlichen Gegenstand, der die eigentliche Arbeit erledigt, eine eigene Kopie der Shell enthielt. Sehr festlich

Ich habe ein Ausstellungsspielzeug geschrieben, das ungefähr so ​​aussah:

#!/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

und beobachtete die maximale Anzahl von Prozessen in ps -ef und wartete in netstat darauf TIME_WAIT, dass sie abliefen TIME_WAIT.

Bevor ich die Grenzen anhob, konnte ich mich an die Ausfallschwelle heranschleichen, die unterhalb von 1K begann, aber auf einen hohen Wert von 1190 anstieg. Jedes Mal, wenn es zu einem Ausfall kam, konnte es das nächste Mal ein wenig länger dauern, wahrscheinlich wegen etwas jedes Mal, wenn ein Fehler auftrat, wurde der Cache bis an sein Limit erweitert.

Obwohl mein Testfall eine "Wartezeit" als letzte Anweisung hatte, gab es nach dem Beenden VIELE getrennte Prozesse.

Ich habe die meisten Informationen, die ich verwendet habe, aus Beiträgen im Internet erhalten, aber nicht alle waren korrekt. Ihre Laufleistung kann variieren.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.