¿Dónde se especifican los ulimits predeterminados en OS X (10.5)?

El nofilelímite predeterminado para las cuentas de usuario de OS X parece ser de unos 256 descriptores de archivos en estos días. Estoy tratando de probar algún software que necesita muchas más conexiones que las abiertas a la vez.

En una caja típica de Debian que ejecuta el módulo de límites de pam, editaría /etc/security/limits.confpara establecer límites más altos para el usuario que ejecutará el software, pero estoy desconcertado sobre dónde establecer estos límites en OS X.

¿Hay una GUI en algún lugar para ello? ¿Hay un archivo de configuración en algún lugar para ello? ¿Cuál es la forma más ordenada de cambiar los límites predeterminados en OS X?

Bajo Leopard el proceso inicial es launchd. Los ulimits predeterminados de cada proceso se heredan de launchd. Como referencia, los límites predeterminados (compilados) son

$ 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

Para cambiar cualquiera de estos límites, agregue una línea (es posible que primero necesite crear el archivo) /etc/launchd.conf, los argumentos son los mismos que se le pasaron al launchctlcomando. Por ejemplo

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

Sin embargo, launchdya ha comenzado su shell de inicio de sesión, por lo que la forma más sencilla de hacer que estos cambios surtan efecto es reiniciar nuestra máquina. (Use >> para agregar a /etc/launchd.conf.)

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

no funciona porque sudo está en el lugar equivocado, intente esto:

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

Límites de la cáscara

Los recursos disponibles para el shell y los procesos pueden ser cambiados por ulimitcomandos que se pueden añadir a los scripts de arranque como ~/.bashrco ~/.bash_profilepara usuarios individuales o /etc/bashrcpara todos los usuarios . Ejemplo de línea para agregar:

ulimit -Sn 4096 && ulimit -Sl unlimited

^{Ver: help ulimity man bashpara más información.}

Límites del sistema

En general, los límites del sistema están controlados por Launchd framework y se pueden cambiar mediante un launchctlcomando, p. Ej.

launchctl limit maxfiles 10240 unlimited

Para que los cambios sean persistentes, debe crear un archivo de lista de propiedades en carpetas específicas compatibles con Launch que actúe como agente de inicio.

Aquí está el comando de ejemplo que crea dicho archivo de inicio:

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"

Sin embargo, el archivo se cargaría en el inicio del sistema para cargarlo y ejecutarlo manualmente:

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

Para verificar los límites actuales, ejecute: launchctl limit.

^{Consulte: Creación de demonios de lanzamiento y agentes .}

Límites del núcleo

• Los límites del núcleo están controlados por el sysctlcomando.
• Para ver los límites actuales del núcleo, ejecute: sysctl -a | grep ^kern.max.
• Para cambiar el máximo de archivos autorizados a abrir, ejecute: sudo sysctl -w kern.maxfiles=20480.
• Para que los cambios sean persistentes, utilice el método anterior similar para crear el archivo de lista de propiedades en la carpeta de inicio del sistema.

Relacionado:

• ¿Cómo controlar constantemente el consumo máximo de recursos del sistema en Mac?
• ¿Qué comando controla los límites de archivos abiertos?

Métodos obsoletos

En una versión anterior de macOS, podría establecer estos límites en todo el /etc/sysctl.confsistema como lo hace normalmente en Unix, sin embargo, parece que no es compatible.

Usando ~/.launchd.confo /etc/launchd.confparece que tampoco es compatible con ninguna versión existente de macOS. ^wiki

Lo mismo con el /etc/rc.localarchivo de inicio, no es compatible con 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
%

Ahora tengo que encontrar por qué existen 2 medios para verificar / establecer límites ...

Bien, parece ulimity sysctlda una falsa sensación positiva de que realmente hacen algo, pero en cambio parecen ser inútiles . ¿Alguien podría verificar eso?

Bien, estoy empezando a entender. A partir de v10.4, ya no hay ningún initproceso, ha sido reemplazado por launchd, que también se ejecuta con un PID de 1.

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

Y, por supuesto, vale la pena mencionar que ulimites un shell incorporado, launchctles un programa independiente del shell.

