53

In macOS, the system is limited to running no more than 1064 processes systemwide, and individual users are limited to 709. Why is there a limit? Why is it this size? Why not a round number like 2500 or a binary round number like 1024?

Update: The limit actually varies in size depending on the version of OS X/macOS and the amount of memory installed in the computer. 1064 is a common limit, but not the only one a Mac might have.

  • 7
    This question and answer addresses why specifically the limit on the number of processes in macOS is 1064 and not, say, 1024 or 2500. Unlike the question macOS Sierra: ulimit maxproc only 2500, it is not intended to address the question of why ulimit limits max. processes per user to 2500 or why setting ulimit to 2500 does not, in fact, allow you to run 2500 processes. Those answers are attached to that question. – Old Pro Oct 21 at 17:50
79

As far as I can tell, the answer is part of the long history of computing.

macOS is based on Darwin, which is the core of Apple's operating system, and which itself is based on xnu, which is a hybrid of FreeBSD layered over Mach, which are based on... until you go back really far to, I don't know, Ada Lovelace? Believe it or not, that is an oversimplification of the macOS history, but it covers the points needed to understand what follows.

In the days when FreeBSD was being developed, memory was expensive, so there was strong incentive to use as little as possible, but not so expensive that you could not build a system shared by a University department. The idea was to have 1 computer that could be used by many people at once, and even if the memory was expensive, the users were only consuming was some memory and disk space, rather than a whole computer, so you wanted to be able to serve as many people as you could without compromising the whole system.

The kernel has a section of memory reserved to hold information for each process, and the size of that table was what limited the total number of processes the system could run at once, so you wanted to keep that table as small as possible, but at the same time big enough to run enough processes to serve all your users. Other kernel memory reservations, such as the number of buffers allocated to store network traffic temporarily, also needed to scale with the number of concurrent users, so FreeBSD introduced a tuning parameter called MAXUSERS, which was not a real limit on how many users the system would handle, but rather a tuning parameter that you set to indicate the maximum number of users you intended to handle at one time. It adjusted the balance between memory allocated to the kernel and memory available to the users.

Prior to graphical user interfaces, individual users on a Unix system typically ran very few processes. They ran a terminal shell, which maybe ran an editor, an email program, a compiler, and some other program, each of which was one process. The email program and compiler would run some other processes. At some point someone estimated that a user would likely need to run no more than 16 processes at once.

Someone (probably the same person) estimated that the system itself could be safely limited to about 20 processes.

This provided the basis for scaling the size of the process table based on the number of concurrent users the system would support:

#define NPROC (20 + 16 * MAXUSERS)

At the time Apple incorporated xnu into their system (and presumably at the time xnu forked from FreeBSD) MAXUSERS defaulted to 32. With 32 users, NPROC was 532. And so it was in OS X 10.0. 532 was the systemwide limit on the total number of processes. Individual users were limited to half that: 266.

And so it remained, until OS X 10.7 Lion, at which point Apple added a scale factor. (Actually, it had has a scale factor long before Lion for Server Performance Mode, but with Lion they extended it a bit to normal mode.) If your computer is running Lion or later and has 3 GiB or more of memory, then maxproc is doubled, and maxprocperuid, which is a fraction of maxproc, goes up even more. maxproc goes from 532 to 1064 and maxprocperuid goes from 266 (maxproc / 2) to 709 ((maxproc * 2) / 3).

And so you get your modern day (10.7 Lion through 10.12 Sierra) limits of 709 processes per user and 1064 processes systemwide.

Fortunately, those limits are going up. If your computer is running macOS 10.13 High Sierra or later and has at least 12 GiB memory, then you get macproc = 532 * memory / 4 GiB up to a max of 8512. In any case, at least now you know why maxproc is a multiple of 532 rather than the more common 512 or 500.

If you want to increase your limits further, you have to switch to server mode. You can read more about how to do that and why at Fix “fork: resource temporarily unavailable” on OS X. You can read a lot of details about what server mode really gives you at What does serverperfmode=1 actually do on macOS?

  • 29
    I like how your second paragraph sounds extremely convoluted and yet still doesn't even remotely cover the strange and complex history of macOS (I mean OSX (I mean Mac OS X (I mean Rhapsody (I mean OPENSTEP (I mean NeXTStep))))). – Jörg W Mittag Oct 20 at 20:32
  • 6
    en.wikipedia.org/wiki/Unix#/media/File:Unix_history-simple.svg @JörgWMittag looks like some steps are missing or combined together – ankii Oct 20 at 20:49
  • 8
    @JörgWMittag The last part of your comment (I mean ...))))) looks like an extract from some bizarre lisp code :) – Aleks G Oct 21 at 14:11
  • 1
    The scaling factor for non-server configs can actually yield a scaling factor > 2 now, given that the machine has >8GB RAM (see the code at bottom of this file: opensource.apple.com/source/xnu/xnu-4903.241.1/osfmk/kern/…). With 64GB of RAM, this yields a maxproc value of 8512. – Siguza Oct 22 at 22:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .