Dove sono le ulimits predefinite specificate su OS X (10.5)?

Il nofilelimite predefinito per gli account utente di OS X sembra essere di circa 256 descrittori di file in questi giorni. Sto cercando di testare alcuni software che richiedono molte più connessioni di quelle aperte contemporaneamente.

Su un tipico box Debian che esegue il modulo pam limits, modificherei /etc/security/limits.confper impostare limiti più alti per l'utente che eseguirà il software, ma non so dove impostare questi limiti in OS X.

C'è una GUI da qualche parte per questo? C'è un file di configurazione da qualche parte per questo? Qual è il modo più semplice per modificare gli ulimits predefiniti su OS X?

Sotto Leopard il processo iniziale è launchd. Le ulime predefinite di ogni processo sono ereditate da launchd. Per riferimento sono i limiti predefiniti (compilati)

$ 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

Per modificare uno di questi limiti, aggiungi una riga (potrebbe essere necessario creare prima il file) /etc/launchd.conf, gli argomenti sono gli stessi passati al launchctlcomando. Per esempio

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

Tuttavia launchdha già avviato la shell di accesso, quindi il modo più semplice per rendere effettive queste modifiche è riavviare il nostro computer. (Usa >> per aggiungere a /etc/launchd.conf.)

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

non funziona perché sudo è nel posto sbagliato, prova questo:

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

Limiti di shell

Le risorse disponibili per la shell e i processi possono essere modificate dal ulimitcomando che può essere aggiunto a script di avvio come ~/.bashrco ~/.bash_profileper singoli utenti o /etc/bashrcper tutti gli utenti . Riga di esempio da aggiungere:

ulimit -Sn 4096 && ulimit -Sl unlimited

^{Vedi: help ulimite man bashper maggiori informazioni.}

Limiti di sistema

In generale, i limiti di sistema sono controllati dal framework Launchd e possono essere modificati tramite launchctlcomando, ad es

launchctl limit maxfiles 10240 unlimited

Per rendere persistenti le modifiche, è necessario creare un file dell'elenco delle proprietà in specifiche cartelle conformi a Launch che funga da agente di avvio.

Ecco il comando di esempio che crea tale file di avvio:

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"

Il file verrebbe caricato all'avvio del sistema, tuttavia, per essere eseguito manualmente:

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

Per verificare i limiti di corrente, eseguire: launchctl limit.

^{Vedi: Creazione di demoni e agenti di lancio .}

Limiti del kernel

• I limiti del kernel sono controllati dal sysctlcomando.
• Per vedere i limiti attuali del kernel, eseguire: sysctl -a | grep ^kern.max.
• Per modificare il numero massimo di file permesso di aprire, eseguire: sudo sysctl -w kern.maxfiles=20480.
• Per rendere persistenti le modifiche, utilizzare il metodo precedente simile per creare il file dell'elenco delle proprietà nella cartella di avvio del sistema.

Relazionato:

• Come controllare costantemente il massimo consumo di risorse di sistema su Mac?
• Quale comando controlla i limiti del file aperto?

Metodi obsoleti

Nella versione precedente di macOS, è possibile impostare questi limiti in tutto il /etc/sysctl.confsistema come normalmente su Unix, tuttavia sembra che non sia supportato.

Utilizzando ~/.launchd.confo /etc/launchd.confsembra che non sia supportato in nessuna versione esistente di macOS. ^wiki

Lo stesso con il /etc/rc.localfile di avvio, non è supportato su 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
%

Ora devo scoprire perché esistono 2 mezzi per controllare / impostare i limiti ....

Va bene - sembra ulimite sysctldare un senso falso positivo che effettivamente fanno qualcosa - ma invece sembrano essere inutili . Qualcuno potrebbe verificarlo?

Ok, sto cominciando a capire. A partire dalla v10.4, non esiste initpiù alcun processo, è stato sostituito da launchd, che funziona anche con un PID di 1.

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

E naturalmente vale la pena ricordare che ulimitè una shell integrata, launchctlè un programma indipendente dalla shell.

Su OS X, se stai provando a modificare i limiti software per un demone, un processo o un'attività, il modo giusto per cambiare questi limiti software non è cambiando la configurazione di avvio predefinita per tutti i processi, ma impostandola per il processo che stai cercando di correre.

