Número máximo de threads por processo no Linux?

Qual é o número máximo de threads que podem ser criados por um processo no Linux?

Como (se possível) esse valor pode ser modificado?

O Linux não possui um limite de threads separados por processo, apenas um limite para o número total de processos no sistema (os threads são essencialmente apenas processos com um espaço de endereço compartilhado no Linux) que você pode visualizar assim:

cat /proc/sys/kernel/threads-max

O padrão é o número de páginas de memória / 4. Você pode aumentar isso como:

echo 100000 > /proc/sys/kernel/threads-max

Há também um limite no número de processos (e, portanto, threads) que um único usuário pode criar, veja ulimit/getrlimitdetalhes sobre esses limites.

É ERRADO dizer que o LINUX não possui um thread separado por limite de processo.

O Linux implementa o número máximo de threads por processo indiretamente !!

number of threads = total virtual memory / (stack size*1024*1024)

Portanto, o número de threads por processo pode ser aumentado aumentando a memória virtual total ou diminuindo o tamanho da pilha. Porém, diminuir muito o tamanho da pilha pode levar à falha do código devido ao estouro da pilha, enquanto a memória virtual máxima é igual à memória de troca.

Verifique sua máquina:

Memória virtual total: ulimit -v(o padrão é ilimitado, portanto, você precisa aumentar a memória de troca para aumentar isso)

Tamanho total da pilha: ulimit -s(o padrão é 8Mb)

Comando para aumentar estes valores:

ulimit -s newvalue

ulimit -v newvalue

* Substitua o novo valor pelo valor que você deseja colocar como limite.

Referências:

http://dustycodes.wordpress.com/2012/02/09/increasing-number-of-threads-per-process/

Em termos práticos, o limite é geralmente determinado pelo espaço na pilha. Se cada thread obtiver uma pilha de 1 MB (não me lembro se esse é o padrão no Linux), um sistema de 32 bits ficará sem espaço de endereço após 3000 threads (assumindo que o último gb esteja reservado ao kernel) .

No entanto, você provavelmente terá um desempenho terrível se usar mais de algumas dezenas de threads. Cedo ou tarde, você recebe muita sobrecarga de alternância de contexto, muita sobrecarga no agendador e assim por diante. (Criar um grande número de threads faz pouco mais do que consumir muita memória. Mas muitos threads com trabalho real a fazer vão atrasá-lo enquanto eles lutam pelo tempo disponível da CPU)

O que você está fazendo quando esse limite é relevante?

100k threads adequados no linux:

ulimit -s  256
ulimit -i  120000
echo 120000 > /proc/sys/kernel/threads-max
echo 600000 > /proc/sys/vm/max_map_count
echo 200000 > /proc/sys/kernel/pid_max 

 ./100k-pthread-create-app

Atualização de 2018 de @Thomas, nos sistemas systemd:

/etc/systemd/logind.conf: UserTasksMax=100000

@dragosrsupercool

O Linux não usa a memória virtual para calcular o máximo de encadeamento, mas a ram física instalada no sistema

 max_threads = totalram_pages / (8 * 8192 / 4096);

http://kavassalis.com/2011/03/linux-and-the-maximum-number-of-processes-threads/

kernel / fork.c

/* The default maximum number of threads is set to a safe
 * value: the thread structures can take up at most half
 * of memory.
 */
max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);

Portanto, o thread max é diferente entre todos os sistemas, porque o ram instalado pode ser de tamanhos diferentes, sei que o Linux não precisa aumentar a memória virtual, porque em 32 bits temos 3 GB para espaço do usuário e 1 GB para o kernel, em 64 bits, temos 128 TB de memória virtual, que acontecem no Solaris. Se você deseja aumentar a memória virtual, precisa adicionar espaço de troca.

Para recuperá-lo:

cat /proc/sys/kernel/threads-max

Para configurá-lo:

echo 123456789 > /proc/sys/kernel/threads-max

123456789 = # de threads

Limite de contagem de threads:

