Comment contrôler de manière persistante la consommation maximale de ressources système sur Mac?

Question

Avant Mavericks, je pouvais utiliser /etc/launchd.conf fichier pour modifier la consommation maximale des ressources système, par exemple:

limit maxfiles 16384 unlimited limit maxproc 16384 unlimited

Cela ne fonctionne plus dans Mavericks.

Quelle est la bonne façon de procéder dans la version récente d'OS X?

Kiwy · Answer

Il semble que la création du fichier /etc/launchd.conf et y mettre votre commande devrait faire l'affaire.

Si cela ne fonctionne pas, vous pouvez probablement modifier ou créer le /etc/rc.local fichier et ajoutez votre commande à l'intérieur car il y a peu de chances que Apple supprime jamais le support de limit sur la ligne de commande.

Modifier 1 :
J'aurais dû commencer par ça, le launchd page de manuel référence les fichiers suivants:

 ~/Library/LaunchAgents Per-user agents provided by the user. /Library/LaunchAgents Per-user agents provided by the administrator. /Library/LaunchDaemons System-wide daemons provided by the administrator. /System/Library/LaunchAgents Per-user agents provided by Mac OS X. /System/Library/LaunchDaemons System-wide daemons provided by Mac OS X.

Je parie que vous devez maintenant mettre votre commande soit dans ~/Library/LaunchAgents ou dans /Library/LaunchDaemons.
Vous devriez essayer les deux.

Édition 2 :
Sachez également que launchd a besoin d'un fichier xml et pas seulement de scripts. un gui a été conçu pour aider dans une telle tâche non libre on est Lingon . Peut-être que d'autres produits gratuits existent.

pixelass · Answer

Je viens d'ajouter ces deux lignes dans mon .bash_profile
fonctionne comme un charme

ulimit -n 1024 ulimit -u 1024

kenorb · Answer

Limites du système

Modification des limites dans /etc/launchd.conf ou /etc/rc.local n'est plus pris en charge pour la version récente de macOS. Voir: Anciens systèmes et technologies .

Au lieu de cela, vous devez créer un nouveau agent de lancement .

Voici l'exemple de commande utilisant la commande PlistBuddy (voir: man PlistBuddy):

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"

Et similaire pour maxproc limit:

Sudo /usr/libexec/PlistBuddy /Library/LaunchAgents/com.launchd.maxproc.plist \ -c "add Label string com.launchd.maxproc" \ -c "add ProgramArguments array" \ -c "add ProgramArguments: string launchctl" \ -c "add ProgramArguments: string limit" \ -c "add ProgramArguments: string maxproc" \ -c "add ProgramArguments: string 2000" \ -c "add ProgramArguments: string unlimited" \ -c "add RunAtLoad bool true"

Pour charger les fichiers ci-dessus, exécutez: Sudo launchctl load /Library/LaunchAgents/com.launchd.*.plist.

Remarques:

Pour imprimer le fichier, exécutez: cat ou PlistBuddy -x -c Print /Library/LaunchAgents/com.launchd.maxfiles.plist.
Pour vérifier le journal des erreurs pendant le chargement, exécutez: tail -f /var/log/system.log.
Pour voir les limites actuelles de launchd, exécutez: launchctl limit.
Le .plist file peut être placé dans un dossier d'agent par utilisateur ou à l'échelle du système (LaunchAgents). Voir: man launchd et man launchd.plist , ou ceci ou que répondez pour plus de détails.

Limites du noyau

Veuillez noter que ci-dessus Launchd les limites du système sont toujours limitées par le noyau, vous ne pouvez donc pas les définir plus haut que les limites réelles définies dans les variables d'état du noyau (voir: man sysctl pour aider).

Pour voir les limites actuelles du noyau, exécutez: sysctl -a | grep ^kern.max.

Pour augmenter la limite maxfiles, exécutez: Sudo sysctl -w kern.maxfiles=20480.

Pour les faire persister, utilisez la méthode similaire pour créer une startup .plist fichiers, par exemple.

Sudo /usr/libexec/PlistBuddy /Library/LaunchAgents/com.kern.maxfiles.plist \ -c "add Label string com.kern.maxfiles" \ -c "add ProgramArguments array" \ -c "add ProgramArguments: string sysctl" \ -c "add ProgramArguments: string -w" \ -c "add ProgramArguments: string kern.maxfiles=20480" \ -c "add RunAtLoad bool true"

Limites du shell

Pour les limites du shell, ajoutez la commande ulimit appropriée dans ~/.bashrc ou ~/.bash_profile fichier de démarrage pour un utilisateur individuel, ou /etc/bashrc pour tous les utilisateurs. Voir: Comment ajouter des paramètres ulimit Shell persistants sur Mac?

Lignes suggérées à ajouter:

# Changes the ulimit limits. ulimit -Sn 4096 # Increase open files. ulimit -Sl unlimited # Increase max locked memory.

Old Pro · Answer

