Como aumentar o número máximo de descritores de arquivos para daemons em execução no Debian Jessie?

Question

Estou jogando com pgBouncer como um sistema de pooling de conexão para o PostgreSQL. Meu sistema é um 12-core com 64GB de RAM e 1Gbps de interface de rede rodando Debian 8.1. Agora quero aumentar o limite para conexões de soquete aberto até, digamos, 10.000 clientes simultâneos. Ao fazer benchmarks DB, os blocos% utility pgbench em cerca de 950 clientes concorrentes, o que parece atingir um limite de 1024 fds abertos, como nos bons velhos tempos. Verifiquei o parâmetro fs.file-max kernel e o limite de recursos do usuário em execução pgbench :

# sysctl fs.file-max
fs.file-max = 6598264
# su - postgres
$ ulimit -Sn
65536
$ fgrep files /proc/self/limits
Max open files            65536                65536                files
$ 

No entanto, os limites de proc mostram que o limite soft para o máximo de arquivos abertos para pgBouncer (executando como usuário postgres ) é de apenas 1024 max arquivos abertos:

$ ps -e | fgrep pgbouncer
 9840 ?        00:00:00 pgbouncer
$ fgrep files /proc/9840/limits
Limit                     Soft Limit           Hard Limit           Units
Max open files            1024                 4096                 files
$

Eu tentei aumentar o limite inserindo ulimit -S -n 5000 em /etc/default/pgbouncer (lido pelo script start / stop em /etc/init.d ), mas isso não funcionou. Então, eu tentei a configuração nofile em /etc/security/limits.conf e verifiquei se ela está ativada no PAM, mas sem sucesso.

Então, onde exatamente o start-stop-daemon diminui o nofile limite para os processos do daemon? Eu tropecei neste antigo relato de erros para o Debian, mas parece que o patch nunca foi aplicado.

BTW: A fs.file-max é realmente a substituição da variável de kernel nofiles do antigo sistema (observe o plural) como sugerido em muitos artigos de blog sobre ajuste? Me faz pensar que está na seção do parâmetro fs . No meu sistema IRIX, ele é chamado de rlimit_no_files_max na seção de recursos, o que faz muito mais sentido para mim do que colocá-lo na seção fs .

O que estou fazendo de errado aqui? Onde é o lugar certo para alterar este parâmetro para daemons na Debian 8.1?

Agradecemos antecipadamente

Stefan

    

Answer 1

Você pode usar "ulimit" na seção "start" do script de inicialização do pgbouncer:

/etc/init.d/pgbouncer:

    [... snip ...]
    case "$1" in
      start)
        # Check if we are still disabled in /etc/default/pgbouncer
        [ "${START:-}" = "0" ] && exit 0
        log_daemon_msg "Starting PgBouncer" $NAME
        test -d $PIDDIR || install -d -o postgres -g postgres -m 2775 $PIDDIR

        ### set whatever limits you want ###
        ulimit -n 20000

        $SSD --start --chuid $RUNASUSER --oknodo -- $OPTS 2> /dev/null
        log_end_msg $?
        ;;
    [... snip ...]

Com esta linha adicionada, os efeitos devem ocorrer após o reinício:

Faça isso ou receba gritos:

# systemctl daemon-reload

Então:

# /etc/init.d/pgbouncer restart

ATUALIZAÇÃO:

Minha resposta original, que mostrou que você pode adicionar "ulimit" ao script init, funciona no Debian 8. Mesmo que Deb8 seja uma distribuição systemd, parece que a instalação padrão do pgbouncer ainda usa o script init.

Para o Centos7, que gerencia o pgbouncer completamente com o systemd, você quer usar um arquivo systemd.service.

Primeiro, parece haver um bug no arquivo de serviço padrão do pgbouncer no Centos7, onde você precisa ter "Type = forked" como "Type = simple".

No arquivo pgbouncer.service, você também pode adicionar um "LimitNOFILE = ##" na seção [Service] ... assim

/etc/systemd/system/pgbouncer.service

    ## good practice to include the default service file as it may change with future updates
    .include /lib/systemd/system/pgbouncer.service

    ## change the Type= per this bug
    ## http://www.postgresql.org/message-id/[email protected]
    Type=simple

    ## Add a service section and set the max number of open files
    [Service]
    LimitNOFILE=12345

Pode valer a pena verificar se o número máximo de arquivos abertos é o gargalo. Você pode verificar seus logs para, essencialmente, mensagens de erro "muitos arquivos abertos". Em cada caso em que excedeu o número máximo de arquivos abertos permitidos, o processo reclamou ...

/var/log/postgresql/pgbouncer.log

ERROR S: login failed: FATAL: could not open relation mapping file (...): Too many open files in system
ERROR S: login failed: FATAL: could not open file (...): Too many open files in system
ERROR S: login failed: FATAL: pipe() failed: Too many open files in system
WARNING sbuf_connect failed: Too many open files in system

/var/log/postgresql/postgresql-9.4-main.log

LOG:  out of file descriptors: Too many open files in system; release and retry
PANIC:  could not open file (...): Too many open files in system
LOG:  server process (...) was terminated by signal 6: Aborted
DETAIL:  Failed process was running: END;
LOG:  terminating any other active server processes

Não precisamos nos preocupar com os FDs disponíveis para o pgbench, porque se eles não forem suficientes, o pgbench não será executado:

$ ulimit -S -n 100
$ pgbench -h 192.168.122.69 -p 6432 -U postgres -d booktown -c 200 -t 10000
You need at least 202 open files but you are only allowed to use 100.
Use limit/ulimit to increase the limit before using pgbench.