扩展 pgTune GSoC 2011

来自 PostgreSQL Wiki
跳转到导航跳转到搜索

1.0 发布功能目标（注意：此项目的任务仍在讨论中。本 wiki 页面的内容仍在最终协商中。）

设置信息

  • 根据 min/max 验证 - 存根
 * What's really needed here is a clamp function that limits based
   on both the maximum setting possible as well as a tuning model
   maximum.  For example, the tuning model max for wal_buffers is
   16MB, while the tuning model max for shared_buffers on Windows
   is 512MB.  The system max matters too.  On a system with a large
   amount of RAM, the suggested value for work_mem might easily be set
   to bigger than its server maximum (2GB) even though there's no
   tuning model max intended for it.
  • 处理指数类型最大值（random_page_cost 的最大值为 1.79769e+308）
  • 使内存设置 (-M) 支持所有数据库内存输入格式
  • 在输出中显示已调整参数的原始值
  • 弄清楚如何处理分隔符 - 存根

参数限制

  • Windows 上的 shared_buffers 限制为 512MB
  • 所有平台上的 shared_buffers 限制为 8GB
  • wal_buffers 限制为 16MB
  • work_mem、maintenance_work_mem 限制为 2GB（服务器最大值）
  • 总 RAM 小于 256MB 时发出警告（存根）
  • 更新 8.4 设置文件，default_statistics_target 应为 100
  • 添加 9.0 32 位设置文件

模型改进

  • 当前对 work_mem 的建议过于激进
 many cases.  More reports of using too much memory than expected.
 Either more multi-node sorting may be going on, or footprint of
 other applications is larger then expected.
  • 根据 PostgreSQL 文档中的表估算使用的共享内存
  • 将模型更新为更为精细的模型
 * Account for all RAM
 * Target using 1/4 for shared_buffers, up to 1/2 for work_mem, and
   typically an additional 1/2 of the OS buffer cache
 * If shared_buffers hits one of the limits, that will change how
   the rest of the tuning works out

特定平台的详细信息

  • 输出 sysctl.conf 建议；参见下文中的备注。
 * Ideally based on estimated memory use, as described in section below
 * Initially just assuming a 50% of memory target for the memory block
   would work
  • 其他程序输入
 * PostgreSQL version and platform, to select the right pg_settings file

 * Platform may be possible to detect; see notes below.
  • 允许覆盖生成 sysctl 输出时使用的操作系统
  • 建议为应用程序保留的大小
  • 使用 PGDATA 查找 postgresql.conf 文件
  • 要调整的新设置
 * Warning about listen_addresses if it's not set to '*'

   * Add an input parameter to allow setting it, too

文档

  • 明确描述所有类型，在使用说明中参考文档
  • 建议设置仍然保守的位置
  • 数据仓库：更多统计信息，关闭自动清理
  • 没有考虑应用程序开销，如果出现这种情况，可以减少内存总量
  • 如果您已经手动增加了 BLCKSZ 或 XLOG_BLCKSZ，系统可能无法正确解析现有值；不过，仍应正确设置值。（如果我们要求或提示在线数据库，我们可对它进行查询：show block_size；show wal_block_size；）
  • 警告称，最小系统应仅仅使用 initdb 中提供的内容

向稳定版本移植的更改

  • 8.4 设置文件修复
  • constraint_exclusion 更改
  • default_statistics_target 调整
  • 更好看的页眉

实现想法

此部分主要包含有关如何构建 1.0 版本计划功能的想法。

估算共享内存使用量

https://postgresql.ac.cn/docs/current/static/kernel-resources.html

  • 引入一个到处传递的平台结构
 abstracts away OS, memory, version, PostgreSQL version, etc.
  • 引入“info”选项，该选项将显示该处的全部信息，
 including anything auto-detected.  This will make testing/debugging
 much easier.

提示界面

一种显示备选方案的方式是进入标准错误的提示界面。样本提示：

 # HINT:  Increase SHMMAX
 # HINT:  You won't be able to connect to this database over TCP/IP with your listen_address setting
 # HINT:  The value for max_connections is being reduced from $X to $Y
 # HINT:  Expected maximum memory use for this configuration:  $X (pretty printed)
 # HINT:  Autovacuum is off  
 # HINT:  If you aren't using partitions, you can improve query planning time by turning constraint_exclusion off
 # HINT:  Windows doesn't handle large numbers of connections
 # HINT:  Consider a conneciton pooler

虽然将所有提示显示为注释会很好，但这样做会导致它们混在一起。不过，那样将使得 SHMMAX 示例的实用性大打折扣。鉴于围绕自动化 sysctl 生成的想法，这可能无关紧要。

Python 系统信息

  • 应该可以检测平台位宽（32 或 64）。
  • 系统参数 SC_INT_MAX 将告诉我们所处平台的类型（`uname -m` 会是一种不错的替代方案吗？）
  • 处理器数也很有可能。
  • 还可以通过平台信息交替获取位宽
  • 查看指针大小

示例系统参数：

 SC_INT_MAX 2147483647
 SC_NPROCESSORS_CONF 4

Python 审核备选方案

这里的行号指的是早期版本的代码。

  • from ctypes import *（第 18 行）让代码块难以阅读，而且
 pollutes the namespace.
  • doc 字符串（59、136、206）不遵循标准惯例，
 described here https://www.pythonlang.cn/dev/peps/pep-0257/.
  • 函数也支持 doc 字符串（342、351 等）。

未来版本创意

V2.0 功能

 Wizard to ask questions
 Real GUI

改进的兼容性功能

