web-dev-qa-db-fra.com

Où sont les ulimités par défaut spécifiés sur OS X (10.5)?

La valeur par défaut nofile limite des comptes d'utilisateurs OS X semble être d'environ 256 descripteurs de fichiers ces jours-ci. J'essaie de tester certains logiciels nécessitant beaucoup plus de connexions que cela ouvertes à la fois.

Sur une boîte de Debian typique exécutant le module PAM Limits, je modifierais /etc/security/limits.conf Pour définir des limites plus élevées pour l'utilisateur qui exécutera le logiciel, mais je suis mystifié où définir ces limites dans OS X.

Y a-t-il une interface graphique quelque part pour cela? Y a-t-il un fichier de configuration quelque part pour cela? Quel est le moyen le moyen de modifier les ulimités par défaut sur OS X?

mac-osxulimit
26
archaelus

Sous Léopard, le processus initial est launchd. Les ulimités par défaut de chaque processus sont hérités de launchd. Pour référence, les limites par défaut (compilées) sont

$ 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

Pour modifier l'une de ces limites, ajoutez une ligne (vous devrez peut-être créer le fichier d'abord) à /etc/launchd.conf, les arguments sont les mêmes que transmis à la commande launchctl. Par exemple

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

Cependant launchd a déjà démarré votre shell de connexion, de sorte que le moyen le plus simple de rendre ces modifications à prendre effet est de redémarrer notre machine. (Utiliser >> à ajouter à /etc/launchd.conf.)

27
Dave Cheney
Sudo echo "limit maxfiles 1024 unlimited" >> /etc/launchd.conf

ne fonctionne pas car le sudo est au mauvais endroit, essayez ceci:

echo 'limit maxfiles 10000 unlimited' | Sudo tee -a /etc/launchd.conf
4
andi

Limites de coquille

Les ressources disponibles pour la coquille et les processus peuvent être modifiées par la commande ulimit _ pouvant être ajoutée aux scripts de démarrage tels que ~/.bashrc Ou ~/.bash_profile Utilisateurs individuels ou /etc/bashrc Pour tous les utilisateurs . Exemple de ligne pour ajouter:

ulimit -Sn 4096 && ulimit -Sl unlimited

Voir: help ulimit Et man bash Pour plus d'informations.

Limites du système

En général, les limites du système sont contrôlées par launchd framework et peuvent être modifiés par la commande launchctl, par exemple.

launchctl limit maxfiles 10240 unlimited

Pour apporter les modifications persistantes, vous devez créer un fichier de liste de propriétés dans des fichiers spécifiques lancer des dossiers conformes , qui agit comme agent de démarrage.

Voici l'exemple de commande créant un tel fichier de démarrage:

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"

Le fichier serait chargé au lancement du système, cependant, de charger pour exécuter manuellement:

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

Pour vérifier les limites actuelles, exécutez: launchctl limit.

Voir: Créer des démons et des agents de lancement .

Limites du noyau

  • Les limites du noyau sont contrôlées par la commande sysctl.
  • Pour voir les limites actuelles du noyau, exécutez: sysctl -a | grep ^kern.max.
  • Pour modifier le maximum de fichiers autorisés à ouvrir, exécutez: Sudo sysctl -w kern.maxfiles=20480.
  • Pour rendre les modifications persistantes, utilisez la méthode ci-dessus similaire pour créer le fichier de liste de propriétés dans le dossier de démarrage du système.

En rapport:

Méthodes obsolètes

Dans la version antérieure de MacOS, vous pouvez définir ces limites dans /etc/sysctl.conf À l'échelle du système, comme normalement que vous faites sur UNIX, cependant, il semble qu'il n'est pas pris en charge.

Utilisation de ~/.launchd.conf Ou /etc/launchd.conf Apparaît qu'il n'est également pas pris en charge dans une version existante des macos non plus.wiki

Même avec le fichier de démarrage /etc/rc.local, Il n'est pas pris en charge sur MacOS.

4
kenorb

Sur OS X, si vous essayez de modifier les limites mou pour un démon ou un processus ou une tâche, la bonne façon de modifier ces limites logicielles n'est pas en modifiant la configuration de Launchd par défaut pour Tous Processus, Mais en la fixant pour le processus, vous essayez de courir.

Ceci est accompli dans votre fichier de lancier .Plist pour votre processus.

Si vous avez un démon ou un processus en cours d'exécution que vous devez avoir plus de fichiers ouverts pour cela, créez un fichier de plateau et ajouter ces params à celui-ci:

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

Un exemple, en utilisant mongodb. Je crée un fichier .plist appelé org.mongo.mongodb.plist et enregistrez-le sur /Library/Launchdaemons/org.mongo.mongodb.plist. Le fichier ressemble à ceci:

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