En OS X, si está intentando modificar los límites de software para un demonio o proceso o tarea, la forma correcta de cambiar estos límites de software no es cambiando la configuración de lanzamiento predeterminada para todos los procesos, sino configurándola para el proceso. tratando de correr

Esto se logra en su archivo launchd .plist para su proceso.

Si tiene un demonio o proceso en ejecución para el que necesita tener más archivos abiertos, cree un archivo plist y agregue estos parámetros:

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

Un ejemplo, usando mongodb. Creo un archivo .plist llamado org.mongo.mongodb.plist y lo guardo en /Library/LaunchDaemons/org.mongo.mongodb.plist. El archivo se ve así:

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

Ahora su proceso tiene los recursos que necesita, sin interferir con la configuración global del sistema. Esto se configurará automáticamente al reiniciar. O, si no desea reiniciar, puede ejecutar

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

Si su proceso o tarea es más un agente que un demonio, puede colocar el .plist en / Library / LaunchAgents en su lugar. Se aplican diferentes reglas sobre cómo launchd controlará su proceso en cualquier caso. LaunchDaemons parece reservado para los procesos que launchd intentará mantenerse al día en todo momento.

Lo siguiente debería resolver la mayoría de las soluciones (y se enumeran en orden de jerarquía):

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

Notas:

1. Deberá reiniciar para que estos cambios surtan efecto.
2. AFAIK ya no puede establecer límites a 'ilimitado' en OS X
3. launchctl maxfiles están delimitados por sysctl maxfiles y, por lo tanto, no pueden superarlos
4. sysctl parece heredar kern.maxfilesperproc de launchctl maxfiles
5. ulimit parece heredar su valor 'abrir archivos' de launchctl por defecto
6. puede establecer un ulimit personalizado dentro de / etc / profile, o ~ / .profile; Si bien esto no es obligatorio, he proporcionado un ejemplo
7. Tenga cuidado al establecer cualquiera de estos valores en un número muy alto en comparación con su valor predeterminado: las características existen estabilidad / seguridad. He tomado estos números de ejemplo que creo que son razonables, escritos en otros sitios web.
8. Cuando los límites de launchctl son más bajos que los de sysctl, ha habido informes de que los sysctl relevantes se aumentarán automáticamente para cumplir con los requisitos.

Mi experiencia es que mi tarea de alto conteo de procesos solo tuvo éxito con:

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

kern.maxprocperuid=2048

ulimit -u 2048

Los dos primeros pueden entrar /etc/sysctl.confy el valor ulimit en launchd.conf, para una configuración confiable.

Como tcp / ip era parte de lo que estaba haciendo, también necesitaba aumentar

kern.ipc.somaxconn=8192

desde su defecto 128.

Antes de aumentar los límites del proceso, recibía fallas de "bifurcación", recursos insuficientes. Antes de aumentar kern.ipc.somaxconn, recibía errores de "tubería rota".

Esto fue mientras ejecutaba un número justo (500-4000) de procesos separados en mi monstruosa Mac, OS 10.5.7, luego 10.5.8, ahora 10.6.1. Bajo Linux en la computadora de mis jefes, simplemente funcionó.

Pensé que el número de procesos estaría más cerca de 1000, pero parece que cada proceso que comencé incluía su propia copia del shell además del elemento real que realizaba el trabajo real. Muy festivo

Escribí un juguete de exhibición que decía algo así como:

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

y vi el número máximo de procesos en ps -ef y dando vueltas en netstat esperando a TIME_WAITque expiraran ... Con los límites elevados, vi más de 3500 TIME_WAITartículos en su punto máximo.

Antes de elevar los límites, podía "escabullirme" en el umbral de falla, que comenzó por debajo de 1K pero aumentó a un alto valor de 1190 ... cada vez que fue empujado al fracaso, podría tomar un poco más la próxima vez, probablemente debido a algo caché que se expandió a su límite cada vez que falló.

Aunque mi caso de prueba tenía una "espera" como su declaración final, todavía había MUCHOS procesos separados que esperaban después de salir.

Obtuve la mayor parte de la información que utilicé de las publicaciones en Internet, pero no toda fue precisa. Tu kilometraje puede variar.