ITPub博客

首页 > 数据库 > 国内数据库 > SequoiaDB报告创建线程失败的解决办法

SequoiaDB报告创建线程失败的解决办法

原创 国内数据库 作者:OliverFinn 时间:2019-07-09 10:44:28 0 删除 编辑

1. 问题背景

对于分布式数据库和分布式环境,高并发和高性能压力的情况下,出现线程创建失败等等问题也是十分常见的,这时候就十分考虑数据库管理员的经验,需要能快速的定位到问题和瓶颈所在,快速解决。本文也是作为一个最佳实践,告诉大家如何在高并发情况下定位问题,排除问题,解决瓶颈。

 

 

2. 问题定位

SequoiaDB 在集群环境中的 -10 错误码,在认真查阅节点的 diaglog 日志后,发现是操作系统 create thread 失败的问题。

  如我们的测试环境下,SequoiaDB节点的 diaglog 的错误日志信息

阅读这个错误日志的内容,通过看到类似如下的关键信息

  Failed to create new agent: boost::thread_resource_error: Resource temporaily unavailable
Failed to create new agent, probe = 30
Failed to create subagent thread, rc = -10
Failed to start session EDU, rc = -10

 

  那么一般操作系统在创建线程时,会受限于哪些参数呢,主要有几个: 文件句柄数限制、操作系 句柄数限制 内存 源。

 

1 )文件句柄数

linux 操作系 中,号称一切皆 文件,无 程、 线 程、 socker 还是其他,最终都会被操作系统归为文件操作。操作系统或者进程,每申请一个资源,例如线程、 socker ,都会打开一个文件,那么 个文件打开状 ,就可以 简单 理解 文件句柄。 其中,“句柄数限制“代表操作系统或者某个进程所能够打开的最多文件的数量的限制。

 

大家有了这个概念后,我们再来看操作系统是如何对文件句柄数进行限制的。在操作系统中,有一个神奇的命令 - ulimit 这一个命令可以设置许多限制值,进程文件句柄数就是其中之一。

例如我们可以查看 root 用户的 ulimit 输出, -n open file = 1024 就是root 用户允许进程打开的最大文件句柄数。

此处我们需要注意,由于root 用户是Linux 中的管理员用户,所以如果root 用户的 ulimit open file 设置成 1024, 那么其他的用户,例如test、mysql 用户等, 想将 ulimit opon file 设置成 大于 1024,是不行的

因此,普通用户的 ulimit 值修改前,必须要注意root用户的ulimit值,保证普通用户的ulimit值比root用户的设置值小。

 

2 )操作系统句柄数

除了进程中的句柄数限制,整个操作系统的句柄数限制同样会对数据库运行产生影响。在句柄数限制下,因为一个操作系统,总不能无限地打开句柄的。所以又引入另外一个设置,操作系统最大打开的句柄数限制。

这个值在 centos 7 中,是被保存在 /proc/sys/fs/file-max 文件中。

如果操作系统总的句柄数已经达到上限,那么即使进程还没有启动几个线程,也会出现句柄不够的情况。

如果希望临时修改操作系统最大句柄数的设置,可以直接执行,即可: echo  2000000 >  /proc/sys/fs/file-max

如果希望永久修改操作系统最大句柄数的设置,可以编辑  /etc/sysctl.conf 文件,增加 fs.file-max = 2000000 内容,然后在root 用户中执行 sysctl -p 即可。

 

3 )内存

针对内存资源的优化,在创建线程时,在Linux 中,是需要给它预先分配内存的 – 也叫 栈大小,用来存储线程中数据的值。

我们程序员都知道,内存主要分为两个大的部分,一个称为 “堆”,一个称为“栈”。在程序中,“堆”通常是程序用来保存常量和变量名字的,“栈”则通常是程序来用保存具体的变量数字的。

此前我们说到,如果系统内存不足,也是无法创建线程的。这个原因就是在于创建线程时,操作系统需要分配一块内存给线程,这个内存是多大呢,就是 ulimit 中 -s stack size 的大小。如果操作系统连 stack size 大小的内容都无法拿出来了,创建线程就会失败。

整个服务器资源,为什么这么一点内存都没有了?

其实如果仔细查看操作系统,你就会发现,那么多进程,每个进程又是那么多线程在运行,每个线程都在申请内存(注意,这块的内存是物理内存),内存不足正常的很。这个也容易让人联想到JVM 的OOM ,但是他们真的不是一回事,大家千万不要误会。

要解决这个问题也比较简单 – 直接粗暴?就是将 ulimit 中 -s stack size 调小一点,每个线程不要申请那么多内存了,操作系统的内存资源就会更加的充裕。毕竟程序、线程这些,都是用完就完了,不可能都永久占用内存的。

 

3. 其他需要注意的点

除了上述解决方案,仍无法解决创建线程失败的额问题

 

执行 ulimit -a 命令,参数看起来也正常,但是系统是否是完成了设置?我们需要真正确认SequoiaDB进程的ulimit 参数是啥。

确认的方式有两种:

·            sdb 新版本中, 点启 动时 diaglog 日志,会打印它自己的 ulimit 参数, 者可以去翻翻日志

·            另外一种就更加直接,直接 linux 的系 统记录 。例如知道 11910 进程的 PID 123456 ,就直接打开 /proc/123456/limits 文件, 看里面的内容, 这样 想不知道,都

 

4. 备注:关于句柄数和 线 程的命令

  查看 某个进程总共开启了多少个 线程,可以

cat /proc/$PID/status | grep Threads

pstree -p $PID ,然后 +1 ,因 为还 有主

top -Hp $PID ,然后 “Threads” 参数

ps hH p $PID | wc -l

查看linux 目前总打开的句柄数

lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|awk '{print $1}' | awk '{sum += $1};END {print sum}'

查看某个进程打开的总句柄数

lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr |  grep  $PID


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31534344/viewspace-2649927/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-04-27

  • 博文量
    30
  • 访问量
    19685