我正在使用 Postgresql 8.3 在 Python 中编写一个应用程序，该应用程序在本地网络上的多台机器上运行。
所有机器
1）从数据库服务器获取大量数据（假设数据库在 2 秒内从一台机器获取 100 个不同的查询），大约有 10 或 11 台机器在做这件事。
2）处理数据后，机器必须更新某些表（每台机器每 1.5 秒大约 3 或 4 个更新/插入查询）。
我注意到的是，由于服务器异常中止进程或冻结服务器机器（需要硬重置），数据库有时会出现故障。
顺便说一句，所有机器始终保持与数据库的恒定连接，即一旦使用 Psycopg2（在 Python 中）建立连接，它就会保持活动状态，直到处理完成（可能持续数小时）。
处理应用程序中大量连接的最佳/最佳方式是什么，是否应该在每次查询后销毁它们？
其次我应该增加 max_connections 吗？
非常感谢您对此事的任何建议。
这听起来有点像您的数据库服务器可能有一些问题，特别是如果您的数据库服务器真的崩溃了。我首先尝试从日志中找出问题的根本原因。这可能类似于内存不足，但也可能由于硬件故障而发生。
如果您在开始时打开所有连接并保持打开状态，max_connections那不是罪魁祸首。您处理数据库连接的方式应该很好，并且无论您的服务器如何配置，都不应该这样做。
最可能的原因确实听起来像内存不足。如果这些是 Linux 服务器，则触发内存不足情况会调用“OOM-killer”，它只会终止内存占用进程（因此“服务器异常中止进程”）。内存不足的情况通常意味着非常高的磁盘交换/分页负载，这使得服务器看起来没有响应。
查看您的内核日志文件（或dmesg命令）以获取类似“ Out of Memory: Killed process 1234 (postgres)”的任何内容。这是由允许内核过度使用内存的默认值引起的。您应该做的第一件事是禁用过度使用，以允许优雅地处理内存不足的情况：
echo 2 > /proc/sys/vm/overcommit_memory
计划A：
一个可能的罪魁祸首是work_mem指定每个单独操作可以分配多少内存的设置。一个查询可能包含多个内存密集型步骤，因此除了全局设置之外，每个后端都可以分配几倍的work_mem内存量。此外，您还需要一些空闲内存用于操作系统缓存。shared_buffers
有关更多信息，请参阅有关资源消耗设置的 PostgreSQL 手册：PostgreSQL 8.3 文档，资源消耗
B计划：
减少这些可调参数可能会大大降低您的查询速度，以至于您仍然无法完成任何工作。另一种方法是人为地限制可以并行运行的查询数量。许多PostgreSQL 的连接池中间件可以限制并行查询的数量，并提供队列。该软件的示例是pgbouncer（更简单）和pgpool-II（更灵活）。
编辑：回答你的问题：
处理应用程序中大量连接的最佳/最佳方式是什么，是否应该在每次查询后销毁它们？
一般来说，与 PostgreSQL 建立新连接并不快，因为 PostgreSQL 为每个后端生成一个新进程。但是，进程在内存方面并不便宜，因此保持与数据库的许多空闲连接不是一个好主意。
我在B 计划中提到的连接池中间件将负责保持与 Postgres 的合理数量的连接——无论您何时或多久连接或断开与池器的连接。因此，如果您选择该路线，则无需担心手动打开/关闭连接。
其次我应该增加 max_connections 吗？
除非您的数据库服务器有大量 RAM（超过 8GB），否则我不会超过 100 个连接的默认限制。