Ciò si ottiene nel file .plist di launchd per il processo.

Se hai un demone o un processo in esecuzione per il quale devi avere più file aperti, crea un file plist per esso e aggiungi questi parametri:

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

Un esempio, usando mongodb. Creo un file .plist chiamato org.mongo.mongodb.plist e lo salvo in /Library/LaunchDaemons/org.mongo.mongodb.plist. Il file è simile al seguente:

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

Ora il tuo processo ha le risorse di cui ha bisogno, senza confondere con la configurazione globale per il sistema. Questo verrà automaticamente impostato al riavvio. Oppure, se non si desidera riavviare, è possibile eseguire

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

Se il tuo processo o attività è più un agente che un demone, puoi invece inserire .plist in / Library / LaunchAgents. Si applicano regole diverse per il modo in cui launchd controllerà il processo in entrambi i casi. LaunchDaemons sembra riservato ai processi che launchd cercherà di tenere il passo in ogni momento.

Quanto segue dovrebbe risolvere la maggior parte delle soluzioni (e sono elencate in ordine di gerarchia):

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

Gli appunti:

1. Sarà necessario riavviare per rendere effettive queste modifiche.
2. AFAIK non puoi più impostare limiti su "illimitato" in OS X.
3. I maxfile launchctl sono delimitati da maxfile sysctl e quindi non possono superarli
4. sysctl sembra ereditare kern.maxfilesperproc dai maxfile launchctl
5. ulimit sembra ereditare il suo valore di 'file aperti' da launchctl per impostazione predefinita
6. è possibile impostare un ulimit personalizzato all'interno di / etc / profile o ~ / .profile; mentre ciò non è necessario, ho fornito un esempio
7. Prestare attenzione quando si imposta uno di questi valori su un numero molto elevato rispetto al loro valore predefinito: le funzionalità esistono stabilità / sicurezza. Ho preso questi numeri di esempio che ritengo ragionevoli, scritti su altri siti web.
8. Quando i limiti di launchctl sono inferiori a quelli di sistema, sono stati segnalati casi in cui i limiti di sistema rilevanti verranno aumentati automaticamente per soddisfare i requisiti.

La mia esperienza è che il mio compito ad alto numero di processi è riuscito solo con:

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

kern.maxprocperuid=2048

ulimit -u 2048

I primi due possono andare in /etc/sysctl.confe il valore ulimit in launchd.conf, per un'impostazione affidabile.

Poiché tcp / ip faceva parte di ciò che stavo facendo, avevo anche bisogno di fare un salto di qualità

kern.ipc.somaxconn=8192

dal suo valore predefinito 128.

Prima di aumentare i limiti del processo, stavo ottenendo errori "fork", non abbastanza risorse. Prima di aumentare kern.ipc.somaxconn, stavo ricevendo errori "pipe spezzata".

Questo mentre eseguivo un discreto numero (500-4000) di processi distaccati sul mio mostro Mac, OS 10.5.7, quindi 10.5.8, ora 10.6.1. Sotto Linux sul computer dei miei capi ha funzionato.

Ho pensato che il numero di processi sarebbe stato più vicino a 1000, ma sembra che ogni processo che ho avviato includesse la propria copia della shell oltre all'elemento reale che faceva il lavoro effettivo. Molto festoso.

Ho scritto un giocattolo da esposizione simile a:

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

e ho visto il numero massimo di processi in ps -ef e in giro in netstat in attesa TIME_WAITdi scadere ... Con i limiti aumentati, ho visto 3500+ TIME_WAIToggetti al massimo.

Prima di innalzare i limiti, potevo "avvicinarmi di soppiatto" alla soglia di errore, che iniziava sotto 1K ma saliva a un valore elevato di 1190 .. ogni volta che veniva spinto in errore poteva richiedere un po 'di più la prossima volta, probabilmente a causa di qualcosa memorizzato nella cache che si espande al limite ogni volta che fallisce.

Sebbene il mio caso di test avesse un "attesa" come ultima affermazione, c'erano ancora MOLTI processi distaccati in giro dopo la sua uscita.

Ho ottenuto la maggior parte delle informazioni che ho usato dai post su Internet, ma non tutte erano accurate. Il tuo chilometraggio può variare.