当前位置: 首页 > 工具软件 > pam-mongodb > 使用案例 >

mongodb错误记录

洪承天
2023-12-01

1.问题描述

今天在使用MongoDB进行数据插入的时候,出现插入不成功的情况,显示出的异常如下所示:

Interrupted acquiring a permit to retrieve an item from the pool in MongDB
com.mongodb.MongoInterruptedException: Interrupted acquiring a permit to retrieve an item from the pool
    at com.mongodb.ConcurrentPool.acquirePermit(ConcurrentPool.java:172)
    at com.mongodb.ConcurrentPool.get(ConcurrentPool.java:112)
    at com.mongodb.PooledConnectionProvider.get(PooledConnectionProvider.java:75)
    at com.mongodb.DefaultServer.getConnection(DefaultServer.java:61)
    at com.mongodb.BaseCluster$WrappedServer.getConnection(BaseCluster.java:248)
    at com.mongodb.DBTCPConnector$MyPort.getConnection(DBTCPConnector.java:503)
    at com.mongodb.DBTCPConnector$MyPort.get(DBTCPConnector.java:434)
    at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:286)
    at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:271)
    at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:237)
    at com.mongodb.QueryResultIterator.getMore(QueryResultIterator.java:137)
    at com.mongodb.QueryResultIterator.hasNext(QueryResultIterator.java:127)
    at com.mongodb.DBCursor._hasNext(DBCursor.java:551)
    at com.mongodb.DBCursor.hasNext(DBCursor.java:571)
    at org.elasticsearch.river.mongodb.Slurper.run(Slurper.java:125)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.InterruptedException
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1325)
    at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:414)
    at com.mongodb.ConcurrentPool.acquirePermit(ConcurrentPool.java:166)
    ... 15 more

查找了一圈,网上没有很好的解决方案,
github上面的解决方式
stackoverflow解决方式
都不行!最终的解决方式是linux系统的数据库连接数设置太小,当达到连接数的上限时,会出现比较奇怪的问题。
所以在进行服务器系统配置时,尤其涉及到资源连接的服务器配置,应该设置此值。

2.解决方式

修改linux 最大文件限制数 ulimit

1)修改当前交互终端的limit值

查询当前终端的文件句柄数: ulimit -n 回车,一般的系统默认的1024.
修改文件句柄数为65535,ulimit -n 65535.此时系统的文件句柄数为65535.
或者直接修改打开文件的最大数量:

/etc/security/limits.conf
*       -       nofile          1024000

2)将ulimit 值添加到/etc/profile文件中(适用于有root权限登录的系统)

为了每次系统重新启动时,都可以获取更大的ulimit值,将ulimit 加入到/etc/profile 文件底部。
echo ulimit -n 65535 >>/etc/profile
source /etc/profile #加载修改后的profile
ulimit -n #显示65535,修改完毕!

3)再次登录失效

OK,好多朋友都以为大功告成了,可以突然发现自己再次登录进来的时候,ulimit的值还是1024,这是为什么呢?
关键的原因是你登录的用户是什么身份,是不是root用户,由于服务器的root用户权限很大,一般是不能用来登录的,都是通过自己本人的登录权限进行登录,并通过sudo方式切换到root用户下进行工作。 用户登录的时候执行sh脚本的顺序:

/etc/profile.d/file 
/etc/profile 
/etc/bashrc 
/mingjie/.bashrc 
/mingjie/.bash_profile 

由于ulimit -n的脚本命令加载在第二部分,用户登录时由于权限原因在第二步还不能完成ulimit的修改,所以ulimit的值还是系统默认的1024。

解决办法:

修改linux的软硬件限制文件/etc/security/limits.conf.
在文件尾部添加如下代码:

* soft nofile 10240
* hard nofile 10240

4)经过以上修改,在有些系统中,用一般用户再登陆,仍然没有修改过来,那么需要检查是否有如下文件,如果没有,则要添加如下内容:

# vim /etc/pam.d/sshd
[Add the line]
session    required   /lib/security/pam_limits.so
# service sshd restart

5)如果仍然不行,那么需要修改如下文件:

# vim /etc/ssh/sshd_config
[May need to modify or add the line]
UsePrivilegeSeparation no
 类似资料: