DuckDB 内存管理
内容提要
DuckDB默认将系统内存的80%用作缓冲池，在2GB容器中易被OOM杀死。其数据块、哈希表和排序缓冲均从单一缓冲池分配，由memory_limit控制；threads决定并行度，temp_directory指定溢出目录。查询超限时，DuckDB会将中间结果分区溢出到磁盘，查询变慢但能完成；若未配置临时目录则返回内存错误而非崩溃。针对2GB Kubernetes Pod的调优示例为：memory_limit设为768MB、threads为2、配置可写临时目录并限制其大小。与Snowflake相比，DuckDB仅有一级本地磁盘溢出且需用户自行配置，Snowflake则有本地SSD和远程存储两级溢出，内存由平台管理。
延伸解读
容器中默认内存上限的风险
DuckDB 默认将系统内存的 80% 用作缓冲池，这在 16GB 笔记本上可行，但在 2GB 容器中会占用 1.6GB，仅剩 400MB 给应用运行时和操作系统，极易触发 OOM 杀死。文章指出，所有数据块、哈希表和排序缓冲都从单一缓冲池分配，由 memory_limit 控制。因此容器部署必须显式调低该值，而不是依赖默认比例。
溢出机制：慢但能完成
当查询超出 memory_limit 时，DuckDB 不会崩溃，而是将中间结果分区溢出到 temp_directory 指定的磁盘目录，查询变慢但能正确完成。若 temp_directory 为空字符串，则无法溢出，查询会返回内存分配错误，但连接仍可用。文章强调，配置可写临时目录是避免查询失败的关键，且临时文件在连接关闭时清理。
2GB Pod 的调优逻辑
针对 2GB Kubernetes Pod，文章建议 memory_limit 设为 768MB，为应用运行时和系统留出约 1.2GB 余量；threads 设为 2 以匹配 CPU 请求，避免线程多于核心导致调度浪费；temp_directory 指向 emptyDir 卷，并用 max_temp_directory_size 限制溢出磁盘用量，防止耗尽临时存储。这些设置需在应用启动时通过 SQL 执行。
与 Snowflake 的架构差异
DuckDB 只有一级溢出：内存到本地磁盘，且内存限制由用户配置，无法横向扩展。Snowflake 有两级溢出：内存到本地 SSD，再溢出到远程对象存储，内存由平台内部管理，用户无法配置，只能通过扩大仓库规格来缓解。文章指出，DuckDB 的优势是控制权和空闲零成本，代价是需自行管理溢出目录，且 emptyDir 写满后查询仍会失败。
Q&A
DuckDB 默认会占用多少系统内存？在 2GB 容器里为什么容易被 OOM 杀死？
DuckDB 默认将系统内存的 80% 用作缓冲池。在 2GB 容器中，缓冲池会占用 1.6GB，仅剩 400MB 留给应用运行时、应用程序和操作系统，因此极易触发 OOM 杀死。
DuckDB 的缓冲池管理哪些内存分配？由哪个参数控制大小？
DuckDB 通过单一缓冲池管理所有数据块、哈希表、排序缓冲和中间结果的内存分配。缓冲池大小由 memory_limit 参数控制。
当查询超过 memory_limit 时，DuckDB 会崩溃吗？它会如何处理？
不会崩溃。DuckDB 会将中间结果分区溢出到磁盘（temp_directory 指定的临时目录），查询变慢但能正确完成。临时文件在连接关闭时清理。
如果没有配置 temp_directory，查询超内存限制会发生什么？
如果 temp_directory 为空字符串，DuckDB 无法溢出。查询超过内存限制时会返回内存分配错误（Out of Memory Error），但进程不会崩溃，连接仍可用，仅该查询失败。
在 2GB 内存、2 核 CPU 的 Kubernetes Pod 中，DuckDB 应该如何调优？
建议设置：memory_limit='768MB'（留约 1.2GB 给应用和系统）、threads=2（匹配 CPU 核数）、temp_directory 指向可写卷（如 emptyDir）、max_temp_directory_size='2GB'（限制溢出磁盘用量）。
DuckDB 和 Snowflake 在内存溢出处理上有什么主要区别？
DuckDB 只有一级溢出（内存到本地磁盘），内存限制用户可配置，无法横向扩展；Snowflake 有两级溢出（本地 SSD 再到远程对象存储），内存由平台管理，可通过调整仓库大小或使用多集群仓库扩展。
