Page 2 – Increasing the Processes Limit
Page 2 – Upping the Ante on Processes
Now we can create a similar file to increase the processes limit. Still in Terminal, type this command:
sudo nano /Library/LaunchDaemons/limit.maxproc.plist
Again, you’ll be in a text editor. Copy and paste this content into the file, the same way you did previously for maxfiles.
<?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>Label</key> <string>limit.maxproc</string> <key>ProgramArguments</key> <array> <string>launchctl</string> <string>limit</string> <string>maxproc</string> <string>2048</string> <string>4096</string> </array> <key>RunAtLoad</key> <true /> <key>ServiceIPC</key> <false /> </dict> </plist>
Press Control-X to save and close the text editor, then you can type exit to leave Terminal.
Finally, reboot your Mac and check the results by issuing the commands we used earlier to check our current limits, the sysctl and ulimit lines. In my case, on a mid–2010 Mac Mini, the maximum processes increased, but not to the limits I configured. Both ulimit -a and sysctl kern.maxfilesperproc revealed a limit of 1064 processes. My assumption is that is the most my Mac can handle, but do let me know if you run into the same limitation.
Use your Mac as normally for a few hours to ensure nothing goes awry. That way, you can quickly reverse your changes by deleting the files we created and rebooting. Once you know everything is working fine, you can re-enable SIP.
Turning SIP Back On
Back to Recovery Mode we go. You need to again restart your Mac, and hold Command-R until the Apple logo appears. When Recovery Mode has loaded, open Terminal and run this command:
csrutil enable
That will turn System Integrity Protection back on.
Keep On Cruising
You can, of course, adjust those limits to whatever you believe might be reasonable. Be cautious not to get overzealous, however. Those limitations are there to protect your operating system from rogue applications that are poorly written and might leak memory like a sieve. You don’t want to go too overboard, or you might find your system slowing to a crawl when it runs out of RAM.
Nice information, but it isn’t necessary to disable and reenable SIP, so you can avoid the multiple reboots, making this a lot less painful. You can create the plist in place by just doing:
This will make the file’s owner be root:wheel, as needed. You then invoke launchctl to load the new settings:
You can confirm your hard maxfiles limit, before and after, as you noted:
And you can confirm your soft maxfiles limit, before and after, with:
Bonjour,
Je possède un macbook de mi-2012, et je n’arrive pas à augmenter le nombre de fichiers.
Lorsque je copie dans la zone de texte le texte suivant
<! DOCTYPE plist PUBLIC “- // Apple // DTD PLIST 1.0 // EN” http://www.apple.com/DTDs/PropertyList-1.0.dtd
Label </ key>
limit.maxfiles </ string>
ProgramArguments </ key>
launchctl </ string>
limite </ string>
maxfiles </ string>
64000 </ string>
524288 </ string>
</ Array>
RunAtLoad </ key>
ServiceIPC </ key>
</ Dict>
</ Plist>
Quand je sauvegarde, je dois mettre quoi comme nom de sauvegarde?
One of the things you missed in this is that changing the limits to increase the number of open files can cause slowdowns without a reboot. Even turning SIP off and on, your dynamic reallocation of the uproc (user process; see the ps command) and file tables will cause a remapping of kernel memory. In the case of the Mach microkernel, the SIP process will have to reorganize and relink driver entry points in order to maintain the open file list.
It is always better to decrease the number of open files than increase them. However, if you are running into open file limits, I would highly recommend that you avoid getting caught by reducing the number of open files… or figure out who is opening more files than necessary, such as a program that is opening multiple sockets to a single server. If you are the developer, you may want to consider a better implementation or, if you are using web-based services, might want to consider setting Keep-Alive to true and reusing the same open connection!
You can only enabled or disable SIP by rebooting, so it’s impossible to carry out these instructions without rebooting.
However, there is a way to accomplish this without messing with SIP or rebooting, so I wonder how much of an issue this will be in that case.
The third command down should be
Not “ulist -a”
Thanks, John! I aim to please 😀
Holy caramba! What a uber geeky article! Kudos Jeff. Love it!