-1

When running this program thread-limit.c on my dedicated debian server, the output says that my system can't create more than around 600 threads. I need to create more threads, and fix my system misconfiguration.

Here are a few informations about my dedicated server:

de801:/# uname -a
Linux de801.ispfr.net 2.6.18-028stab085.5 #1 SMP Thu Apr 14 15:06:33 MSD 2011 x86_64 GNU/Linux
de801:/# java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
de801:/# ldd $(which java)
        linux-vdso.so.1 =>  (0x00007fffbc3fd000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00002af013225000)
        libjli.so => /usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/../lib/amd64/jli/libjli.so (0x00002af013441000)
        libdl.so.2 => /lib/libdl.so.2 (0x00002af01354b000)
        libc.so.6 => /lib/libc.so.6 (0x00002af013750000)
        /lib64/ld-linux-x86-64.so.2 (0x00002af013008000)
de801:/# cat /proc/sys/kernel/threads-max
1589248
de801:/# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 794624
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 10240
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 128
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Here is the output of the C program

de801:/test# ./thread-limit
Creating threads ...
Address of c = 1061520 KB
Address of c = 1081300 KB
Address of c = 1080904 KB
Address of c = 1081168 KB
Address of c = 1080508 KB
Address of c = 1080640 KB
Address of c = 1081432 KB
Address of c = 1081036 KB
Address of c = 1080772 KB
100 threads so far ...
200 threads so far ...
300 threads so far ...
400 threads so far ...
500 threads so far ...
600 threads so far ...
Failed with return code 12 creating thread 637.

Any ideas how to fix this please ?