$ cat /proc/sys/kernel/threads-max 

Como é calculado:

max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);

e: o tamanho da página x86_64 (PAGE_SIZE) é 4K; Como todas as outras arquiteturas, o x86_64 possui uma pilha de kernel para cada encadeamento ativo. Essas pilhas de encadeamento são THREAD_SIZE (2 * PAGE_SIZE) grandes;

para mempages:

cat /proc/zoneinfo | grep spanned | awk '{totalpages=totalpages+$2} END {print totalpages}';

na verdade, o número não está relacionado à limitação do tamanho da pilha de memória de threads (ulimit -s ).

PS: a limitação da pilha de memória de threads é 10M na minha VM rhel e, para a memória 1.5G, essa VM pode pagar apenas 150 threads?

Para quem está vendo isso agora, em sistemas systemd (no meu caso, especificamente no Ubuntu 16.04), existe outro limite imposto pelo parâmetro cgroup pids.max.

Isso é definido como 12.288 por padrão e pode ser substituído em /etc/systemd/logind.conf

Outros conselhos ainda se aplicam, incluindo pids_max, threads-max, max_maps_count, ulimits etc.

verifique o tamanho da pilha por thread com ulimit, no meu caso Redhat Linux 2.6:

    ulimit -a
...
    stack size              (kbytes, -s) 10240

Cada um de seus threads receberá essa quantidade de memória (10 MB) atribuída à sua pilha. Com um programa de 32 bits e um espaço de endereço máximo de 4 GB, isto é, no máximo, apenas 4096MB / 10MB = 409 threads !!! Menos código de programa, menos heap-space provavelmente levará a um máximo observado. de 300 fios.

Você deve conseguir aumentar isso compilando e executando em 64 bits ou configurando ulimit -s 8192 ou mesmo ulimit -s 4096. Mas se isso for recomendável, é outra discussão ...

Provavelmente não deveria importar. Você obterá um desempenho muito melhor projetando seu algoritmo para usar um número fixo de threads (por exemplo, 4 ou 8 se você tiver 4 ou 8 processadores). Você pode fazer isso com filas de trabalho, E / S assíncronas ou algo como libevent.

Use nbio biblioteca de E / S sem bloqueio ou qualquer outra coisa, se precisar de mais threads para fazer chamadas de E / S que bloqueiam

Depende do seu sistema, basta escrever um programa de amostra [criando processos em um loop] e verificar usando ps axo pid, ppid, rss, vsz, nlwp, cmd. Quando ele não pode mais criar threads, verifique nlwp count [nlwp é o número de threads] voila, você obteve sua resposta à prova de idiotas em vez de ler os livros

Para definir permanentemente,

vim /etc/sysctl.conf

e adicione

kernel.threads-max = "value"

Podemos ver o número máximo de threads definidos no seguinte arquivo no linux

cat / proc / sys / kernel / threads-max

(OU)

sysctl -a | grep threads-max

Você pode ver o valor atual com o seguinte comando: cat / proc / sys / kernel / threads-max

Você também pode definir o valor como

eco 100500> / proc / sys / kernel / threads-max

O valor que você definir seria verificado nas páginas de RAM disponíveis. Se as estruturas de encadeamentos ocuparem mais de 1/8) das páginas de RAM disponíveis, o encadeamento máximo será reduzido de acordo.

Sim, para aumentar o número de threads, você precisa aumentar a memória virtual ou diminuir o tamanho da pilha. No Raspberry Pi, não encontrei uma maneira de aumentar a memória virtual, se diminuir o tamanho da pilha do padrão de 8 MB para 1 MB. É possível obter mais de 1000 threads por processo, mas diminuir o tamanho da pilha com o comando "ulimit -s" faça isso para todos os threads. Portanto, minha solução foi usar a instância “pthread_t” “thread class” porque o pthread_t me permitiu definir o tamanho da pilha para cada thread. Por fim, estou disponível para arquivar mais de 1000 threads por processo no Raspberry Pi, cada um com 1 MB de pilha.