Onde estão os ulimits padrão especificados no OS X (10.5)?

O nofilelimite padrão para contas de usuário do OS X parece ser de cerca de 256 descritores de arquivo atualmente. Estou tentando testar algum software que precise de muito mais conexões do que as abertas de uma só vez.

Em uma caixa Debian típica executando o módulo de limites de pam, eu editaria /etc/security/limits.confpara definir limites mais altos para o usuário que executará o software, mas estou confuso sobre onde definir esses limites no OS X.

Existe uma GUI em algum lugar para isso? Existe um arquivo de configuração em algum lugar para isso? Qual é a maneira mais organizada de alterar os ulimits padrão no OS X?

Sob o Leopard, o processo inicial é launchd. Os ulimits padrão de cada processo são herdados launchd. Para referência, os limites padrão (compilados) são

$ 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 alterar qualquer um desses limites, adicione uma linha (talvez seja necessário criar o arquivo primeiro) para /etc/launchd.conf, os argumentos são os mesmos que foram passados ​​para o launchctlcomando. Por exemplo

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

No entanto launchd, já iniciou seu shell de login, portanto, a maneira mais simples de fazer essas alterações entrar em vigor é reiniciar nossa máquina. (Use >> para anexar ao /etc/launchd.conf.)

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

não funciona porque o sudo está no lugar errado, tente o seguinte:

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

Limites de Shell

Recursos disponíveis para o shell e os processos podem ser alterados pelo ulimitcomando que pode ser adicionado a scripts de inicialização, como ~/.bashrcou ~/.bash_profilepara usuários individuais ou /etc/bashrcpara todos os usuários . Exemplo de linha a ser adicionada:

ulimit -Sn 4096 && ulimit -Sl unlimited

^{Veja: help ulimite man bashpara mais informações.}

Limites do sistema

Em geral, os limites do sistema são controlados pela estrutura Launchd e podem ser alterados por launchctlcomando, por exemplo

launchctl limit maxfiles 10240 unlimited

Para tornar as alterações persistentes, você precisa criar um arquivo de lista de propriedades em pastas específicas compatíveis com o Launch que atuam como um agente de inicialização.

Aqui está o comando de exemplo que cria esse arquivo de inicialização:

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"

O arquivo seria carregado no lançamento do sistema, no entanto, para carregar para executar manualmente:

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

Para verificar os limites atuais, execute: launchctl limit.

^{Consulte: Criando daemons e agentes de inicialização .}

Limites do kernel

• Os limites do kernel são controlados pelo sysctlcomando
• Para ver os limites atuais do kernel, execute: sysctl -a | grep ^kern.max.
• Para alterar o máximo de arquivos permitido abrir, execute: sudo sysctl -w kern.maxfiles=20480.
• Para tornar as alterações persistentes, use o método semelhante acima para criar o arquivo de lista de propriedades na pasta de inicialização do sistema.

Palavras-chave:

• Como controlar persistentemente o consumo máximo de recursos do sistema no Mac?
• Qual comando controla os limites de arquivo aberto?

Métodos preteridos

Na versão anterior do macOS, era possível definir esses limites em todo o /etc/sysctl.confsistema, como normalmente no Unix, no entanto, parece que não há suporte.

O uso ~/.launchd.confou /etc/launchd.confparece que ele também não é suportado em nenhuma versão existente do macOS. ^wiki

Mesmo com o /etc/rc.localarquivo de inicialização, ele não é suportado no 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
%

Agora eu tenho que descobrir por que existem dois meios de verificar / definir limites ....

Ok - parece ulimite sysctldá uma sensação falso-positiva de que eles realmente fazem alguma coisa - mas, em vez disso, parecem inúteis . Alguém poderia verificar isso?

Ok, estou começando a entender. A partir da v10.4, não há initmais processo, ele foi substituído por launchd, que também é executado com um 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

E, claro, vale a pena mencionar é que ulimité um shell embutido, launchctlé um programa independente do shell.

