Início / unix / Perguntas / 551491
Accepted
Kingsley
Asked: 2019-11-11 20:54:53 +0800 CST

ulimit para o tamanho da pilha - por processo ou por limite de thread?

  • 772

Portanto, temos um programa no Solaris que estava ficando sem espaço de pilha.

Enquanto investigava isso, dei uma breve olhada no que era ulimit para a pilha:

user@solaris-box:~$ ulimit -a
...
stack size              (kbytes, -s) 8192

Portanto, o limite de tamanho da pilha é de 8 megabytes. Mas esse é o limite para todo o processo?

E se meu processo tiver 10 threads, eles são permitidos apenas 819k por thread? (ou alguma mistura deles, até 8MiB?)

Não consigo encontrar nenhum doco sobre isso.

solaris

1 respostas

  1. Best Answer

    RESUMO

    Para o encadeamento principal, você precisa chamar setrlimit()(talvez usando ulimit) antes que o processo seja iniciado para garantir que o tamanho da pilha maior seja efetivo.

    Para encadeamentos iniciados pelo processo, você precisa usar pthread_attr_setstacksize()como o tamanho da pilha do encadeamento não é afetado pelo stack sizelimite de recursos de setrlimit()/ getrlimit().

    O código precisa ficar mais ou menos assim:

    pthread_attr attr;
pthread_attr_init( &attr );

// 32MB stack size example - should **NOT** hardcode this
// but get it from an environment variable or property setting
size_t stacksize = 32UL * 1024UL * 1024UL;
pthread_attr_setstacksize( &attr, stacksize );

pthread_create( &tid, &attr, start_func, thread_arg );

    Você pode obter o tamanho da pilha de threads do limite de tamanho da pilha atual:

    struct rlimit limits;

getrlimit( RLIMIT_STACK, &limits );
size_t stacksize = limits.rlim_cur; // use rlim_max for hard limit

    (Observe que, se você estiver usando uma biblioteca que cria seus próprios threads, essa biblioteca pode ter seu próprio método documentado para definir o tamanho da pilha de threads, como OpenMPI.)

    RESPOSTA DETALHADA

    Os limites de recursos são definidos na linha de comando pelo ulimitutilitário .

    Se você correr truss -f -a -vall -o /tmp/truss.out /usr/bin/ulimit -a, você verá

    address space limit (kbytes)   (-M)  unlimited
core file size (blocks)        (-c)  unlimited
cpu time (seconds)             (-t)  unlimited
data size (kbytes)             (-d)  unlimited
file size (blocks)             (-f)  unlimited
locks                          (-x)  not supported
locked address space (kbytes)  (-l)  not supported
message queue size (kbytes)    (-q)  not supported
nice                           (-e)  not supported
nofile                         (-n)  1024
nproc                          (-u)  29995
pipe buffer size (bytes)       (-p)  5120
max memory size (kbytes)       (-m)  not supported
rtprio                         (-r)  not supported
socket buffer size (bytes)     (-b)  5120
sigpend                        (-i)  128
stack size (kbytes)            (-s)  8192
swap size (kbytes)             (-w)  not supported
threads                        (-T)  not supported
process size (kbytes)          (-v)  unlimited

    E se você olhar /tmp/truss.out, verá

    7752:   execve("/usr/bin/ulimit", 0xFFFF80FFBFFFF9E8, 0xFFFF80FFBFFFFA00)  argc = 2
7752:    argv: /usr/bin/ulimit -a
7752:   sysinfo(SI_MACHINE, "i86pc", 257)       = 6

  much deleted extraneous data (loading shared libraries, etc)...

