21

Today I just noticed that my process IDs are very high, in the 400,000 (i.e 449624). When I run ps -ef | more, that's when I noticed it. Is that normal or does that indicate a problem? Otherwise the scripts are running fine.

I am using Redhat 7.3 x64 bit.

One other thing I noticed is that we also have Redhat 7.2 and the pids are not that high, just on newer OS. Why would that be? Does it mean it's OS related and normal?

I don't have that kernel_pid_max in my sysctl.conf. I ran cat /proc/sys/kernel/pid_max and I see 458752.

ctrl-alt-delor
  • 27,993
user5352090
  • 319
  • You don't have kernel_pid_max in your sysctl.conf because it should be kernel.pid_max. – JRFerguson Feb 12 '19 at 22:23
  • Large process IDs just mean you've started a lot of processes since the machine was booted. Each time a process is started, the kernel assigns the next available process ID larger than the most recently used one, rolling over when you reach the maximum. – chepner Feb 13 '19 at 13:56

3 Answers3

21

At boot, the kernel adjusts the default pid_max depending on the number of CPUs available. When the number is low, the usual 32768 is selected. Else the calculation is done as follows (showing here a 3.10 kernel to be similar to RHEL but beside some variations it's the same for any recent Linux kernel):

include/linux/threads.h:

/*
 * This controls the default maximum pid allocated to a process
 */
#define PID_MAX_DEFAULT (CONFIG_BASE_SMALL ? 0x1000 : 0x8000)

0x8000 = 32768 is the usual value used on systems with less than 32 cpu threads available.

and later:

#define PIDS_PER_CPU_DEFAULT    1024

Those values are then used in kernel/pid.c:

int pid_max = PID_MAX_DEFAULT;

and later:

    /* bump default and minimum pid_max based on number of cpus */
    pid_max = min(pid_max_max, max_t(int, pid_max,
                PIDS_PER_CPU_DEFAULT * num_possible_cpus()));
    pid_max_min = max_t(int, pid_max_min,
                PIDS_PER_CPU_MIN * num_possible_cpus());
    pr_info("pid_max: default: %u minimum: %u\n", pid_max, pid_max_min);

So from OP this should mean a total of 458752/1024 = 448 simultaneous threads available: quite a lot. The other system has probably not as many CPUs/cores/threads etc., so has a lower default pid_max.

A.B
  • 36,364
  • 2
  • 73
  • 118
  • 1
    example: SuperServer 7089P-TR4T has 224 cores so 448 threads. – A.B Feb 13 '19 at 13:29
  • My Ubuntu laptop has only 8 threads CPU (Intel i7-7700HQ), yet sysctl -n kernel.pid_max reports 4194304. – qwr Jun 30 '22 at 04:28
  • @qwr my laptop running Debian has only 2 cores 4 threads, and has high values. This is a newer change from previous kernels (which wasn't happening with the same laptop when I wrote this answer). I guess checking the same sources I quoted would show differences, but OP's RHEL 7.x with kernel 3.10.x wouldn't change its behavior. – A.B Jun 30 '22 at 11:24
  • On modern Linux distributions, the Linux distribution and not the Linux kernel chooses the default max_pid, and chooses it to be 2^22. In fact, it's not even each Linux distribution who made this choice independently, and it was the systemd guys who made this choice for everyone, in 2019: See https://github.com/systemd/systemd/commit/0e0d424c0f5e1b8cff32ed51033ee6e2f70a5676 – Nadav Har'El Jun 26 '23 at 07:58
  • 1
    @NadavHar'El that's right (eg: it doesn't depend on the number of cpus anymore on my current system) but at the time I made this answer, it hadn't changed yet. – A.B Jun 26 '23 at 17:51
17

From the proc documentaton :

On 32-bit platforms, 32768 is the maximum value for pid_max. On 64-bit systems, pid_max can be set to any value up to 2^22 (PID_MAX_LIMIT, approximately 4 million).

You can see the with cat /proc/sys/kernel/pid_max. You can also query this with sysctl.

sudo sysctl -a | grep kernel.pid_max

Or:

sysctl -n kernel.pid_max

Modify /etc/sysctl.conf to change the value permanently and reload with sysctl -p.

Community
  • 1
JRFerguson
  • 14,740
7

A process ID can be any value represented by the pid_t type, which is specific to your operating system. In practice, it is usually a 32-bit signed integer, which means the maximum process ID would be 2147483647, or approximately 5000 times larger than the process IDs you're observing.

The GNU documentation says:

Data Type: pid_t

The pid_t data type is a signed integer type which is capable of representing a process ID. In the GNU C Library, this is an int.

In practice, the kernel will usually enforce an upper limit which is lower than that. On a Linux system, this is controlled by /proc/sys/kernel/pid_max, which defaults to 32768. If your system is Linux, you can check that file to see what the current limit is.

The limit may be different on different operating systems; for example, it appears that on macOS, PID_MAX is hardcoded as 99999.

Daniel Pryden
  • 209
  • 3
    Linux has fundamental API reasons pids can't fill a 31-bit space; the top 2 bits (in addition to the sign bit) are reserved for special purposes in the robust futex and PI futex interfaces. That leaves only 29 bits, for a 512M pid space. – R.. GitHub STOP HELPING ICE Feb 13 '19 at 00:54
  • 1
    @R.: Sure, that's true for Linux. But when I wrote this answer, the question didn't specify Linux, and so I gave an answer for any Unix. As far as I know, there is nothing in the POSIX standard that requires a particular size for pids; it seems unnecessary now but I could imagine a future system where pid_t was 64-bits in size. – Daniel Pryden Feb 13 '19 at 14:15
  • Indeed that's all true. – R.. GitHub STOP HELPING ICE Feb 13 '19 at 15:53
  • The default of 32786 seems to be out-of-date. On current RHEL and Ubuntu, /proc/sys/kernel/pid_max is 4194304. – Jeff Learman Nov 16 '23 at 18:36