No OS X, se você estiver tentando modificar os limites flexíveis para um daemon ou processo ou tarefa, a maneira correta de alterar esses limites flexíveis não é alterando a configuração padrão launchd para todos os processos, mas definindo-o para o processo em que está. tentando correr.

Isso é realizado no seu arquivo launchd .plist para o seu processo.

Se você possui um daemon ou processo em execução para o qual precisa de mais arquivos abertos, crie um arquivo plist para ele e adicione esses parâmetros:

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

Um exemplo, usando o mongodb. Eu crio um arquivo .plist chamado org.mongo.mongodb.plist e salve-o em /Library/LaunchDaemons/org.mongo.mongodb.plist. O arquivo fica assim:

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

Agora seu processo tem os recursos necessários, sem mexer na configuração global do sistema. Isso será configurado automaticamente na reinicialização. Ou, se você não quiser reiniciar, poderá executar

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

Se o seu processo ou tarefa for mais um agente do que um daemon, você poderá colocar o .plist em / Library / LaunchAgents. Regras diferentes se aplicam para como o launchd controlará seu processo nos dois casos. O LaunchDaemons parece reservado para processos que o launchd tentará acompanhar o tempo todo.

O seguinte deve resolver a maioria das soluções (e são listadas na ordem de sua hierarquia):

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. Você precisará reiniciar para que essas alterações entrem em vigor.
2. AFAIK, você não pode mais definir limites para 'ilimitado' no OS X
3. launchctl maxfiles são limitados por sysctl maxfiles e, portanto, não podem excedê-los
4. O sysctl parece herdar o kern.maxfilesperproc do launchctl maxfiles
5. ulimit parece herdar o valor de 'arquivos abertos' do launchctl por padrão
6. você pode definir um ulimit personalizado dentro de / etc / profile ou ~ / .profile; Embora isso não seja necessário, forneci um exemplo
7. Seja cauteloso ao definir um desses valores para um número muito alto quando comparado com o padrão - os recursos existem estabilidade / segurança. Peguei esses números de exemplo que considero razoáveis, escritos em outros sites.
8. Quando os limites do launchctl são mais baixos do que os do sysctl, houve relatos de que os limites relevantes do sysctl serão aumentados automaticamente para atender aos requisitos.

Minha experiência é que minha tarefa de alta contagem de processos só conseguiu:

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

kern.maxprocperuid=2048

ulimit -u 2048

Os dois primeiros podem entrar /etc/sysctl.confe o valor ulimit em launchd.conf, para uma configuração confiável.

Como tcp / ip fazia parte do que eu estava fazendo, eu também precisava aumentar

kern.ipc.somaxconn=8192

do seu padrão 128.

Antes de aumentar os limites do processo, eu estava recebendo falhas de "bifurcação", sem recursos suficientes. Antes de aumentar o kern.ipc.somaxconn, eu estava recebendo erros de "tubo quebrado".

Isso ocorreu durante a execução de um número razoável (500-4000) de processos desanexados no meu monstro Mac, OS 10.5.7, depois 10.5.8, agora 10.6.1. No Linux, no computador dos meus chefes, funcionava.

Eu pensei que o número de processos estaria mais próximo de 1000, mas parece que todo processo iniciado incluía sua própria cópia do shell, além do item real realizando o trabalho real. Muito festivo.

Eu escrevi um brinquedo de exibição que era algo 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

e observei o número máximo de processos no ps -ef e circulando no netstat esperando TIME_WAITexpirar ... Com os limites aumentados, vi mais de 3500 TIME_WAITitens no pico.

Antes de aumentar os limites, eu podia 'esgueirar-me' do limiar de falha, que começava abaixo de 1K, mas subia para um valor alto de 1190 .. toda vez que era introduzido na falha, poderia demorar um pouco mais na próxima vez, provavelmente por causa de algo em cache que se expandia ao limite toda vez que falhava.

Embora meu caso de teste tivesse uma "espera" como declaração final, ainda havia MUITOS processos desanexados por aí depois que ele saiu.

Eu recebi a maioria das informações que usei de postagens na internet, mas nem todas eram precisas. Sua milhagem pode variar.