我建议你阅读 Nikolai Samokhvalov 的报告“调整 PostgreSQL 的工业方法：数据库实验”的文字记录
Shared_buffers = 25% – 是多还是少？ 还是刚刚好？ 您如何知道这个相当过时的建议是否适合您的特定情况？
是时候“像成年人一样”解决选择 postgresql.conf 参数的问题了。 不是借助盲目的“自动调谐器”或文章和博客中过时的建议，而是基于：
- 对数据库进行严格验证的实验，在尽可能接近“战斗”的条件下自动进行、大量进行，
- 深入了解DBMS和OS的特性。
使用 Nancy CLI (），我们将看一个具体的例子 - 臭名昭著的共享缓冲区 - 在不同的情况下，在不同的项目中，并尝试找出如何为我们的基础设施、数据库和负载选择最佳设置。
我们将讨论数据库实验。 这是一个持续六个月多一点的故事。
有关于我的一些。 拥有超过 14 年的 Postgres 经验。 多家社交网络公司相继成立。 Postgres 过去和现在到处都在使用。
另外，RuPostgres 小组在 Meetup 上排名世界第二。 我们正在慢慢接近 2 人。 RuPostgres.org。
在包括 Highload 在内的各种会议的 PC 上，我从一开始就负责数据库，特别是 Postgres。
在过去的几年里，我从这里重新开始了 11 个时区的 Postgres 咨询实践。
几年前，当我这样做时，我可能从 2010 年开始就中断了使用 Postgres 的手动工作。 我很惊讶 DBA 的工作流程几乎没有改变，仍然需要使用多少体力劳动。 我立即想到这里出了问题，我需要自动化更多的事情。
由于一切都是远程的，因此大多数客户端都位于云端。 显然，很多事情已经实现自动化。 稍后会详细介绍这一点。 也就是说，所有这些导致了这样的想法：应该有许多工具，即某种平台，可以自动执行几乎所有 DBA 操作，以便可以管理大量数据库。
本报告将不包括：
- “银弹”和诸如设置 8 GB 或 25% 共享缓冲区之类的语句就可以了。 关于shared_buffers就不多说了。
- 硬核“内脏”。
会发生什么？
- 我们将应用和开发一些优化原则。 在此过程中会出现各种各样的想法以及我们在开源中创建的大部分工具，也就是说，我们在开源中奠定了基础。 此外，我们有门票，所有通信实际上都是开源的。 您可以看到我们现在正在做什么、下一个版本中将会有什么等等。
- 在许多公司中，从小型初创公司到大公司，也会有一些使用这些原则、这些工具的经验。
这一切是如何发展的？
首先，DBA的主要任务除了保证实例的创建、备份的部署等之外，就是发现瓶颈、优化性能。
现在就这样设置了。 我们查看监控，我们看到了一些东西，但我们遗漏了一些细节。 我们开始更仔细地挖掘，通常是用手，并了解如何以某种方式处理它。
有两种方法。 pg_stat_statements 是识别慢查询的默认解决方案。 并使用 pgBadger 分析 Postgres 日志。
每种方法都有严重的缺点。 在第一种方法中，我们丢弃了所有参数。 如果我们看到组 SELECT * FROM 表，其中列等于“？” 或从 Postgres 10 开始为“$”。我们不知道这是索引扫描还是序列扫描。 这很大程度上取决于参数。 如果在那里替换一个很少遇到的值，这将是索引扫描。 如果你替换一个占据表 90% 的值，seq 扫描将是显而易见的，因为 Postgres 知道统计信息。 这是 pg_stat_statements 的一个很大的缺点，尽管一些工作正在进行中。
日志分析的最大缺点是您通常无法承受“log_min_duration_statement = 0”。 我们也会讨论这个。 因此，你看不到全貌。 而某些查询速度非常快，可能会消耗大量资源，但您不会看到它，因为它低于您的阈值。
DBA 如何解决他们发现的问题？
例如，我们发现了一些问题。 通常做什么？ 如果您是开发人员，那么您将在某些大小不同的实例上执行某些操作。 如果您是 DBA，那么您就需要进行分期。 而且只能有一个。 他落后了六个月。 你认为你会投入生产。 甚至经验丰富的 DBA 也会在副本上检查生产情况。 他们碰巧创建了一个临时索引，确保它有帮助，然后将其删除并将其交给开发人员，以便他们可以将其放入迁移文件中。 这就是现在正在发生的无稽之谈。 这是一个问题。
- 调整配置。
- 优化索引集。
- 改变SQL查询本身（这是最困难的方法）。
- 增加容量（大多数情况下最简单的方法）。
这些事情发生了很多事情。 Postgres 中有很多句柄。 有很多事情需要了解。 Postgres中有很多索引，也感谢这次会议的组织者。 所有这些都需要知道，这就是让非 DBA 感觉 DBA 正在练习黑魔法的原因。 也就是说，你需要学习10年才能开始正常理解这一切。
我是对抗这种黑魔法的斗士。 我想做的每一件事都是有技术的，而这一切都没有直觉。
现实生活中的例子
我至少在两个项目中观察到了这一点，包括我自己的项目。 另一篇博客文章告诉我们，default_statistict_target 的值为 1 比较合适。 好的，让我们在生产中尝试一下。
两年后，我们使用我们的工具，借助对我们今天讨论的数据库进行的实验，我们可以比较过去和现在的情况。
为此，我们需要创建一个实验。 它由四个部分组成。
- 首先是环境。 我们需要一个硬件。 当我来到某家公司并签订合同时，我告诉他们给我与生产中相同的硬件。 对于你们的每一位大师，我至少需要一件这样的硬件。 这要么是 Amazon 或 Google 中的实例虚拟机，要么我需要完全相同的硬件。 也就是说，我想重建环境。 在环境的概念中，我们包括了 Postgres 的主要版本。
- 第二部分是我们的研究对象。 这是一个数据库。 它可以通过多种方式创建。 我会告诉你如何做。
- 第三部分是负载。 这是最困难的时刻。
- 第四部分是我们检查的内容，即我们将与什么进行比较。 假设我们可以更改配置中的一个或多个参数，或者我们可以创建索引等。
我们正在开展一项实验。 这是 pg_stat_statements。 左边就是发生的事情。 右边 - 发生了什么。
左边default_statistics_target = 100，右边=1。我们看到这对我们有帮助。 总体而言，一切都好转了 000%。
但是如果我们向下滚动，将会有来自 pgBadger 或 pg_stat_statements 的请求组。 有两种选择。 我们会看到一些请求下降了 88%。 这就是工程方法。 我们可以进一步挖掘内部，因为我们想知道它为何沉没。 您需要了解统计数据发生了什么。 为什么统计数据中的桶越多会导致结果越差。
或者我们可以不挖掘，而是执行“ALTER TABLE ... ALTER COLUMN”并返回100个桶回到该列的统计数据。 然后通过另一个实验，我们可以确保这个补丁有帮助。 全部。 这是一种工程方法，可以帮助我们了解全局并根据数据而不是直觉做出决策。
其他领域的几个例子。 测试中CI测试已经存在很多年了。 如果没有自动化测试，任何头脑清醒的项目都无法生存。
在其他行业：在航空、汽车行业，我们测试空气动力学的时候，我们也有机会做实验。 我们不会将图纸中的东西直接发射到太空，或者我们不会立即将一些汽车送上轨道。 例如，有一个风洞。
我们可以从其他行业的观察中得出结论。
首先，我们有特殊的环境。 它已经接近生产，但还没有接近。 其主要特点是成本低廉、可重复且尽可能自动化。 并且还必须有专门的工具来进行详细的分析。
最有可能的是，当我们发射飞机并飞行时，我们研究机翼表面每一毫米的机会比在风洞中要少。 我们有更多的诊断工具。 我们有能力携带更重的东西，而这些东西是我们无法放在飞机上飞的。 与 Postgres 相同。 在某些情况下，我们可能会在实验期间启用完整的查询日志记录。 我们不想在生产中这样做。 我们甚至可能计划使用 auto_explain 来启用此功能。
正如我所说，高度自动化意味着我们按下按钮并重复。 本来就应该这样，这样才有大量的实验，这样才能上线。
Nancy CLI——“数据库实验室”的基础
所以我们做了这件事。 也就是说，我在六月，也就是差不多一年前，就谈到了这些想法。 我们已经在开源中拥有所谓的 Nancy CLI。 这是建立数据库实验室的基础。
— 它是开源的，位于 Gitlab 上。 你可以说，你可以尝试。 我在幻灯片中提供了一个链接。 你可以点击它，它就会在那里 在各方面。
当然，还有很多正在开发中。 那里有很多想法。 但这是我们几乎每天都使用的东西。 当我们有了一个想法 - 为什么当我们删除 40 行时，这一切都归结为 IO，然后我们可以进行实验并更详细地查看以了解发生了什么，然后尝试即时修复它。 也就是说，我们正在做一个实验。 例如，我们调整一些东西，看看最终会发生什么。 我们在生产中不会这样做。 这就是这个想法的本质。
这可以在哪里发挥作用？ 这可以在本地工作，即您可以在任何地方执行它，甚至可以在 MacBook 上运行它。 我们需要一个码头工人，我们走吧。 就这样。 您可以在任何地方的硬件或虚拟机上的某些实例中运行它。
并且还有机会在 Amazon EC2 实例中远程运行。 这是一个非常酷的机会。 例如，昨天我们在 i500 实例上进行了 3 多次实验，从最年轻的开始到 i3-16-xlarge 结束。 500 次实验花费 64 美元。 每场持续15分钟。 也就是说，由于那里使用了点，因此非常便宜 - 70% 的折扣，亚马逊按秒计费。 你可以做很多事情。 你可以做真正的研究。
支持 Postgres 的三个主要版本。 完成一些旧版本和新的第 12 版本并不是那么困难。
我们可以通过三种方式定义一个对象。 这：
- 转储/sql 文件。
- 主要方式是克隆PGDATA目录。 通常，它是从备份服务器获取的。 如果您有普通的二进制备份，您可以从那里进行克隆。 如果您有云，那么像亚马逊和谷歌这样的云办公室将为您做这件事。 这是克隆真实生产的最重要的方式。 这就是我们展开的方式。
- 当您想了解 Postgres 中的某些内容如何工作时，最后一种方法适合研究。 这是 pgbench。 您可以使用 pgbench 生成。 它只是一个“db-pgbench”选项。 你告诉他什么规模。 如前所述，所有内容都将在云中生成。
并加载：
- 我们可以在一个 SQL 线程中执行加载。 这是最原始的方式。
- 我们可以模拟负载。 我们可以首先通过以下方式进行模拟。 我们需要收集所有日志。 这很痛苦。 我会告诉你原因。 我们使用 pgreplay 进行游戏，它内置于 Nancy 中。
- 或者另一种选择。 所谓工艺负载，就是我们付出一定的努力去做的。 分析战斗系统当前的负载，我们提取出最重要的请求组。 使用 pgbench，我们可以在实验室中模拟此负载。
- 要么我们必须执行某种 SQL，即我们检查某种迁移，在那里创建索引，在那里执行 ANALAZE。 我们看看真空之前和真空之后发生了什么。 一般来说，任何 SQL。
- 我们要么更改配置中的一个或多个参数。 例如，我们可以告诉我们检查 Amazon 中 TB 数据库的 100 个值。 几个小时后你就会得到结果。 通常，部署 TB 数据库需要几个小时。 但是有一个补丁正在开发中，我们有一系列可能，即您可以在同一台服务器上一致地使用相同的 pgdata 并进行检查。 Postgres 将重新启动并且缓存将被重置。 并且您可以驱动负载。
- 一个目录包含一堆不同的文件，从 pg 快照开始统计***。 最有趣的是pg_stat_statements、pg_stat_kcacke。 这是两个分析请求的扩展。 pg_stat_bgwriter 不仅包含 pgwriter 统计信息，还包含检查点以及后端本身如何替换脏缓冲区的统计信息。 这一切都很有趣。 比如我们设置shared_buffers的时候，看看大家都替换了多少，很有趣。
- Postgres 日志也已到达。 两个日志——一个准备日志和一个加载播放日志。
- 一个相对较新的功能是 FlameGraphs。
- 另外，如果您使用 pgreplay 或 pgbench 选项来播放负载，那么它们的输出将是本机的。 您将看到延迟和 TPS。 我们将能够理解他们是如何看待它的。
- 系统信息。
- 基本 CPU 和 IO 检查。 对于 Amazon 中的 EC2 实例来说更是如此，当您想要在一个线程中启动 100 个相同的实例并在那里运行 100 次不同的运行时，那么您将进行 10 个实验。 而且你需要确保你不会遇到已经被某人压迫的有缺陷的实例。 其他人在该硬件上很活跃，而您剩下的资源所剩无几。 最好放弃这样的结果。 在 Alexey Kopytov 的 sysbench 的帮助下，我们进行了几项简短的检查，这些检查可以与其他检查进行比较，即您将了解 CPU 的行为以及 IO 的行为。
从不同公司的例子来看，技术难点是什么？
假设我们想使用日志重复实际负载。 如果它是在开源 pgreplay 上编写的，这是一个好主意。 我们用它。 但为了使其正常工作，您必须启用带有参数和计时的完整查询日志记录。
持续时间和时间戳存在一些复杂性。 我们将清空整个厨房。 主要问题是你买得起还是买不起？
问题是它可能不可用。 首先，您必须了解将以什么流写入日志。 如果您有 pg_stat_statements，则可以使用此查询（幻灯片中提供链接）来了解大约每秒写入多少字节。
我们查看请求的长度。 我们忽略了没有参数的事实，但我们知道请求的长度，并且知道每秒执行多少次。 这样我们就可以估计每秒大约有多少字节。 我们可能会犯两倍的错误，但这样我们一定会理解顺序。
我们可以看到每秒执行该请求 802 次。 我们看到 bytes_per sec – 300 kB/s 将被写入正负。 一般来说，我们可以承受这样的流量。
但！ 事实上，存在不同的日志系统。 而人们默认的通常是“syslog”。
如果你有 syslog，那么你可能会看到这样的图片。 我们将使用 pgbench，启用查询日志记录并看看会发生什么。
没有日志记录 - 这是左侧的列。 我们获得了 161 TPS。 使用 syslog - 这是在 Amazon 上的 Ubuntu 000 中，我们获得了 16.04 TPS。 而如果我们换成另外两种日志记录方式，那么情况就会好很多。 也就是说，我们预计它会下降，但幅度不会相同。
而在 CentOS 7 上，journald 也参与其中，将日志转换为二进制格式以便于搜索等，那么那里就是一场噩梦，我们的 TPS 下降了 44 倍。
这就是人们的生活。 通常在公司中，尤其是在大公司中，这一点很难改变。 如果您可以摆脱系统日志，那么请摆脱它。
- 评估 IOPS 和写入流量。
- 检查您的日志系统。
- 如果预计负载过大，请考虑抽样。
我们有 pg_stat_statements。 正如我所说，它一定在那里。 我们可以在文件中以特殊方式获取并描述每组请求。 然后我们可以使用 pgbench 中一个非常方便的功能 - 这是使用“-f”选项插入多个文件的能力。
它理解很多“-f”。 您可以借助末尾的“@”来判断每个文件应具有哪些共享。 也就是说，我们可以说在 10% 的情况下这样做，在 20% 的情况下这样做。 这将使我们更接近我们在生产中看到的情况。
我们如何了解我们的生产情况？ 分享什么以及如何分享？ 这有点偏题了。 我们还有一款产品 。 也是开源的基础。 我们现在正在积极开发它。
他出生的原因略有不同。 由于监控还不够。 就是你来，看看基地，看看存在的问题。 而且，作为一项规则，您会进行健康检查。 如果您是一位经验丰富的 DBA，那么您会进行 health_check。 我们研究了索引的使用等。如果你有 OKmeter，那就太好了。 这对于 Postgres 来说是很酷的监控。 OKmeter.io – 请安装它，那里一切都做得很好。 是付费的。
如果你没有，那么你通常没有太多。 监控中一般就是CPU、IO，然后还有预留，仅此而已。 我们还需要更多。 我们需要了解 autovacuum 是如何工作的，检查点是如何工作的，在 io 中我们需要将检查点与 bgwriter 和后端分开，等等。
问题是，当你帮助一家大公司时，他们无法快速实施某些事情。 他们无法快速购买 OKmeter。 也许他们会在六个月内购买它。 他们无法快速交付一些包裹。
我们想到了一个想法，我们需要一个不需要安装任何东西的特殊工具，也就是说，你不需要在生产中安装任何东西。 将其安装在您的笔记本电脑上，或者安装在您将运行它的观察服务器上。 它将分析很多东西：操作系统、文件系统和 Postgres 本身，进行一些可以直接运行到生产环境的轻型查询，并且不会失败。
我们称之为 Postgres 检查。 从医学角度来说，这是一次定期的健康检查。 如果它是汽车主题的，那么就像维护一样。 您每六个月或每年对您的汽车进行一次维护，具体取决于品牌。 你们对你们的基地进行维护吗？ 也就是说，您定期进行深入研究吗？ 必须这样做。 如果您进行了备份，然后进行检查，这一点同样重要。
我们有这样一个工具。 大约三个月前它才开始活跃地出现。 他还年轻，但有很多东西。
收集最“有影响力”的查询组 - Postgres-checkup 中的报告 K003
还有一组报告K。目前为止有三份报告。 还有这样一份报告K003。 pg_stat_statements 位于顶部，按 Total_time 排序。
当我们按总时间对请求组进行排序时，我们会在顶部看到系统加载最多的组，即消耗更多资源的组。 为什么要命名查询组？ 因为我们扔掉了参数。 这些不再是请求，而是请求组，即它们是抽象的。
而如果我们从上到下进行优化，就会减轻我们的资源，延缓我们需要升级的时刻。 这是一个非常好的省钱方法。
也许这不是一个很好的照顾用户的方式，因为我们可能不会看到一个人等待15秒的罕见但非常烦人的情况。 总的来说，它们非常罕见，我们看不到它们，但我们正在处理资源。
这张表发生了什么？ 我们拍了两张快照。 Postgres_checkup 将为您提供每个指标的增量：总时间、调用、行、shared_blks_read 等。就这样，增量已计算出来。 pg_stat_statements 的一个大问题是它不记得何时重置。 如果 pg_stat_database 记得，那么 pg_stat_statements 就不记得。 你看有1万，但我们不知道从哪里算的。
我们知道，这里有两张快照。 我们知道本例中的增量为 56 秒。 一个很短的间隙。 按总时间排序。 然后我们可以区分，即将所有指标除以持续时间。 如果我们将每个指标除以持续时间，我们将得到每秒的调用次数。
接下来，每秒的总时间是我最喜欢的指标。 它以秒为单位，每秒，即我们的系统每秒执行这组请求需要多少秒。 如果您看到每秒超过一秒，则意味着您必须提供多个核心。 这是一个非常好的指标。 你可以这样理解，比如这位朋友，至少需要三个核心。
这是我们的专有技术，我从未在任何地方见过类似的东西。 请注意 - 这是一件非常简单的事情 - 每秒一秒。 有时候，当你的CPU是100%的时候，那么每秒半个小时，也就是说，你花了半个小时来做这个请求。
接下来我们看到每秒的行数。 我们知道它每秒返回多少行。
然后还有一个有趣的事情。 我们每秒从共享缓冲区本身读取多少个共享缓冲区。 命中已经存在，我们从操作系统缓存或磁盘中获取行。 第一个选项很快，第二个选项可能快也可能不快，具体取决于情况。
第二种区分方式是划分该组中的请求数量。 在第二列中，每个查询始终划分一个查询。 然后有趣的是 - 这个请求中有多少毫秒。 我们知道这个查询的平均表现如何。 每个请求需要 101 毫秒。 这是我们需要理解的传统指标。
每个查询平均返回多少行？ 我们看到该组有 8 人返回。 平均而言，从缓存中取出并读取了多少内容。 我们看到一切都被很好地缓存了。 第一组的表现强劲。
每行的第四个子字符串是占总数的百分比。 我们有电话。 比方说1，我们可以了解这个群体做出了什么贡献。 我们看到，在这种情况下，第一组的贡献不到 000%。 也就是说，它太慢了，以至于我们在全局中看不到它。 第二组是 000% 的电话费。 也就是说，所有呼叫中有 0,01% 是第二组。
Total_time 也很有趣。 我们在第一组请求上花费了总工作时间的 14%。 第二个 - 11%，等等。
我不会详细说明，但其中有微妙之处。 我们在顶部显示一个错误，因为当我们比较时，快照可能会浮动，也就是说，一些请求可能会掉下来，不能再出现在第二个请求中，而一些新的请求可能会出现。 然后我们计算误差。 如果您看到 0，那就很好。 没有错误。 如果错误率达到20%就可以了。
然后我们回到我们的主题。 我们需要精心设计工作负载。 我们从上到下，直到达到 80% 或 90%。 通常这是 10-20 组。 我们为 pgbench 制作文件。 我们在那里使用随机。 不幸的是，有时这并不能解决问题。 并且在 Postgres 12 中将会有更多的机会使用这种方法。
然后我们通过这种方式获得了 80-90% 的总时间。 “@”后面应该写什么？ 我们查看电话，查看有多少兴趣，并了解我们在这里欠了这么多利息。 从这些百分比我们可以了解如何平衡每个文件。 之后我们使用 pgbench 并开始工作。
我们还有 K001 和 K002。
K001 是一个大字符串，有四个子字符串。 这是我们整个负载的一个特点。 请参阅第二列和第二子行。 我们看到每秒大约一秒半，也就是说，如果有两个核心，那就好了。 容量约为 75%。 它会像这样工作。 如果我们有10个核心，那么我们通常会很平静。 这样我们就可以评估资源。
K002 就是我所说的查询类，即 SELECT、INSERT、UPDATE、DELETE。 并单独选择SELECT FOR UPDATE，因为它是锁。
在这里我们可以得出结论，SELECT 是普通读者 - 占所有调用的 82%，但同时 - 占总时间的 74%。 也就是说，它们被调用很多，但消耗的资源较少。
我们回到这个问题：“我们如何选择正确的shared_buffers？” 我观察到大多数基准测试都是基于这样的想法 - 让我们看看吞吐量是多少，即吞吐量是多少。 通常以 TPS 或 QPS 来衡量。
我们尝试使用调整参数从汽车中挤出尽可能多的每秒交易量。 这里的 select 正好是每秒 311 个。
但没有人全速开车上班和回家。 这很愚蠢。 与数据库相同。 我们不必全速行驶，也没有人这样做。 没有人生活在拥有 100% CPU 的生产环境中。 虽然，也许有人活着，但这并不好。
我们的想法是，我们通常以 20% 的容量行驶，最好不超过 50%。 我们首先尝试优化用户的响应时间。 也就是说，我们必须有条件地调整旋钮，使 20% 速度下的延迟最小。 我们也尝试在实验中使用这个想法。
最后，建议：
- 一定要进行数据库实验室。
- 如果可能的话，按需进行，以便它展开一段时间 - 玩完然后扔掉。 如果你有云，那么这是不言而喻的，即有很多地位。
- 保持好奇心。 如果出现问题，请通过实验检查其行为方式。 南希可以用来训练自己检查基地如何运作。
- 并以最短响应时间为目标。
- 并且不要害怕 Postgres 来源。 当您使用消息源时，您必须懂英语。 那里有很多评论，一切都在那里解释。
- 并定期检查数据库的运行状况，至少每三个月一次，手动或Postgres-checkup。
问题
多谢！ 一件非常有趣的事情。
两块。
是的，两块。 只是我不太明白。 当 Nancy 和我工作时，我们可以只调整一个参数还是整组参数？
我们有一个增量配置参数。 您可以一次性转到那里任意数量。 但你需要明白，当你改变很多事情时，你可能会得出错误的结论。
是的。 我为什么问？ 因为当你只有一个参数时，很难进行实验。 你把它拧紧，看看它是如何工作的。 我把他赶了出去。 然后你开始下一个。
可以同时收紧，不过当然要看情况。 但最好测试一个想法。 昨天我们有一个想法。 我们的情况非常接近。 有两个配置。 我们不明白为什么会有这么大的差异。 于是出现了这样的想法：你需要使用二分法才能一致地理解和发现差异。 您可以立即使一半参数相同，然后四分之一，等等。一切都很灵活。
还有一个问题。 该项目还很年轻并且正在发展。 文档已经准备好了，有详细说明吗？
我专门在那里建立了参数描述的链接。 它就在那里。 但很多东西还没有实现。 我正在寻找志同道合的人。 当我表演时我会找到它们。 这非常酷。 有人已经在和我一起工作，有人在那里帮忙并做了一些事情。 如果您对这个主题感兴趣，请就缺少的内容提供反馈。
一旦我们建立了实验室，也许就会有反馈。 让我们来看看。 谢谢你！
你好！ 感谢您的报告！ 我看到有亚马逊支持。 有计划支持GSP吗？
好问题。 我们开始这样做了。 我们暂时冻结了它，因为我们想省钱。 也就是说，支持使用在本地主机上运行。 您可以自己创建一个实例并在本地工作。 顺便说一句，这就是我们所做的。 我在 Getlab 和 GSP 做这件事。 但我们还没有看到进行这样的编排的意义，因为谷歌没有便宜的地方。 有 ？？？ 例，但它们也有局限性。 首先，他们总是只有 70% 的折扣，你不能玩那里的价格。 在某些情况下，我们会将价格提高 5-10%，以降低您被踢出的可能性。 也就是说，您节省了名额，但它们随时可能被夺走。 如果你出价比别人高一点，你就会被杀掉。 谷歌有完全不同的细节。 还有一个非常糟糕的限制——它们只能存活 24 小时。 有时我们想进行为期 5 天的实验。 但你可以分批进行；有时分批会持续数月。
你好！ 感谢您的报告！ 你提到了检查。 如何计算 stat_statements 错误？
非常好的问题。 我可以非常详细地向您展示和告诉您。 简而言之，我们看看请求组的集合是如何浮动的：有多少个请求组脱落了，有多少个新的请求组出现了。 然后我们看两个指标：total_time和calls，所以有两个错误。 我们看看流动团体的贡献。 有两个小组：离开的人和到达的人。 让我们看看他们对整体情况有何贡献。
你不怕它在两次快照之间会转两三次吗？
也就是说，他们是重新注册还是什么？
比如这个请求已经被抢占过一次，然后又来又被抢占，然后又来又被抢占。 你在这里计算了一些东西，而这一切都在哪里？
好问题，我们得看看。
我也做了类似的事情。 当然，更简单，我一个人做的。 但我必须重置，重置 stat_statements 并在快照时找出少于一定比例的数据，这仍然没有达到 stat_statements 可以在那里累积的上限。 我的理解是，很可能没有任何东西被取代。
是的，是的。
但我不明白还能如何可靠地做到这一点。
不幸的是，我不记得我们是否使用查询文本或 queryid 与 pg_stat_statements 并专注于它。 如果我们关注 queryid，那么理论上我们正在比较可比较的事物。
不，他可以在快照之间被强制退出并再次出现。
有相同的id吗？
是。
我们会研究这个。 好问题。 我们需要研究它。 但现在，我们看到的要么是写0……
当然，这是一种罕见的情况，但当我发现 stat_statemetns 可以取代那里时，我感到震惊。
Pg_stat_statements 中可以有很多东西。 我们发现，如果您启用了 track_utility = on，那么您的集合也会被跟踪。
是的，当然。
如果你有 java hibernate，它是随机的，那么哈希表就开始位于那里。 一旦您关闭负载非常大的应用程序，您最终会得到 50-100 个组。 那里的一切或多或少都是稳定的。 解决这个问题的一种方法是增加 pg_stat_statements.max。
是的，但你需要知道多少钱。 我们需要以某种方式关注他。 我就是做这个的。 也就是说，我有 pg_stat_statements.max。 我发现在拍摄快照时我还没有达到 70%。 好吧，所以我们没有失去任何东西。 让我们重置一下。 我们再次保存。 如果下一个快照少于 70，那么很可能您没有再丢失任何东西。
是的。 现在默认值是 5。这对于很多人来说已经足够了。
通常是的。
视频：
PS 我代表我自己补充一下，如果Postgres包含机密数据并且它不能包含在测试环境中，那么您可以使用 。 方案大概如下：
来源： habr.com