Joel
  • 195
  • 2
  • 10
  • 1
    Why do you need so many? Anyway, see this question. http://stackoverflow.com/questions/344203/maximum-number-of-threads-per-process-in-linux – Zoredache Nov 21 '11 at 22:30
  • See this: http://stackoverflow.com/questions/1947221/changing-the-limit-of-maximum-number-of-pthreads-by-an-application and that: http://stackoverflow.com/questions/344203/maximum-number-of-threads-per-process-in-linux – ott-- Nov 21 '11 at 22:36
  • thank you, i have already seen each of those links and they don't apply to my problem. none of the solutions proposed changes anything. – Joel Nov 21 '11 at 22:44
  • Is there actually enough allocatable memory on the system to generate more threads? Do you have the results of free? – Matthew Ife Nov 22 '11 at 00:12
  • Yes, there is 2GB available total memory, and 1.7GB available when this bug occurs. – Joel Nov 22 '11 at 00:15
  • 1
    Over on SuperUser, where [this questioner has also spammed this very same programming question](http://superuser.com/questions/360000/), I pointed out that the question has been asked and answered more than seven times on StackOverflow, including twice in August 2010 alone. – JdeBP Nov 24 '11 at 22:57
  • @JdeBP I have asked this question here. Someone has tried to help me on the chat, and has suggested me to post the same question on the other website, which I did. Now stop harassing me on every question and go on with your life. I have a job to do and i am not interested into your weird little game of Hide-and-seek on the Internet. – Joel Nov 24 '11 at 23:13
  • This is nothing to do with systems administration, so I don't know why you were suggested to ask it here. – Mark Henderson Nov 25 '11 at 02:57

3 Answers3

2

You don't need to create more than 600 threads at a time. You only need threads for things you can usefully do at the same time. Your system cannot usefully do more than 600 things at a time. You do not need more threads to do more work.

In any event, you're setting the wrong stack size. You're setting the limiting size of the initial thread stack, the one not created by your code. You're supposed to be setting the size of the stack of the threads your code creates.

Change:

  printf("Creating threads ...\n");
  for (i = 0; i < MAX_THREADS && rc == 0; i++) {
    rc = pthread_create(&(thread[i]), NULL, (void *) &run, NULL);

to (roughly):

  printf("Creating threads ...\n");
  pthread_attr_t pa;
  pthread_attr_init(&pa);
  pthread_attr_setstacksize(&pa, 2*1024*1024);
  for (i = 0; i < MAX_THREADS && rc == 0; i++) {
    rc = pthread_create(&(thread[i]), &pa, (void *) &run, NULL);
  phtread_attr_destroy(&pa);

You can also call pthread_attr_getstacksize to find our your platform's default thread stack size. Note that if a thread exceeds its allocated stack, your process will die.

Even with a 2MB stack, which can be very dangerous, you're still looking at 1.2GB just for stacks to have 600 threads. Whatever your job is, threads are not the right tool for it.

David Schwartz
  • 31,449
  • 2
  • 55
  • 84
  • I executed this code on my server and got the following result: `Failed with return code 12 creating thread 640.`. I also changed the stack size with `pthread_attr_setstacksize(&pa, 128*1024);` and got the following result: `Failed with return code 12 creating thread 635.`. – Joel Nov 21 '11 at 23:56
  • I forgot to mention that this is not my code but a standard linux test that should create 20.000+ threads on any linux. – Joel Nov 21 '11 at 23:58
  • @Joel Can you paste a link to the code as you tested it? If you, for example, missed the change to `pthread_create`, the code won't work as intended. – David Schwartz Nov 22 '11 at 00:02
  • there it it: [thread-limit3.c](http://www.text-upload.com/read.php?id=201706&c=1655830) – Joel Nov 22 '11 at 00:04
  • @Joel On 64-bit Linux, I get up to 10,000 threads with that code, after raising the 'ulimit -u' value to unlimited. – David Schwartz Nov 22 '11 at 00:09
  • Everyone but me gets thousands of threads. This is why I asked this question. Btw my `ulimit -u` is already set to unlimited as you can see in my original question. – Joel Nov 22 '11 at 00:13
  • How much physical memory do you have? How much swap? Have you customized or changed any memory settings such as disabling overcommit? – David Schwartz Nov 22 '11 at 00:46
  • I have 2GB physical memory, and unlimited virtual memory (according to ulimit -v). I haven't changed any memory setting on the OS. – Joel Nov 22 '11 at 02:32
  • I would triple-check that you are compiling and running the exact same code as the code you pasted. – David Schwartz Nov 22 '11 at 02:43
  • Yes I did. Anywway this was just a reproducer code. As you imagine, I am trying to solve this because my real applicative server is crashing due to the actual thread limitation. – Joel Nov 22 '11 at 03:30
  • @Joel : Fix the server so it doesn't need so many threads! There is no way you can usefully do 600 things at the same time, unless you have 100 cores and 100 disk drives. – David Schwartz Nov 22 '11 at 03:38
  • My program uses 3% of the cpu for 300 users. Changing a working program because the OS is badly installed is not a good advice. Thanks anyway. – Joel Nov 22 '11 at 03:41
  • @Joel It's not about CPU use, it's about sanity. And don't blame the OS or its installation -- the specs say you are guaranteed 64 threads. Any more than that is a gift. – David Schwartz Nov 22 '11 at 03:46
-1

This is nothing to do with thread limits. Error code 12 doesnt apply to thread limits.

$ perror 12
OS error code  12:  Cannot allocate memory

I guess if anything your running low on stack, if you set it to the redhat default of 8MB your probably going to be able to run more threads.

This one is the same as the one linked to with explicit stack sizes set to 8MB. See what happens when you compile this one.

/* compile with:   gcc -lpthread -o thread-limit thread-limit.c */
/* originally from: http://www.volano.com/linuxnotes.html */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>
#include <sys/time.h>
#include <sys/resource.h>

#define MAX_THREADS 10000
int i;

void run(void) {
  char c;
  if (i < 10)
    printf("Address of c = %u KB\n", (unsigned int) &c / 1024);
  sleep(60 * 60);
}

int main(int argc, char *argv[]) {
  struct rlimit limits;
  limits.rlim_cur = 1024*1024*8;
  limits.rlim_max = 1024*1024*8;
  if (setrlimit(RLIMIT_STACK, &limits) == -1) {
    perror("Failed to set stack limit");
    exit(1);
  }
  int rc = 0;
  pthread_t thread[MAX_THREADS];
  printf("Creating threads ...\n");
  for (i = 0; i < MAX_THREADS && rc == 0; i++) {
    rc = pthread_create(&(thread[i]), NULL, (void *) &run, NULL);
    if (rc == 0) {
      pthread_detach(thread[i]);
      if ((i + 1) % 100 == 0)
    printf("%i threads so far ...\n", i + 1);
    }
    else
      printf("Failed with return code %i creating thread %i.\n",
         rc, i + 1);
  }
  exit(0);
}
Matthew Ife
  • 23,357
  • 3
  • 55
  • 72
  • i have tried every possible value for the stack size and the limit is always the same. – Joel Nov 21 '11 at 23:12
  • @Joel I altered the provided C to set a stack limit. Since your stack size is pretty small I'm quietly confident that is your issue. Might need to use root to set that limit correctly. – Matthew Ife Nov 21 '11 at 23:28
  • This code sets an 8MB limit on the process initial (legacy) stack. It has no effect on the stacks created for each individual thread -- at the process level, these are data. – David Schwartz Nov 21 '11 at 23:38
  • Thanks for the answer. I am already a root on this machine. And running the code you provided returns the following result: `Failed with return code 12 creating thread 637.`. – Joel Nov 21 '11 at 23:43
  • @David Schwartz. According to the man page "A child process created via fork(2) inherits its parent's resource limits. Resource limits are preserved across execve(2).", an explicit getrlimit in run() proves this is also the case for threads not yet created too. – Matthew Ife Nov 21 '11 at 23:46
  • @MIfe Yes, but this is the limit on the process initial legacy stack. It has no effect on *thread* stacks (which are just data as far as the process is concerned). This is the limit on the *process* stack -- which is used only by the initial thread. The `pthread_create` function allocates *data* (from the process' data pool) to act as stack for the new threads. They don't use the prcess' stack space. – David Schwartz Nov 22 '11 at 00:00
  • @David Schwartz, yes - of course, my post is nonsensical since every thread is allocated its own stack, the result is not cumalative. – Matthew Ife Nov 22 '11 at 00:05
-1

Just got the following information: This is a limitation imposed by my host provider. This has nothing to do with programming, or linux.

Joel
  • 195
  • 2
  • 10
  • So either they're being completely unreasonable, prohibiting a perfectly sensible program from running, or you're being completely unreasonable, claiming that your design is perfectly sensible. – David Schwartz Nov 22 '11 at 17:23
  • yeah whatever you say – Joel Nov 22 '11 at 17:26
  • 1
    On the off chance you are open to reason, please at least take a quick glance at the [actual standard](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html) you are coding to which says "_POSIX_THREAD_THREADS_MAX The number of threads per process. Value: 64". (Other versions, such as SuSv2, say the same thing.) – David Schwartz Nov 22 '11 at 17:32
  • This is a limitation from another time. I could run my custom game server using 2 threads per client and have 3000 simultaneaous players on a first-price machine. So none of this is relevant nowdays. I will move to another host which let me install the standard debian, not a rigged version. – Joel Nov 22 '11 at 17:36
  • Sure, you *could* do that, but it would be silly. You could do it just as well with a pool of 24 threads. You'd use less memory, have fewer context switches, and you wouldn't be relying on behavior that's not guaranteed. You could discover hundreds of sockets ready for I/O with one kernel call, rather than hundreds. That said, I completely agree with you about your host, assuming this is a machine (or virtual machine) that is supposed to be just yours, there is no reason it should have such limits. (But I might agree with them if it's a shared machine or shared VM.) – David Schwartz Nov 22 '11 at 17:38
  • It's sold under the denomination "dedicated server", and it's not a machine, it's in their cloud. They are crooks. – Joel Nov 22 '11 at 17:47
  • @Joel; sorry to hear that it was the host provider. Good luck with finding a new! – KarlP Nov 22 '11 at 19:29
  • @David Schwarts: I don't want to start a flame war, but threads and processes are abstraction that was invented in order to write code oblivious of that the program is running in tiny time slices on a time sharing machine. Following the abstraction, it's not unreasonable to want 100.000 "tasks" to coexist. Unfortunately, most languages and OS:s are not up to the task just yet, but It would make my life simpler if I could just code "business code" without worrying about thread pools and multiplexing. For instance, Erlang,that is built around super thin threads, probably handles 100K threads. – KarlP Nov 22 '11 at 19:42
  • 2
    @KarlP : It is not unreasonable to want 100,000 tasks to coexist -- as you point out, Erlang makes that easy. It is unreasonable to want 100,000 POSIX threads to coexist when POSIX says you get 64 of them. POSIX threads are, by intentional design, heavy. They are just not the right tool for this job. – David Schwartz Nov 22 '11 at 19:46
  • thanks for your help Karl. you helped me a lot in finding out where the pb came from. – Joel Nov 24 '11 at 15:03