openGauss报错：Too many open files，解决方案

于 2024-08-29 17:55:04 发布
阅读量411 收藏 2
点赞数 3
文章标签： 数据库 gaussdb openGauss
版权声明：本文为博主原创文章，遵循 CC 4.0 BY 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u010490822/article/details/141684863
版权

操作系统信息

Linux user-pc 5.4.18-87.76-generic #gfb16-KYLINOS SMP Thu Aug 31 09:05:44 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

解决方案

当前使用gsql -d postgres -p 5432 -r命令登录数据的时候，报错如下：

gsql: FATAL:  could not look up local user ID 1002: Too many open files

报错信息 gsql: FATAL: could not look up local user ID 1002: Too many open files指出系统达到了打开文件的数量上限，并且是在尝试查找本地用户ID时发生的。这个问题通常与操作系统的资源限制有关，而不是特定的代码实现问题。
要解决这个问题，你需要增加操作系统允许的文件打开数量。以下是在Linux系统上解决此问题的步骤：

  1. 临时增加文件打开数量限制：
    使用 ulimit 命令临时增加当前会话的文件打开数量限制。
ulimit -n 65535
  1. 永久增加文件打开数量限制：
    编辑 /etc/security/limits.conf 文件，添加或修改以下行来永久增加限制。
   *               soft    nofile          65535
   *               hard    nofile          65535

这里的 * 表示对所有用户生效。你也可以指定特定的用户名来仅对特定用户生效。

  1. 应用限制并重启服务：
    修改完 /etc/security/limits.conf 文件后，你需要重启系统或至少重启受影响的服务（如openGauss数据库服务）来使更改生效。

  2. 检查并关闭不必要的应用程序：
    确保没有不必要的应用程序或服务占用文件句柄。

  3. 优化数据库配置：
    检查并优化openGauss的配置，以减少不必要的文件打开请求。

进一步解决问题

通过上面的步骤一般情况下是可以解决问题的，但是现在我们重启服务后，发现问题依然存在，此时我们查看看一下数据库进程。