Si vous avez un seul programme qui atteint un ulimit (une limite douce sur le nombre de fichiers qu'un seul processus peut ouvrir), l'ajustement de ulimit à un nombre plus élevé est correct, surtout si vous pouvez simplement mettre la commande ulimit dans votre .bash_profile. Au-delà de cela, je déconseille fortement de modifier des fichiers comme /etc/launchd.conf ou /etc/sysctl.conf ou en ajoutant des fichiers plist sous /Library/LaunchDaemons/ pour plusieurs raisons.

Les modifications apportées à ces fichiers persistent dans les sauvegardes et sont transférées vers les nouvelles versions de macOS et les nouveaux ordinateurs lors de la mise à niveau.
Si ces modifications causent des problèmes (ce qui est une possibilité réelle), vous devez vous rappeler que vous avez effectué les modifications et quelles sont les modifications, puis rééditer les fichiers pour les annuler. Cela peut arriver des années plus tard.
Après quelques années de mise à niveau, vous constaterez peut-être que ce qui était auparavant une augmentation d'une limite est maintenant une diminution d'une limite. Mais vous ne le saurez probablement pas car vous (a) ne vous souviendrez pas que vous avez fait le changement et (b) ne verrez pas les nouvelles limites parce que vous les avez dépassées depuis le début.

Une bien meilleure option

En général, plutôt que de régler des paramètres individuels sur le système et de déséquilibrer le système (et de laisser potentiellement un seul programme planter le système en occupant toutes les ressources), si les limites système par défaut sont insuffisantes pour vos besoins, je recommande de turing sur "Server Performance Mode", ou du moins en essayant. Tout ce dont vous avez besoin pour cela est OS X/macOS 10.8 Mountain Lion ou version ultérieure et au moins 16 GiB de mémoire installée. Au début, vous deviez payer pour cela, mais en commençant par OS X 10.8 Mountain Lion , c'est gratuit et officiellement pris en charge par Apple avec le système d'exploitation standard.

L'activation de ce mode augmente considérablement les limites du système, en particulier le nombre de processus que vous pouvez exécuter et le nombre de fichiers que vous pouvez ouvrir, au prix d'allouer plus de mémoire au noyau du système. Vous pouvez lire en détail ce qui est modifié par le mode de performance du serveur dans la réponse à la question "Que fait réellement serverperfmode = 1 sur macOS?" .

Ce mode présente plusieurs avantages par rapport à la modification des fichiers de configuration, comme suggéré par d'autres réponses.

Il s'agit d'un changement d'un seul paramètre, facile à annuler.
Il en résulte un ensemble équilibré de limites plus élevées, préservant les garanties contre les processus malveillants faisant planter le système.
Dans la plupart des cas, il fournit des limites plus élevées que le noyau ne le permettrait autrement, même avec l'édition des fichiers de configuration.
Il augmente les limites par défaut pour tous les processus sans aucune modification de configuration supplémentaire.
À partir d'OS X 10.11 El Capitan, la modification de configuration est stockée dans la NVRAM, ce qui signifie que si cela cause des problèmes, vous reviendrez au mode normal lorsque vous effectuerez l'étape de dépannage de la réinitialisation de la NVRAM. Vous n'avez pas à vous en souvenir.
Parce qu'il est en NVRAM, il ne changera pas accidentellement lors de la restauration à partir de sauvegardes.
Parce qu'il est en NVRAM, il ne s'allumera pas automatiquement lorsque vous clonerez votre configuration Mac vers un nouveau matériel.
Parce qu'il est officiellement pris en charge par Apple, "cela fonctionne" et vous ne recevrez pas de plaintes de Apple Geniuses selon lesquelles vous avez incorrectement modifié le système lorsque vous demandez de l'aide.
Comme il s'agit d'un changement d'un seul paramètre, vous pouvez facilement l'activer et le désactiver pour le dépannage ou la comparaison d'un paramètre à l'autre.

Activer ou désactiver le mode de performance du serveur

Pour activer le mode de performances du serveur, utilisez le terminal pour exécuter l'une de ces commandes, puis redémarrez-le pour qu'il prenne effet:

Pour OS X 10.11 El Capitan ou version ultérieure, allumez-le avec

Sudo nvram boot-args="serverperfmode=1 $(nvram boot-args 2>/dev/null | cut -f 2-)"

et éteignez-le avec

Sudo nvram boot-args="$(nvram boot-args 2>/dev/null | sed -e $'s/boot-args	//;s/serverperfmode=1//')"

Les commandes ci-dessus sont ce que Apple recommande officiellement, mais il y a en fait un problème avec elles, c'est que si vous exécutez la commande "allumer" deux fois, vous devez alors exécuter la "éteindre" "commande deux fois pour la désactiver. Vérifiez donc si elle est activée ou désactivée après avoir effectué une modification en exécutant

nvram boot-args

Si la sortie inclut "serverperfmode = 1", le paramètre est activé, et si ce n'est pas le cas, le paramètre est désactivé.

Pour OS X 10.8 Mountain Lion, OS X 10.9 Mavericks et OS X 10.10 Yosemite, activez le mode de performance du serveur avec

serverinfo --setperfmode 1

et éteignez-le avec

serverinfo --setperfmode 0

Vérifiez le réglage avec

serverinfo --perfmode

Le paramètre ne prendra effet qu'après le redémarrage du système.

Vérification pour voir si l'ordinateur s'exécute actuellement en mode de performances du serveur

La vérification du paramètre vous indiquera s'il est configuré pour prendre effet (ou non) après le redémarrage. Pour tester pour voir s'il est actuellement actif (en supposant que vous avez suivi mes conseils et que vous n'avez modifié aucun fichier de configuration qui modifie les paramètres), exécutez

sysctl kern.maxproc

Il vous donnera un nombre qui est le nombre maximum de processus que le système autorisera. Si ce nombre est n multiple de 532 , le mode de performance du serveur est désactivé. S'il s'agit d'un nombre rond (un multiple de 2500), le mode de performances du serveur est activé pour le système en cours d'exécution.