Maintenant, votre processus a les ressources dont il a besoin, sans fumer avec la configuration globale du système. Cela sera automatiquement mis en place sur le redémarrage. Ou, si vous ne voulez pas redémarrer, vous pouvez courir

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

Si votre processus ou votre tâche est plus d'un agent qu'un démon, vous pouvez mettre la place dans/Library/Landagents. Différentes règles s'appliquent à la manière dont LaunchD contrôlera votre processus dans les deux cas. LaunlestDaemons semble réservé aux processus que Lanchant essaiera de suivre à tout moment.

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

Maintenant, je dois trouver pourquoi il existe 2 moyens de vérifier/de définir des limites ....

Ok - on dirait que ulimit et sysctl donner un sentiment faux positif qu'ils font réellement quelque chose - mais ils semblent être inutile. Quelqu'un pourrait-il vérifier cela?

D'accord, je commence à comprendre. À partir de V10.4, il n'y a plus de processus init, il a été remplacé par launchd, qui fonctionne également avec une 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

Et bien sûr mérite d'être mentionné, c'est que ulimit est une coquille intégrée, launchctl est un programme indépendant de coquille.

2
Xerxes

Les éléments suivants doivent résoudre la plupart des solutions (et sont répertoriés dans l'ordre de leur hiérarchie):

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

Remarques:

  1. Vous devrez redémarrer ces changements à prendre effet.
  2. Afaik, vous ne pouvez plus définir des limites à "illimité" sous OS X
  3. launchCtl MAXFILES sont délimités par SYSCTL MAXFILES et ne peuvent donc pas les dépasser
  4. sYSCTL semble hériter de KERN.MAXFileSperProc de LaunchCl MAXFILES
  5. ulimit semble hériter de la valeur "Open Files" de LaunkCtl par défaut
  6. vous pouvez définir un ulimit personnalisé dans/etc/profil, ou ~/.profile; Bien que cela ne soit pas nécessaire, j'ai fourni un exemple
  7. Soyez prudent lors de la définition de ces valeurs à un nombre très élevé par rapport à leur défaut - les fonctionnalités existent la stabilité/la sécurité. J'ai pris ces mêmes numéros que je crois être raisonnables, écrit sur d'autres sites Web.
  8. Lorsque les limites de ReleCktLL sont inférieures à celles du SYSCTL, il a été signalé que les noms de rapport pertinents seront automatiquement heurtés pour répondre aux exigences.
1
errant.info

Mon expérience est que ma tâche de comptage de haut niveau ne réussissait que:

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

kern.maxprocperuid=2048

ulimit -u 2048

Les deux premiers peuvent entrer dans /etc/sysctl.conf et la valeur ulimentaire en launchd.conf, pour un réglage fiable.

Depuis que TCP/IP faisait partie de ce que je faisais, j'ai aussi besoin de casser

kern.ipc.somaxconn=8192

de la valeur par défaut 128.

Avant d'avoir augmenté les limites de processus, je reçois des échecs "fourchettes", pas assez de ressources. Avant d'avoir augmenté Kern.ipc.somaxconn, je reçois des erreurs "tuyaux cassées".

C'était tout en exécutant un nombre équitable (500-4000) de processus détachés sur My Monster Mac, OS 10.5.7, puis 10.5.8, maintenant 10.6.1. Sous Linux sur l'ordinateur de mon patron, il vient de travailler.

Je pensais que le nombre de processus serait plus proche de 1 000, mais il semble que chaque processus que j'ai commencé à inclure sa propre copie de la coque en plus de l'élément réel effectuant le travail réel. Très festif.

J'ai écrit un jouet d'affichage qui a fait quelque chose comme:

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

et regardé le nombre maximum de processus en PS -EF et suspendu à NetStat en attente de TIME_WAIT expirer ... avec les limites soulevées, j'ai vu 3500+ TIME_WAIT articles au sommet.

Avant de soulever les limites, je pouvais "faufiler" sur le seuil d'échec, qui a commencé en dessous de 1 km, mais a augmenté à une valeur élevée de 1190 .. Chaque fois qu'il a été poussé dans une défaillance, il pouvait prendre un peu plus la prochaine fois, probablement à cause de quelque chose mis en cache qui s'est étendu à sa limite à chaque échec.

Bien que mon cas de test ait une "attente" comme dernière déclaration, il y avait encore beaucoup de processus détachés suspendus après sa sortie.

J'ai eu la plupart des informations que j'ai utilisées dans des publications sur Internet, mais tout cela n'était pas précis. Votre miliolier peut varier.

1
Bil Abbott