Gdzie są określone domyślne limity w OS X (10.5)?

Domyślny nofilelimit kont użytkowników OS X wynosi obecnie około 256 deskryptorów plików. Próbuję przetestować oprogramowanie, które wymaga znacznie większej liczby połączeń niż otwarte jednocześnie.

W typowym oknie Debiana z modułem pam limitów edytowałbym, /etc/security/limits.confaby ustawić wyższe limity dla użytkownika, który będzie uruchamiał oprogramowanie, ale zastanawiam się, gdzie ustawić te limity w OS X.

Czy jest gdzieś do tego GUI? Czy jest gdzieś plik konfiguracyjny? Jaki jest najbardziej uporządkowany sposób zmiany domyślnych limitów w OS X?

W Leopardzie początkowy proces to launchd. Domyślne limity każdego procesu są dziedziczone launchd. Dla odniesienia domyślnymi (wkompilowanymi) limitami są

$ 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

Aby zmienić którykolwiek z tych limitów, dodaj wiersz (może być konieczne najpierw utworzenie pliku) /etc/launchd.conf, argumenty są takie same, jak przekazane do launchctlpolecenia. Na przykład

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

Jednak launchdjuż uruchomiono powłokę logowania, więc najprostszym sposobem na wprowadzenie tych zmian jest ponowne uruchomienie naszego komputera. (Użyj >>, aby dołączyć do /etc/launchd.conf.)

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

nie działa, ponieważ sudo znajduje się w niewłaściwym miejscu, spróbuj tego:

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

Ograniczenia powłoki

Zasoby dostępne dla powłoki i procesów można zmienić za pomocą ulimitpolecenia, które można dodać do skryptów startowych, takich jak ~/.bashrclub ~/.bash_profiledla poszczególnych użytkowników lub /etc/bashrcdla wszystkich użytkowników . Przykładowa linia do dodania:

ulimit -Sn 4096 && ulimit -Sl unlimited

^{Zobacz: help ulimiti man bashwięcej informacji.}

Limity systemowe

Zasadniczo limity systemowe są kontrolowane przez środowisko Launchd i mogą być zmieniane za pomocą launchctlpolecenia, np

launchctl limit maxfiles 10240 unlimited

Aby zmiany były trwałe, musisz utworzyć plik listy właściwości w określonych folderach zgodnych z Launch, które działają jako agent startowy.

Oto przykładowe polecenie tworzące taki plik startowy:

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"

Plik zostanie załadowany przy uruchomieniu systemu, aby załadować go ręcznie:

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

Aby sprawdzić aktualne limity, uruchom: launchctl limit.

^{Zobacz: Tworzenie demonów i agentów uruchamiania .}

Limity jądra

• Limity jądra są kontrolowane przez sysctlpolecenie.
• Aby zobaczyć aktualne limity jądra, uruchom: sysctl -a | grep ^kern.max.
• Aby zmienić maksymalną ilość plików mogą otwierać, uruchom: sudo sysctl -w kern.maxfiles=20480.
• Aby zmiany były trwałe, użyj podobnej powyższej metody, aby utworzyć plik listy właściwości w folderze startowym systemu.

Związane z:

• Jak trwale kontrolować maksymalne zużycie zasobów systemowych na komputerze Mac?
• Które polecenie kontroluje limity otwartych plików?

Przestarzałe metody

We wcześniejszej wersji systemu macOS można było ustawić te limity w całym /etc/sysctl.confsystemie, jak zwykle w systemie Unix, jednak wydaje się, że nie jest ono obsługiwane.

Używanie ~/.launchd.conflub /etc/launchd.confwydaje się, że nie jest również obsługiwane w żadnej istniejącej wersji systemu macOS. ^wiki

To samo dotyczy /etc/rc.localpliku startowego, nie jest obsługiwany w systemie 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
%

Teraz muszę się dowiedzieć, dlaczego istnieją 2 sposoby sprawdzania / ustawiania limitów ....

Okej - wydaje się ulimiti sysctldaje fałszywie pozytywne wrażenie, że faktycznie coś robią - ale zamiast tego wydają się bezużyteczne . Czy ktoś może to zweryfikować?

Okej, zaczynam rozumieć. Począwszy od wersji 10.4, nie ma initjuż żadnego procesu, został on zastąpiony przez launchd, który również działa z 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

I oczywiście warto wspomnieć, że ulimitjest to wbudowana powłoka, launchctlto program niezależny od powłoki.

W systemie OS X, jeśli próbujesz zmodyfikować miękkie limity dla demona, procesu lub zadania, właściwym sposobem zmiany tych miękkich limitów nie jest zmiana domyślnej uruchomionej konfiguracji dla wszystkich procesów, ale ustawienie jej dla procesu, w którym jesteś próbuje biec.