7752:   getrlimit(RLIMIT_VMEM, 0xFFFF80FFBFFFD4B0)  = 0
7752:       cur = RLIM64_INFINITY  max = RLIM64_INFINITY
7752:   getrlimit(RLIMIT_CORE, 0xFFFF80FFBFFFD4B0)  = 0
7752:       cur = RLIM64_INFINITY  max = RLIM64_INFINITY
7752:   getrlimit(RLIMIT_CPU, 0xFFFF80FFBFFFD4B0)   = 0
7752:       cur = RLIM64_INFINITY  max = RLIM64_INFINITY
7752:   getrlimit(RLIMIT_DATA, 0xFFFF80FFBFFFD4B0)  = 0
7752:       cur = RLIM64_INFINITY  max = RLIM64_INFINITY
7752:   getrlimit(RLIMIT_FSIZE, 0xFFFF80FFBFFFD4B0) = 0
7752:       cur = RLIM64_INFINITY  max = RLIM64_INFINITY
7752:   getrlimit(RLIMIT_NOFILE, 0xFFFF80FFBFFFD4B0)    = 0
7752:       cur = 1024  max = 65536
7752:   sysconfig(_CONFIG_CHILD_MAX)            = 29995
7752:   pathconf("/", _PC_PIPE_BUF)         = 5120
7752:   pathconf("/", _PC_PIPE_BUF)         = 5120
7752:   sysconfig(_CONFIG_SIGQUEUE_MAX)         = 128
7752:   getrlimit(RLIMIT_STACK, 0xFFFF80FFBFFFD4B0) = 0
7752:       cur = 8388608  max = RLIM64_INFINITY
7752:   getrlimit(RLIMIT_VMEM, 0xFFFF80FFBFFFD4B0)  = 0
7752:       cur = RLIM64_INFINITY  max = RLIM64_INFINITY
7752:   write(1, " a d d r e s s   s p a c".., 942) = 942

    Vemos que ulimitusa as funções da biblioteca getrlimit()(esetrlimit() ) para obter/definir limites de recursos.

    Por página getrlimit()/ setrlimit() man( observe as partes em negrito):

    RLIMIT_STACK

    O tamanho máximo da pilha de um processo em bytes. O sistema não aumentará automaticamente a pilha além desse limite.

    Dentro de um processo, setrlimit()aumentará o limite do tamanho de sua pilha, mas não moverá segmentos de memória atuais para permitir esse crescimento. Para garantir que a pilha de processos possa crescer até o limite, o limite deve ser alterado antes da execução do processo no qual o novo tamanho da pilha será usado .

    Dentro de um processo multithread, setrlimit()não tem impacto no limite de tamanho da pilha para o thread de chamada se o thread de chamada não for o thread principal . Uma chamada para setrlimit()for RLIMIT_STACKafeta apenas a pilha do thread principal e deve ser feita apenas a partir do thread principal, se for o caso.

    O SIGSEGVsinal é enviado para o processo. Se o processo está segurando ou ignorando o SIGSEGV, ou está capturando SIGSEGVe não tomou providências para usar uma pilha alternativa (consulte sigaltstack(2)), a disposição de SIGSEGVserá definida para SIG_DFLantes de ser enviada.

    Portanto, o tamanho da pilha para encadeamentos criados pelo processo que não são o encadeamento principal não é afetado pelo RLIMIT_STACKlimite de recursos do processo. E você precisa chamar setrlimit() ANTES do início do processo (no processo pai) para garantir que qualquer limite de tamanho de pilha maior seja realmente eficaz.

    Pela página pthread_create()man :

    Um novo thread criado com pthread_create()usa a pilha especificada pelo stackaddratributo e a pilha continua pelo número de bytes especificado pelo stacksizeatributo. Por padrão, o tamanho da pilha é de 1 megabyte para processos de 32 bits e 2 megabyte para processos de 64 bits ( consulte Recursospthread_attr_setstacksize(3C) ). Se o padrão for usado para os atributos stackaddre , cria uma pilha para o novo encadeamento com pelo menos 1 megabyte para processos de 32 bits e 2 megabytes para processos de 64 bits. (Para personalizar tamanhos de pilha, consulte NOTAS ).stacksizepthread_create()

    ...

    Notas

    ...

    Um tamanho de pilha especificado pelo usuário deve ser maior que o valor PTHREAD_STACK_MIN. Um tamanho mínimo de pilha pode não acomodar o quadro de pilha para a função de encadeamento do usuário start_func. Se um tamanho de pilha for especificado, ele deve acomodar start_funcos requisitos e as funções que ele pode chamar, além do requisito mínimo.

    Geralmente é muito difícil determinar os requisitos de pilha de tempo de execução para um thread. PTHREAD_STACK_MINespecifica quanto armazenamento de pilha é necessário para executar um arquivo NULL start_func. Os requisitos totais de tempo de execução para armazenamento de pilha dependem do armazenamento necessário para fazer a vinculação de tempo de execução, a quantidade de armazenamento exigida pelos tempos de execução da biblioteca (como printf()) que seu encadeamento chama. Como esses parâmetros de armazenamento não são conhecidos antes da execução do programa, é melhor usar pilhas padrão. Se você conhece seus requisitos de tempo de execução ou decide usar pilhas maiores que o padrão, faz sentido especificar suas próprias pilhas.

    • 4

relate perguntas