omm@user-pc:/media/user/D/datanode/gsdn$ systemctl status openGauss.service 
● openGauss.service - 華為openGauss數據庫服務...
     Loaded: loaded (/etc/systemd/system/openGauss.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2024-08-29 16:28:35 CST; 1h 7min ago
    Process: 180477 ExecStart=/usr/local/bin/gs_ctl start -D /media/user/D/datanode/gsdn (code=exited, status=0/SUCCESS)
   Main PID: 180483 (gaussdb)
      Tasks: 38 (limit: 18929)
     Memory: 2.3G
     CGroup: /system.slice/openGauss.service
             └─180483 /media/user/D/openGauss-server/dest/bin/gaussdb -D /media/user/D/datanode/gsdn

从上面的数据信息可以得到openGauss的进程ID是180483，下面我们统计一下该进程的打开数量。

user@user-pc:~$ sudo lsof -p 180483 | wc -l
输入密码
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
1274

上面的输出信息得到打开数量为1274
我们看一下该进程的limits信息

user@user-pc:~$ cat /proc/180483/limits 
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             63099                63099                processes 
Max open files            1024                 524288               files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       63099                63099                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us

image.png
到此问题找到了，进程实际限制的1024个，但是实际打开了1274个，故报此错误。
由于上面我们已经设置了，但是发现并没有生效，什么原因呢？
猜测有没有可能是被系统级设置覆盖了。

omm@user-pc:/media/user/D/datanode/gsdn$ cat /etc/systemd/system.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See systemd-system.conf(5) for details.

[Manager]
#LogLevel=info
#LogTarget=journal-or-kmsg
#LogColor=yes
#LogLocation=no
#DumpCore=yes
#ShowStatus=yes
#CrashChangeVT=no
#CrashShell=no
#CrashReboot=no
#CtrlAltDelBurstAction=reboot-force
#CPUAffinity=1 2
#NUMAPolicy=default
#NUMAMask=
#RuntimeWatchdogSec=0
#RebootWatchdogSec=10min
#ShutdownWatchdogSec=10min
#KExecWatchdogSec=0
#WatchdogDevice=
#CapabilityBoundingSet=
#NoNewPrivileges=no
#SystemCallArchitectures=
#TimerSlackNSec=
#StatusUnitFormat=description
#DefaultTimerAccuracySec=1min
#DefaultStandardOutput=journal
#DefaultStandardError=inherit
#DefaultTimeoutStartSec=90s
#DefaultTimeoutAbortSec=
#DefaultRestartSec=100ms
#DefaultStartLimitIntervalSec=10s
#DefaultStartLimitBurst=5
#DefaultEnvironment=
#DefaultCPUAccounting=no
#DefaultIOAccounting=no
#DefaultIPAccounting=no
#DefaultBlockIOAccounting=no
#DefaultMemoryAccounting=yes
#DefaultTasksAccounting=yes
#DefaultTasksMax=
#DefaultLimitCPU=
#DefaultLimitFSIZE=
#DefaultLimitDATA=
#DefaultLimitSTACK=
#DefaultLimitCORE=
#DefaultLimitRSS=
#DefaultLimitNOFILE=1024:524288
#DefaultLimitAS=
#DefaultLimitNPROC=
#DefaultLimitMEMLOCK=
#DefaultLimitLOCKS=
#DefaultLimitSIGPENDING=
#DefaultLimitMSGQUEUE=
#DefaultLimitNICE=
#DefaultLimitRTPRIO=
#DefaultLimitRTTIME=

从上面的信息可以看出系统级默认限制是1024个，那我们就更改一下这里的数量，设置为DefaultLimitNOFILE=65535:524288，更新后重启数据库。
再次查看，openGauss进程的limits信息，如下

omm@user-pc:/media/user/D/datanode/gsdn$ cat /proc/180483/limits
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             63099                63099                processes 
Max open files            65535                524288               files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       63099                63099                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us

image.png
查看数据库日志，发现Too many open files错误信息消失，下面我们通过gsql命令工具登录数据库。

omm@user-pc:/media/user/D/datanode/gsdn$ gsql -d postgres -p 5432 -r
gsql ((openGauss 6.0.0 build ) compiled at 2024-08-06 17:27:08 commit 0 last mr  )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.

openGauss=#

image.png
登录成功！
到这里，这个问题也就解决了。

字节熊猫
关注
  • 3
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
mac版Android studio编译报错：Too many open files in system
让技术为我所用
06-14 1896
原因大致因为mac系统有文件打开数上限，随着工程变大，编译时项目中build文件夹下生成文件数量过多，导致打开文件数超过了系统上限。本文章的解决办法是查看并提高这个上限，使编译顺利通过。查看 修改 持久化修改 在文件中...
报错：too many open files处理
04-23
针对“too many open files”错误，我们可以采取以下几种解决方法： 1. **调整系统限制**：可以通过修改`/etc/security/limits.conf`文件来永久性地提高用户或组的文件描述符限制。例如，为所有用户增加限制： ```...
netty报错：too many open files，调整文件句柄
pxzsky的专栏
09-21 419
netty,too many files
Logstash启动报错：Too many open files
weixin_42910346的博客
07-30 612
问题描述： 启动Logstash日志中报：Error: Too many open files - Too many open files 提示打开的文件过多。 解决过程： 查看单个进程允许打开的最大文件句柄数 ulimit -n 显示为默认的1024，需设置较大的数目 设置进程打开的最大句柄个数 a. 临时修改：ulimit -n 10240 只对当前终端有效，重新打开个终端设置无效 b.永久生效：修改文件/etc/security/limits.conf 添加： * soft nofile
opengauss数据库或者postgresql数据库日志报错：too many open files
weixin_44418421的博客
06-26 327
解决too many open files问题
使用命令启动kubelet报错：too many open files
mischen520的博客
12-05 727
解决方案： 首先使用ulimint -n查看系统允许打开的最大文件数，若非65535，建议调整到65535，截图如下： 使用 echo 'ulimit -n 65535'>> /etc/profile source /etc/profile 设置系统最大的文件数为65535 再次使用ulimit -n查看可以看到最大文件数已经调整到65535.如果启动还是报错，则继续下面的步骤： 1.使用lsof命令来列出打开文件存在的进程，若显示一个进程打开文件过多并且该进程用处不大，可以.
java.net.SocketException:Too many open files 解决方案
whb的博客
05-15 2097
java.net.SocketException:Too many open files 解决方案
ambari 中启动kafka 报错：too many open file
m0_65850671的博客
03-13 416
too many open file
pytorch报错：Too many open files
y4ung
05-22 2789
程序运行到一半报了Too many open files的错： ... ... File "/home/miniconda3/envs/gpu/lib/python3.9/multiprocessing/resource_sharer.py", line 48, in __init__ OSError: [Errno 24] Too many open files 参考github上的issue It is expected because the default file_descriptor sh
生产报错：too many open files
BushRo
02-21 1360
生产环境上的定时任务脚本本来在应用上是跑的好好的，突然发现就都失败了，急忙去生产服务器上面看。发现了下面这个报错。 这里的files不单是文件的意思，也包括打开的通讯链接(比如socket)，正在监听的端口等等，所以有时候也可以叫做句柄(handle)，这个错误通常也可以叫做句柄数超出系统限制。 经常在使用linux的时候出现，大多数情况是由于程序没有正常关闭一些资源引起的（比如读写文件），所以出现这种情况，请检查io读写，socket通讯等是否正常关闭。 经过检查并不是资源未关闭而造成的。就怀疑是否当前
centos7.1系统报错：Error: Too many open files
weixin_34056162的博客
06-29 841
2019独角兽企业重金招聘Python工程师标准>>> ...
访问应用很慢，访问Nginx时，报错：accept() failed (24 Too many open files).docx
09-01
在本文中，我们将讨论 Nginx 访问慢和 accept() failed 错误的解决方案。这个问题通常是由于 Nginx 的连接数超过了系统设定的最大值造成的。下面是解决这个问题的方法。 一、临时修改 ulimit 值 可以使用 ulimit ...
JAVA.NET.SOCKETEXCEPTION TOO MANY OPEN FILES解决方法
03-18
JAVA.NET.SOCKETEXCEPTION TOO MANY OPEN FILES解决方法 JAVA.NET.SOCKETEXCEPTION TOO MANY OPEN FILES错误是一种常见的网络编程错误，发生在Java应用程序中， especialmente 在 Linux 操作系统中。该错误的出现是...
Python错误提示：[Errno 24] Too many open files的分析与解决
09-21
在Python编程过程中，可能会遇到一个常见的错误提示：“[Errno 24] Too many open files”。这个错误通常意味着你的程序尝试打开的文件句柄超过了操作系统允许的最大限制。下面我们将深入探讨这个问题的原因、如何...
MySQL 相关知识笔记
weixin_68929783的博客
08-23 2663
以上是根据 B 站黑马课程学习后的 MySQL 笔记，为了日后复习和给别人参考而整理，希望对大家有所帮助。同时，在实际应用中，还需要根据具体情况合理使用索引、约束等功能，以提高数据库的性能和数据的完整性。
修复数据库中的 “Access Denied: SUPER Privilege Required” 错误
xiaochong0302的博客
08-26 708
当您使用数据库时，您可能会看到错误消息：“Access denied; you need (at least one of) the SUPER privilege(s) for this operation”。当您的数据库用户没有足够的权限来执行某些操作时，就会发生这种情况。
汉服文化平台网站
heye0910032的博客
08-26 824
本文主要探讨了使用Java语言开发汉服文化平台网站的全过程。系统采用B/S架构，严格遵循软件开发流程，从分析、设计到实现，确保了项目的系统性和科学性。系统主要面向管理员和用户两大类使用者，提供了包括首页、个人中心、汉服知识管理、服装展示管理、用户相册管理、论坛交流、系统管理、订单管理等功能。本系统的应用，旨在实现汉服文化信息管理的信息化，提高管理效率，方便用户访问和交流。通过本毕业设计，我深入学习并实践了Java语言和SSM框架在Web开发中的应用。
python12 中，No module named‘distutils‘错误
qq_43557600的博客
08-27 3942
python12 “ No module named'distutils' ”,​ 安装 pip install setuptools ，解决 ​
（1）Hilt的基本概念和使用
最新发布
challenge51all的专栏
08-27 725
Jetpack Hilt 是一个强大的依赖注入框架，它简化了 Android 应用中的依赖管理，提高了代码的可维护性和可测试性。通过使用注解和模块，开发人员可以轻松地管理应用中的依赖关系，并在不同的组件之间共享和注入依赖。在应用的 Application 类上使用这个注解，告诉 Hilt 这是一个使用 Hilt 进行依赖注入的应用。Jetpack Hilt 是一个用于 Android 的依赖注入框架，它建立在 Dagger 的基础上，旨在简化 Android 应用中的依赖注入过程。
node.js 报错 EMFILE: too many open files
09-06
这个错误是由于打开的文件描述符数量超过了操作系统限制引起的。在使用 Node.js 进行文件操作时，每个打开的文件都会占用一个文件描述符。当打开的文件描述符数量达到操作系统的限制时，就会出现 EMFILE 错误。 要解决这个问题，有几种方法可以尝试： 1. 增加操作系统的文件描述符限制：可以通过修改操作系统的配置文件来增加文件描述符的限制。具体的方法取决于你使用的操作系统，你可以查阅相关文档了解如何进行调整。 2. 优化代码：检查你的代码，确保在使用完文件后及时关闭文件。可以使用 `fs.close()` 方法来显式关闭文件，或者使用 Promise 或 async/await 来确保在完成文件操作后释放资源。 3. 限制同时打开的文件数量：可以通过限制同时打开的文件数量来减轻负载。你可以在代码中使用适当的控制流程，例如使用队列或限制并发操作。 4. 考虑使用流式处理：如果你处理的是大型文件或需要同时处理多个文件，可以考虑使用流式处理来减少对内存和文件描述符的需求。Node.js 提供了 `stream` 模块，可以帮助你以流的方式处理数据。 希望这些方法能帮助你解决 EMFILE 错误。如果问题仍然存在，请提供更多的上下文信息，以便我能够给出更具体的建议。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值