Jest to realizowane w uruchomionym pliku .plist dla Twojego procesu.

Jeśli masz uruchomionego demona lub proces, dla którego musisz mieć więcej otwartych plików, utwórz dla niego plik plist i dodaj do niego następujące parametry:

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

Przykład użycia mongodb. Tworzę plik .plist o nazwie org.mongo.mongodb.plist i zapisuję go w /Library/LaunchDaemons/org.mongo.mongodb.plist. Plik wygląda następująco:

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

Teraz twój proces ma zasoby, których potrzebuje, bez konieczności marnowania globalnej konfiguracji systemu. Zostanie to automatycznie skonfigurowane przy ponownym uruchomieniu. Lub, jeśli nie chcesz restartować, możesz uruchomić

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

Jeśli twój proces lub zadanie jest bardziej agentem niż demonem, możesz zamiast tego umieścić .plist w / Library / LaunchAgents. W obu przypadkach obowiązują różne zasady dotyczące tego, jak uruchomienie będzie kontrolować proces. Wydaje się, że LaunchDaemons jest zarezerwowane dla procesów, które uruchomione będą starały się nadążać przez cały czas.

Następujące powinny rozwiązać większość rozwiązań (i są wymienione w kolejności ich hierarchii):

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

Uwagi:

1. Konieczne będzie ponowne uruchomienie, aby zmiany zostały wprowadzone.
2. AFAIK, nie można już ustawiać limitów na „nieograniczony” w OS X
3. launchctl maxfiles są ograniczone przez maxfiles sysctl i dlatego nie mogą ich przekraczać
4. Wygląda na to, że sysctl dziedziczy kern.maxfilesperproc z maxctiles launchctl
5. ulimit domyślnie dziedziczy wartość „otwartych plików” z launchctl
6. możesz ustawić niestandardową ulimit w / etc / profile lub ~ / .profile; chociaż nie jest to wymagane, podałem przykład
7. Zachowaj ostrożność przy ustawianiu którejkolwiek z tych wartości na bardzo dużą liczbę w porównaniu z ich wartością domyślną - istnieją funkcje stabilności / bezpieczeństwa. Wziąłem te przykładowe liczby, które moim zdaniem są rozsądne, zapisane na innych stronach internetowych.
8. Gdy limity uruchamiania sctctl są niższe niż limity sysctl, pojawiły się doniesienia, że ​​odpowiednie limity sysctl zostaną automatycznie zwiększone, aby spełnić wymagania.

Z mojego doświadczenia wynika, że ​​moje zadanie polegające na dużej liczbie procesów zakończyło się powodzeniem:

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

kern.maxprocperuid=2048

ulimit -u 2048

Pierwsze dwa mogą wejść do, /etc/sysctl.confa wartość ulimit do launchd.conf, dla niezawodnego ustawienia.

Ponieważ tcp / ip było częścią tego, co robiłem, musiałem również zwiększyć wydajność

kern.ipc.somaxconn=8192

z domyślnego 128.

Zanim podniosłem limity procesu, dostawałem awarie „rozwidlenia”, za mało zasobów. Zanim zwiększyłem kern.ipc.somaxconn, otrzymywałem błędy „zepsutej rury”.

To było podczas uruchamiania sporej liczby (500-4000) odłączonych procesów na moim potwornym Macu, OS 10.5.7, potem 10.5.8, teraz 10.6.1. Pod Linuksem na komputerze moich szefów po prostu działało.

Myślałem, że liczba procesów będzie bliższa 1000, ale wydaje się, że każdy proces, który rozpocząłem, zawierał własną kopię powłoki oprócz rzeczywistego elementu wykonującego faktyczną pracę. Bardzo uroczyście.

Napisałem zabawkę displayową, która wyglądała mniej więcej tak:

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

i obserwowałem maksymalną liczbę procesów w ps -ef i krążyłem w sieci, czekając na TIME_WAITwygaśnięcie ... Po podniesieniu limitów widziałem ponad 3500 TIME_WAITprzedmiotów w szczycie.

Zanim podniosłem granice, mogłem „podkraść się” do progu awarii, który zaczynał się poniżej 1K, ale wzrósł do wysokiej wartości 1190 .. za każdym razem, gdy popychano go w niepowodzenie, może zająć trochę więcej czasu, prawdopodobnie z powodu czegoś buforowane, które zwiększało się do limitu za każdym razem, gdy zawiodło

Chociaż mój przypadek testowy miał „czekać” jako ostateczne stwierdzenie, wciąż było mnóstwo odłączonych procesów wiszących po jego wyjściu.

Większość informacji, z których korzystałem, otrzymałem z postów w Internecie, ale nie wszystkie były dokładne. Twój przebieg może się różnić.