linux – 如何为在Debian Jessie上运行的守护进程提高文件描述符的最大数量?

前端之家收集整理的这篇文章主要介绍了linux – 如何为在Debian Jessie上运行的守护进程提高文件描述符的最大数量?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在使用pgBouncer作为Postgresql的连接池系统.我的系统是12核,64GB RAM和运行Debian 8.1的1Gbps网络接口.现在我想提高开放套接字连接的限制,比如10.000并发客户端.在进行数据库基准测试时,pgbench实用程序会阻塞大约950个并发客户端,这似乎达到了1024个开放fds的限制,就像过去那样.我检查了fs.file-max内核参数和运行用户资源限制的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
$

但是,来自proc的限制显示pgBouncer(作为用户postgres运行)的最大打开文件的软限制仅为1024个最大打开文件

$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
$

我尝试通过在/ etc / default / pgbouncer中插入ulimit -S -n 5000来提高限制(通过/etc/init.d中的启动/停止脚本读入),但这不起作用.然后我在/etc/security/limits.conf中尝试了nofile设置并确保它在PAM中启用,但无济于事.

那么,start-stop-daemon究竟在哪里降低了守护程序进程的nofile限制?我为Debian偶然发现了这个old bug report,但似乎补丁从未被应用过.

顺便说一句:fs.file-max是否真的取代了以前系统的nofiles(注意复数)内核变量,如许多关于调优的博客文章中所建议的那样?让我想知道它是在fs参数部分.在我的IRIX系统上,它在资源部分被称为rlimit_no_files_max,这对我来说比把它放在fs部分更有意义.

我在这里做错了什么? Debian 8.1中为守护进程更改此参数的正确位置在哪里?

提前致谢,

斯特凡

解决方法

您可以在pgbouncer init脚本的“start”部分中使用“ulimit”:

/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 ...]

添加此行后,应在重新启动后发生效果

这样做,或者你被大喊:

# systemctl daemon-reload

然后:

# /etc/init.d/pgbouncer restart

更新:

我的原始答案显示你可以在init脚本中添加“ulimit”,适用于Debian 8.尽管Deb8是一个systemd发行版,但是pgbouncer的默认安装仍然使用了init脚本.

对于使用systemd完全管理pgbouncer的Centos7,您希望使用systemd.service文件.

首先,在Centos7上pgbouncer的默认服务文件中似乎存在一个错误,你需要将“Type = forked”改为“Type = simple”.

在pgbouncer.service文件中,您还可以在[Service]部分添加“LimitNOFILE = ##”…

/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/554A7105.1050002@gmx.net
    Type=simple

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

可能值得验证打开文件的最大数量是瓶颈.您可以检查日志,实际上是“太多打开文件错误消息.在我超过允许打开文件的最大数量的每种情况下,该过程都抱怨…

/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

我们不需要担心pgbench的可用FD,因为如果它们还不够,pgbench将无法运行:

$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.

猜你在找的Linux相关文章