这些功能都优先级低于这里概述的其他功能。相对于所提供的优点，很难证明与旧/奇系统兼容的运作是合理

  • 添加 8.3、8.2、8.1 兼容性
  • 设定 FSM 参数 - 需要想法，弄清楚数据库有多大
  • 加入一项自动检测 PG 版本的选项。这可能需要
 a series of sample postgresql.conf files from each version, to figure
 out which the input file is most like.
  • 扩展模型，使之能够妥善适用于用户数量较少、旨在处理少量 RAM 的系统
  • 设置 max_prepared_transactions
  • 一系列不要搞乱的参数（整理、存档命令），这
 may be needed for more advanced generation ideas

调整可用空间映射设置 2011 年 5 月 24 日 13:52（UTC）2011 年 5 月 24 日 13:52（UTC）2011 年 5 月 24 日 13:52（UTC）2011 年 5 月 24 日 13:52（UTC）2011 年 5 月 24 日 13:52（UTC）2011 年 5 月 24 日 13:52（UTC）

仅适用于添加 PostgreSQL 8.3 及早期版本。如果目标是 8.4，FSM 操作是必需的。值

  • web：max_fsm_pages = DBsize / PageSize / 8
  • oltp：max_fsm_pages = DBsize / PageSize / 8
  • Mixed：max_fsm_pages = DBsize / PageSize / 8
  • Desktop：max_fsm_pages = DBsize / PageSize / 8
  • DW：max_fsm_pages = DBsize / PageSize / 32

DW 案例与其他类型不同，因为它们往往比其他类型更不频繁地插入和删除数据，留下的可用空间更少，无法重复使用。

配置再生程序创意

postgresql.conf 中有许多注释掉的设置。这使得文件比以前更难以浏览。改善这种情况的一个想法是让 pgtune 删除无关的行。第二个想法是支持基于针对每个版本的模板提供生成一个配置文件，从头开始。

Josh 的评论：首先，我不清楚我们为何要尝试支持包含注释的自定义 postgresql.conf 文件。我们应该只生成一个不含注释的新简单文件。

完整的配置生成器可能支持以下开关

  • -b，--basic - 简短的配置文件，仅列出 15-18 个最常更改的选项
  • -a，--advanced - 列出所有 196+ 个选项的配置文件
  • -t，--terse - 配置文件仅列出类别标题和实际设置，无注释
  • -n，--normal - 配置文件具有类别和子类别设置，带简短的描述性注释
  • -v，--verbose - 配置文件在注释中列出完整描述和建议，每个选项都有
  • -c "option = value" 在文件中将特定选项设为特定值
  • -f "filename" ‚Äî 从文件 "filename" 中获取选项和值。这允许程序
 to handle the difficult settings manipulation part for a custom settings set suggested by
 a different tool.

默认值为 "-b -n"，shared_buffers 有特定的设置。当前的 postgresql.conf 更类似于 "-a -v" 文件。

从头开始生成新文件的难点在于获得所有区域设置和共享内存设置的权利，它必须重复 initdb 为此处理的大部分工作。而在 pgtune 尝试删除无用注释的情况下，它确实需要每个版本的 postgresql.conf 文件的样本，才能弄清楚那里哪些行是样板，哪些是用户注释。

Josh 的评论：这并不具有挑战性。要么你从正在运行的 PostgreSQL 获取此信息，要么从现有的 postgresql.conf 获取。解析出我们需要的几行一点也不难。再次强调，我们不应该尝试保留机器生成文件中的注释。

设置通用成语

几种类型的 postgresql.conf 更改作为可以自动化的常见更改集发生

  • 配置日志进行性能监控
  • 调整日志格式以进行查询分析（与 pgfouine 兼容）
  • 设置 SSL
  • 良好的 syslog 设置和实践
  • 按周轮换的数据库管理日志文件

工作负载类型的注释

“DW”用例的具体元素不一定与大小相关。它们是

  • 数据以大批次形式而不是单个行形式进入
  • 少量用户
  • 大型复杂查询

一个只有 15GB 的数据库可能仍然表现出稳定的 DW 行为，在这种情况下，您需要将 max_connections 保持在 < 20，甚至关闭 autovaccum。

内部信息

解析输入单位

这描述了程序中如何处理输入单位。它基于数据库在其 GUC 系统中使用的逻辑。

parse_int 是那里的内部例程

kB MB 和 GB 是接受的单位

一些参数是 "GUC_UNIT_MEMORY"；这些是此逻辑应用于的参数

 These are ones where the unit name ends with kB

原始整数被认为为 kb，除非它们是 blocksz 或 xlog_blcksz。几个常量进行转换：

 #define KB_PER_MB (1024)
 #define KB_PER_GB (1024*1024)
  • kB：除以（单位大小）/kb（通常 =8）以获得 kB
  • MB：乘以 KB_PER_MB，如上所示进行除法
  • GB：乘以 KB_PER_GB

还有一些时间单位变量，现在不用考虑那些

以下是将块大小信息映射到单位字段的逻辑:

                       case GUC_UNIT_KB:
                               values[2] = "kB";
                       case GUC_UNIT_BLOCKS:
                               snprintf(buf, sizeof(buf), "%dkB", BLCKSZ / 1024);
                       case GUC_UNIT_XBLOCKS:
                               snprintf(buf, sizeof(buf), "%dkB", XLOG_BLCKSZ / 1024);

所以我不用担心那个；我可以直接使用 kB 作为单位大小

对于布尔值，on 和 off 是这些值的正式支持版本，但是也接受很多其他值。

取自 "https://wiki.postgresql.ac.cn/index.php?title=Extending_pgTune_GSoC_2011&oldid=17037"