DBeaver 启动时未继承系统 ulimit 限制，因其作为 Java 应用由桌面环境或 systemd --user 启动，不经过 PAM 登录流程，故 /etc/security/limits.conf 和终端中执行的 ulimit -n 均无效；必须从快捷方式、systemd 用户服务或 dbeaver.ini 中干预启动上下文。
直接改 ulimit 不管用，DBeaver 启动时没继承系统限制，必须从启动入口干预。
为什么 ulimit -n 65535 对 DBeaver 无效
DBeaver 是 Java 应用，通过 java 命令启动（Linux/macOS 下是 dbeaver 脚本，本质调用 java -jar）。它不运行在你手动执行 ulimit 的那个 shell 里——尤其是你从桌面环境（GNOME/KDE）或 Dock 点击图标启动时，根本不会读 ~/.bashrc 或 /etc/security/limits.conf。
常见错误现象：你在终端里 ulimit -n 65535 再运行 ./dbeaver 是有效的；但双击图标或搜“DBeaver”启动就立刻报 Too many open files，且 lsof -p $(pgrep -f dbeaver) 显示打开数卡在 1024 左右。
- systemd 用户会话（如 Ubuntu 22.04+）默认忽略
/etc/security/limits.conf - DBeaver 桌面快捷方式通常指向
/usr/share/applications/dbeaver.desktop，里面Exec=行没带任何 ulimit 上下文 - Java 进程的
Max open files值，得看它启动那一刻实际拿到的限制，不是你后来ulimit的值
Linux 下真正生效的三种改法
优先级从高到低：桌面快捷方式 > systemd 用户服务 > Java 启动参数。只改一种可能白忙。
- 改
/usr/share/applications/dbeaver.desktop（或用户级~/.local/share/applications/dbeaver.desktop）：
把Exec=行改成：Exec=sh -c 'ulimit -n 65535 && /usr/bin/dbeaver %F'，然后执行sudo update-desktop-database - 如果用 systemd --user 管理 GUI 应用（如 Fedora/CentOS Stream），在
~/.config/systemd/user/dbeaver.service中写：[Service]LimitNOFILE=65536
再运行systemctl --user daemon-reload && systemctl --user restart dbeaver - 在 DBeaver 安装目录的
dbeaver.ini文件末尾加一行：-XX:MaxFDLimit=65536（仅对 OpenJDK 有效，某些 Oracle JDK 忽略该参数）
macOS 上绕过 launchd 限制的关键点
macOS 的 GUI 应用由 launchd 派生，它默认硬编码 soft nofile=256、hard nofile=1024，ulimit 和 limits.conf 完全不生效。
- 必须创建
/Library/LaunchDaemons/limit.maxfiles.plist（需 root）：
里面SoftResourceLimits NumberOfFiles为 65536 - 重启后仍需让 DBeaver 继承：编辑
/Applications/DBeaver.app/Contents/MacOS/dbeaver可执行脚本，在exec java前插入ulimit -n 65536 - 验证是否生效：启动 DBeaver 后，终端执行
lsof -p $(pgrep -f "DBeaver.*java") | wc -l，再对比cat /proc/$(pgrep -f "DBeaver.*java")/limits | grep "Max open files"
排查 DBeaver 自身是否泄漏文件句柄
即使系统限制调高，如果 DBeaver 频繁新建连接又不 close，fd 数仍会缓慢爬升，最终再次触顶。
- 在 DBeaver 设置里关掉「自动保存未提交的编辑」和「后台元数据刷新」（
Preferences → Editors → SQL Editor → Auto-save） - 检查所有数据库连接的「连接池」设置：避免
max connections设得过大（如 50+），尤其连 PostgreSQL/MySQL 时，每个连接至少占 2–3 个 fd - 用
lsof -p $(pgrep -f "DBeaver.*java") | grep -E "\.(sql|log|tmp|sock)" | wc -l看是否有大量残留临时文件或 socket 未释放 - 如果使用 SSH 隧道连接数据库，确认隧道配置里没勾选「保持连接活跃」——这个选项会让 DBeaver 持有额外 socket 且不超时关闭
最易被忽略的是：DBeaver 的「结果集导出」功能（CSV/Excel）若中途取消，可能留下未关闭的 FileOutputStream；连续多次导出失败后，fd 数会明显堆积。这类问题只能靠重启 DBeaver 临时缓解，长期得等官方修复。
