PostgreSQL修改最大连接数的详细操作步骤
前言
和PostgreSQL打交道久了,多半都撞见过这个熟悉又头疼的错误:“sorry, too many clients already”。问题出在哪?很简单,默认情况下PostgreSQL把最大连接数设在了100。对个人项目或小规模测试来说,这个数字绰绰有余。可一旦放到生产环境,尤其是面对突发的并发请求时,100个连接就显得捉襟见肘了。
修改最大连接数
想给PostgreSQL“松松绑”,增加连接数上限吗?别担心,流程很清晰,跟着下面这几步走就行。
打开PostgreSQL配置文件
第一步,得找到它的配置文件。不过,文件的藏身之处会因操作系统和PostgreSQL版本的不同而变化。这里有几个常见系统的默认路径:
- Ubuntu/Debian:
/etc/postgresql//main/postgresql.conf - CentOS/RHEL:
/var/lib/pgsql//data/postgresql.conf - macOS (通过Homebrew安装):
/usr/local/var/postgres/postgresql.conf
找到文件后,打开它,我们的目标就是里面那条叫做max_connections的参数。
修改最大连接数
在配置文件里定位到max_connections,然后把值改成你想要的数字。比如,想将上限提升到1000,就把那一行改成:
max_connections = 1000
改完后,别忘了保存文件。
重启 PostgreSQL 服务
光改配置可不行,得让PostgreSQL服务重新加载一下。通常,用下面这个命令就能重启服务:
sudo service postgresql restart
当然,具体命令可能因系统不同略有差异。此外,如果是通过Docker跑的PostgreSQL,那重启的就不是服务,而是容器本身了:
docker restart
验证修改是否生效
重启完成后,怎么确认修改真的生效了呢?很简单,在命令行执行这条查询:
psql -U-c "SHOW max_connections;"
记得把换成你实际的数据库用户名。这条命令会直接返回当前设置的最大连接数。
如果你习惯用图形化工具,比如Na vicat,那更方便。连上数据库后,直接新建一个查询窗口,运行同样的SQL语句就行:
SHOW max_connections;
不过话说回来,有件事必须提醒一下:连接数不是越大越好。盲目调高上限,会消耗更多系统内存和CPU资源。在动手之前,最好先评估一下服务器的硬件配置和实际负载情况。
修改操作系统的文件描述符限制
有时候会碰到一个“坑”:明明在PostgreSQL里把max_connections调高了,但实际还是上不去。这很可能是因为操作系统的“文件描述符限制”在拖后腿。
你可以先运行下面这个命令,看看系统当前的限制是多少:
ulimit -n
如果这个数字比你设定的数据库连接数小,那就得考虑放宽操作系统的限制了。具体怎么操作呢?跟着下面的流程走。
查看当前的 ulimit 最大值
首先,全面了解一下当前的限制情况:
ulimit -a
这个命令会列出包括文件描述符、用户进程数在内的所有ulimit限制。
临时修改 ulimit 最大值
如果想临时试试效果,可以用这个命令(比如将文件描述符数设为65536):
ulimit -n 65536
但要记住,这种方法是临时的,只对当前终端会话有效,一旦退出登录,设置就打回原形了。
永久修改 ulimit 最大值
想要一劳永逸,就得修改系统配置文件。不同系统的配置文件路径如下:
- Ubuntu/Debian / CentOS/RHEL:
/etc/security/limits.conf - macOS:
/etc/launchd.conf
打开对应的文件,然后添加或修改以下几行。比如,为所有用户设置文件描述符和进程数的硬/软限制:
* hard nofile 65536 * soft nofile 65536 * hard nproc 65536 * soft nproc 65536
这里解释一下几个关键符号:
- *:代表对所有用户生效。
- nofile:指最大文件打开数,它直接关系到PostgreSQL能建立多少个连接。
- nproc:指最大进程数。
修改保存后,最稳妥的方式是重启一下系统:
reboot
重启后,再次登录,用ulimit -n命令检查一下,确认新设置已经生效。
最后强调一点:修改系统级的ulimit限制属于高级操作,需要管理员权限。操作前请务必理解其影响,并且记得备份原始配置文件,以防万一。
查询数据库连接情况
除了前面提到的SHOW max_connections;,管理数据库连接时,我们常常需要更细致的信息。这里整理了一套非常实用的查询语句。
查询数据库配置的最大连接数
select setting from pg_catalog.pg_settings where "name" ='max_connections';
查询数据库当前连接信息
SELECT
datname,
pid,
usename,
query_start,
wait_event,
wait_event_type,
state,
query
FROM pg_catalog.pg_stat_activity
ORDER BY query_start DESC;
根据进程 ID 取消正在执行的查询
SELECT pg_cancel_backend(pid);
根据进程 ID 终止指定的连接
这个命令比“取消”更彻底,会直接断开连接:
SELECT pg_terminate_backend(pid);
根据进程 ID 获取连接的详细信息
SELECT pg_stat_get_activity(pid);
查询当前使用的连接数
SELECT COUNT(*) FROM pg_catalog.pg_stat_activity;
查询当前空余连接数
想知道连接池还有多少余量?这个查询很直观:
SELECT
setting::int2 - (SELECT COUNT(*) FROM pg_catalog.pg_stat_activity)
FROM pg_catalog.pg_settings
WHERE "name" ='max_connections';
总结
调高PostgreSQL的最大连接数,是一个从数据库配置到系统层级都需要打通的系统工程。核心步骤就三步:改数据库配置、重启服务、必要时调整系统限制。但关键在于,调整前务必要结合服务器的实际资源,做好性能评估。同时,日常运维中熟练运用那些查询当前连接状态的SQL命令,能让你在问题出现时更快地定位和解决。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
Oracle并行DML提升大批量UPDATE效率详解
首先需要明确一个关键要点:Oracle 的 UPDATE 语句默认完全不支持并行执行,即便你添加了 *+ PARALLEL * 提示也仍然无效——这是数据库的硬性限制,并非配置参数未正确设置。若要利用并行 DML 实现大批量 SQL UPDATE 的显著性能提升,必须深入理解其行为机制。 从根本
SQLite视图模拟动态计算列的实用方法
SQLite没有像PostgreSQL那样内置的GENERATED ALWAYS AS语法,但这并不意味着我们没法实现“计算列”的效果。一个很自然的替代方案就是视图——通过封装SELECT表达式,在查询时动态计算结果。虽然视图不存储数据,但每次查询都能拿到最新计算值,对轻量级项目来说足够用了。 SQ
如何用SQL子查询找出选修所有课程的优等生名单
在数据库查询中,想要精准检索出“选修了全部课程”的学生,很多人都会被这个问题卡住。直接使用IN或EXISTS子查询进行判断,只能确认学生是否“选过某几门课”,而无法证明其“选过每一门课”。这里的关键误区在于,子查询本质上表达的是集合的包含关系,而非全称量化的逻辑。要想准确锁定这类学生,正确的解决思路
SQL Server DDL触发器防止误删数据库表的编写方法
很多人在SQL Server中配置DDL触发器时都会遇到一个常见困惑:明明创建了阻止DROP TABLE的触发器,却依然无法生效。核心问题在于:DDL触发器必须显式启用才能正常工作,创建后不启用就等于没用,这是导致线上操作事故的重要原因。 在SQL Server中,使用CREATE TRIGGER
SQL视图递归深度限制与配置参数调整方法
一张图看清不同数据库对视图嵌套深度和递归CTE的处理差异。 先摆一个残酷的现实:如果你的SQL Server视图嵌套超过32层,编译器会直接甩给你一个Msg 319报错,连执行计划都生成不了。这可不是什么可配置的软限制,而是解析器调用栈的硬上限,发生在编译阶段。换句话说,根本没得商量。 这时你可能会
- 日榜
- 周榜
- 月榜
1
2
3
4
5
6
7
8
9
10
相关攻略
2026-07-04 07:09
2026-07-04 07:08
2026-07-04 07:08
2026-07-04 07:08
2026-07-04 07:08
2026-07-04 07:08
2026-07-04 07:08
2026-07-04 07:07
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程
热门话题

