Linux 调优以提高 PostgreSQL 性能。 伊利亚·科斯莫杰米扬斯基

Ilya Kosmodemyansky 2015 年报告“Linux 调优以提高 PostgreSQL 性能”的文字记录

免责声明：我注意到这份报告的日期是 2015 年 4 月——已经过去 9.4 年多了，已经过去了很多时间。 报告中讨论的4版本不再受支持。 过去 5 年里，PostgreSQL 发布了 15 个新版本，Linux 内核也发布了 XNUMX 个版本。 如果您重写这些段落，您最终会得到不同的报告。 但在这里我们考虑对 PostgreSQL 进行基本的 Linux 调优，这在今天仍然具有现实意义。

我叫伊利亚·科斯莫杰米扬斯基。 我在 PostgreSQL 咨询公司工作。 现在我将谈谈如何使用 Linux 来处理一般数据库，特别是 PostgreSQL，因为原理非常相似。

我们会聊什么？ 如果您与 PostgreSQL 进行通信，那么在某种程度上您需要成为 UNIX 管理员。 这是什么意思？ 如果我们比较 Oracle 和 PostgreSQL，那么在 Oracle 中，您需要是 80% 的 DBA 数据库管理员和 20% 的 Linux 管理员。

对于 PostgreSQL，情况稍微复杂一些。 使用 PostgreSQL，您需要更好地了解 Linux 的工作原理。 同时，在机车后面跑一点，因为最近一切都更新得很好。 新内核的发布、新功能的出现、性能的提高等等。

我们为什么要谈论Linux？ 根本不是因为我们正在参加 Linux 会议 Peter，而是因为在现代条件下，Linux 是使用数据库（尤其是 PostgreSQL）最合理的操作系统之一。 因为不幸的是，FreeBSD 正在朝着一些非常奇怪的方向发展。 性能和许多其他方面都会出现问题。 PostgreSQL 在 Windows 上的性能通常是一个单独的严重问题，因为 Windows 没有与 UNIX 相同的共享内存，而 PostgreSQL 则与此相关，因为它是一个多进程系统。

我认为每个人都对 Solaris 这样的外来事物不太感兴趣，所以我们走吧。

现代 Linux 发行版有超过 1 个 syctl 选项，具体取决于您构建内核的方式。 同时，如果我们观察不同的坚果，我们可以通过多种方式进行调整。 有关于如何安装它们的文件系统参数。 如果您对如何启动有疑问：在 BIOS 中启用什么、如何配置硬件等。

这是一个非常大的卷，可以在几天内讨论，而不是在一篇简短的报告中，但现在我将重点关注重要的事情，如何避免那些保证会阻止您在 Linux 上使用数据库的 Rake，如果您不要纠正它们。 同时，重要的一点是许多默认参数并未包含在对数据库正确的设置中。 也就是说，默认情况下它会工作得很差或者根本不工作。

Linux 中有哪些传统的调优目标？ 我认为既然你们都在处理Linux管理，那么没有特别需要解释什么是目标。

您可以调整：

• 中央处理器。
• 记忆。
• 存储。
• 其他。 我们将在最后吃零食时讨论这个问题。 例如，甚至节能政策等参数也会以一种非常不可预测且不是最令人愉快的方式影响性能。

PostgreSQL 和数据库的具体特点是什么？ 问题是你无法调整任何一个单独的坚果并看到我们的性能得到显着提高。

是的，有这样的小工具，但数据库是一个复杂的东西。 它与服务器拥有的所有资源进行交互，并且更愿意进行最充分的交互。 如果你看看 Oracle 目前关于如何使用主机操作系统的建议，就会发现这就像蒙古宇航员的笑话一样——喂狗，不要碰任何东西。 让我们将所有资源交给数据库，数据库本身会整理所有内容。

原则上，某种程度上情况与 PostgreSQL 完全相同。 不同之处在于数据库还无法为自己获取所有资源，即在 Linux 级别的某个地方您需要自己整理所有资源。

主要思想不是选择单个目标并开始调整它，例如内存、CPU 或类似的东西，而是分析工作负载并尝试尽可能提高吞吐量，以便优秀的程序员创建它的负载对于我们，包括我们的用户。

这是一张图片来解释它是什么。 有 Linux 操作系统缓冲区、共享内存和 PostgreSQL 共享缓冲区。 与 Oracle 不同，PostgreSQL 仅通过内核缓冲区直接工作，即，为了使磁盘中的页面进入其共享内存，它必须经过内核缓冲区并返回，情况完全相同。

磁盘位于该系统下。 我把它画成磁盘。 事实上，可能还有RAID控制器等。

这种输入输出以某种方式通过这件事发生。

PostgreSQL 是一个经典的数据库。 里面有一页。 所有输入和输出都使用页面进行。 我们通过页面将块提升到内存中。 如果没有发生任何事情，我们只是读取它们，然后它们逐渐从缓存、共享缓冲区中消失，最后回到磁盘上。

如果我们替换某处的某些内容，那么整个页面都会被标记为脏。 我在这里用蓝色标记它们。 这意味着该页面必须与块存储同步。 也就是说，当我们弄脏时，我们在 WAL 中创建了一个条目。 在某个美妙的时刻，一种叫做检查点的现象出现了。 而这份日志中记录了他已经到达的信息。 这意味着此时共享缓冲区中的所有脏页都通过内核缓冲区使用 fsync 与存储磁盘同步。

为什么要这样做？ 如果我们失去电压，那么我们就不会出现所有数据都丢失的情况。 每个人都告诉我们的持久内存到目前为止在数据库理论中都是如此——这是一个光明的未来，我们当然会为之奋斗并且我们喜欢它，但目前它们的寿命还剩负 20 年。 当然，所有这一切都需要受到监控。

最大化吞吐量的任务是在所有这些阶段进行微调，以便一切快速来回移动。 共享内存基本上是一个页面缓存。 在 PostgreSQL 中，我们发送了一个选择查询或其他东西，它从磁盘检索这些数据。 它们最终进入共享缓冲区。 因此，为了更好地工作，必须有大量的内存。

为了让这一切顺利快速地工作，您需要在各个阶段正确配置操作系统。 并选择平衡的硬件，因为如果某个地方不平衡，那么您可以制造大量内存，但不会以足够的速度提供服务。

让我们逐一讨论一下这些要点。

为了使这些页面更快地来回移动，您需要实现以下目标：

• 首先，你需要更有效地利用记忆。
• 其次，页面从内存到磁盘的转换应该更加高效。
• 第三，要有好的磁盘。

如果服务器中有 512 GB RAM，并且所有这些内存最终都位于没有任何缓存的 SATA 硬盘上，那么整个数据库服务器就不仅仅是一个南瓜，而是一个带有 SATA 接口的南瓜。 你会直接遇到它。 没有什么能拯救你。

关于第一点记忆，有三件事会让生活变得非常困难。

第一个是 NUMA。 NUMA 是为了提高性能而设计的。 根据工作负载，可以优化不同的事情。 在当前的新形式中，它对于密集使用页面缓存共享缓冲区的数据库等应用程序来说并不是很好。

简而言之。 如何判断 NUMA 是否有问题？ 你有某种不愉快的敲击声，突然某个CPU超载了。 同时，您分析 PostgreSQL 中的查询，发现没有任何类似的东西。 这些查询不应该如此占用 CPU 资源。 你可以抓住这个很长一段时间。 从一开始就使用有关如何为 PostgreSQL 配置 NUMA 的正确建议会更容易。

究竟发生了什么？ NUMA 代表非统一内存访问。 重点是什么？ 你有一个CPU，旁边有它的本地内存。 这种内存互连可以从其他 CPU 中调出内存。

如果你跑 numactl --hardware，那么你就会得到这么大的一张纸。 除此之外，还有一个距离场。 会有数字——10-20，类似的东西。 这些数字只不过是获取此远程内存并在本地使用它的跳数。 原则上，这是一个好主意。 这可以在一定范围的工作负载下大大提高性能。

现在想象一下，您有一个 CPU 首先尝试使用其本地内存，然后尝试通过互连拉出另一个内存以进行某些操作。 这个 CPU 获得整个 PostgreSQL 页面缓存 - 就是这样，一些 GB。 你总是会遇到最坏的情况，因为在 CPU 上，该模块本身的内存通常很少。 所有提供服务的内存都经过这些互连。 事实证明它缓慢而悲伤。 并且为该节点提供服务的处理器不断过载。 而且这种存储器的存取时间很差、很慢。 如果您将其用于数据库，这是您不希望出现的情况。

因此，对于数据库来说，更正确的选择是让 Linux 操作系统根本不知道那里发生了什么。 这样它就可以像它一样访问内存。

这是为什么？ 似乎应该反过来才对。 发生这种情况的原因很简单：我们需要大量内存用于页面缓存 - 数十、数百 GB。

如果我们分配所有这些并将数据缓存在那里，那么使用缓存的收益将明显大于这种棘手的内存访问的收益。 与使用 NUMA 更有效地访问内存相比，我们将受益匪浅。

因此，目前有两种方法，直到光明的未来到来，数据库本身无法弄清楚它正在哪些CPU上运行以及需要从哪里提取数据。

因此，正确的做法是完全禁用 NUMA，例如，重新启动时。 在大多数情况下，奖金的数量级很大，以至于根本不存在哪个更好的问题。

还有另一种选择。 我们比第一个更频繁地使用它，因为当客户向我们寻求支持时，重新启动服务器对他来说是一件大事。 他在那里有生意。 他们会因为 NUMA 而遇到问题。 因此，我们尝试以比重启更侵入性的方式禁用它，但要小心检查它是否被禁用。 因为，正如经验所表明的，我们在父 PostgreSQL 进程上禁用 NUMA 是件好事，但它根本没有必要起作用。 我们需要检查一下她是否真的关机了。

罗伯特·哈斯 (Robert Haas) 发表了一篇很好的文章。 这是 PostgreSQL 提交者之一。 所有低级内脏的主要开发者之一。 如果您点击这篇文章中的链接，他们会描述几个关于 NUMA 如何让人们的生活变得困难的丰富多彩的故事。 看一下，研究系统管理员清单，了解需要在服务器上配置哪些内容才能使我们的数据库正常工作。 这些设置需要记下来并检查，否则效果不会很好。

请注意，这适用于我将讨论的所有设置。 但通常数据库都是以主从模式进行收集，以实现容错。 不要忘记在从机上进行这些设置，因为有一天你会发生意外，你会切换到从机，它会成为主机。

在紧急情况下，当一切都非常糟糕时，你的电话不断地响着，你的老板拿着大棒跑过来，你将没有时间考虑检查。 结果可能是相当灾难性的。

下一点是大页面。 大页面很难单独测试，而且这样做没有意义，尽管有基准测试可以做到这一点。 它们很容易被谷歌搜索到。

重点是什么？ 您有一台不是很昂贵的服务器，具有大量 RAM，例如超过 30 GB。 您不使用大页面。 这意味着您在内存使用方面肯定有开销。 而这种开销远非最令人愉快的。

这是为什么？ 发生什么了？ 操作系统将内存分配为小块。 太方便了，历史上就是这样发生的。 如果我们详细讨论的话，操作系统必须将虚拟地址转换为物理地址。 而且这个过程并不是最简单的，因此操作系统将这个操作的结果缓存在Translation Lookaside Buffer（TLB）中。

而且由于TLB是一个缓存，因此缓存固有的所有问题都会在这种情况下出现。 首先，如果你有很多 RAM 并且都是以小块的形式分配的，那么这个缓冲区就会变得非常大。 如果缓存很大，则搜索速度会更慢。 开销是健康的，它本身会占用空间，即 RAM 被不正确的东西消耗。 这次。

第二 - 在这种情况下缓存增长得越多，缓存未命中的可能性就越大。 并且该缓存的效率随着其大小的增加而迅速下降。 因此，操作系统想出了一个简单的方法。 它在 Linux 中已经使用了很长时间。 不久前它出现在 FreeBSD 中。 但我们谈论的是Linux。 这些是巨大的页面。

这里应该指出的是，大页面作为一个想法，最初是由包括 Oracle 和 IBM 在内的社区推动的，即数据库制造商强烈认为这对数据库也很有用。

这怎么能和 PostgreSQL 交上朋友呢？ 首先，必须在 Linux 内核中启用大页。

其次，它们必须由 sysctl 参数显式指定 - 有多少个。 这里的数字来自一些旧服务器。 您可以计算有多少个共享缓冲区，以便可以容纳大页面。

如果您的整个服务器专用于 PostgreSQL，那么一个好的起点是将 25% 的 RAM 分配给共享缓冲区，或者如果您确定您的数据库肯定适合这 75%，则分配 75%。 起点一。 考虑一下，如果您有 256 GB 的 RAM，那么相应地，您将拥有 64 GB 的大缓冲区。 大约计算一些余量 - 该数字应设置为多少。

在 9.2 版本之前（如果我没记错的话，从 8.2 版本开始），可以使用第三方库将 PostgreSQL 与大页面连接起来。 并且应该始终这样做。 首先，您需要内核能够正确分配大页面。 其次，以便与它们一起工作的应用程序可以使用它们。 它不会只是这样使用。 由于 PostgreSQL 以系统 5 风格分配内存，因此可以使用 libhugetlbfs 来完成 - 这是库的全名。

在 9.3 中，PostgreSQL 在使用内存时的性能得到了提高，并且放弃了 system 5 内存分配方法。 每个人都很高兴，因为否则你尝试在一台机器上运行两个 PostgreSQL 实例，他说我没有足够的共享内存。 他说 sysctl 需要纠正。 而且有这么一个sysctl还需要重启等等。总的来说，大家都很高兴。 但是mmap内存分配打破了大页的使用。 我们的大多数客户都使用大型共享缓冲区。 我们强烈建议不要切换到 9.3，因为那里的开销开始以良好的百分比计算。

但社区注意到了这个问题，在 9.4 中他们很好地重做了这个事件。 在 9.4 中，postgresql.conf 中出现了一个参数，您可以在其中启用 try、on 或 off。

尝试是最安全的选择。 当PostgreSQL启动时，当它分配共享内存时，它会尝试从大页中获取这块内存。 如果不起作用，则会回滚到正常选择。 如果你有 FreeBSD 或 Solaris，那么你可以尝试一下，它总是安全的。

如果打开，则如果无法从大页面中进行选择，则它根本不会启动。 这里已经是关于谁和什么更好的问题了。 但如果您尝试过，请检查是否确实突出显示了您需要的内容，因为存在很大的出错空间。 目前此功能仅适用于 Linux。

在我们进一步讨论之前，还有一个小注释。 透明大页还不是关于 PostgreSQL 的。 他无法正常使用它们。 对于此类工作负载，使用透明大页，当需要大块共享内存时，只有非常大的容量才能带来好处。 如果您有 TB 的内存，那么这可能会发挥作用。 如果我们谈论的是更日常的应用程序，当您的机器上有 32、64、128、256 GB 内存时，那么通常的大页面就可以了，我们只需禁用透明即可。

最后一个关于记忆的事情与成果没有直接关系，它真的可以毁掉你的生活。 服务器不断交换的事实将极大地影响所有吞吐量。

这在很多方面都会令人非常不愉快。 主要问题是现代内核的行为与旧版 Linux 内核略有不同。 而这个东西踩起来相当不愉快，因为当我们谈论某种与swap有关的工作时，它就以OOM杀手的不合时宜的到来而告终。 而 OOM-killer 没有及时到达并丢弃了 PostgreSQL，令人不快。 每个人都会知道这一点，即直到最后一个用户。

发生了什么？ 你有大量的内存，一切都运行良好。 但由于某种原因，服务器挂在交换中并因此变慢。 看起来内存很多，但是却发生了这种情况。

以前，我们建议将 vm.swappiness 设置为零，即禁用交换。 以前，32 GB RAM 和相应的共享缓冲区似乎是一个巨大的数字。 交换的主要目的是当我们摔倒时有一个地方可以扔掉外壳。 而且也不再特别满足了。 然后你打算用这个外壳做什么呢？ 这是一项不太清楚为什么需要交换的任务，尤其是对于这样大的大小。

但在更现代的内核第三版本中，行为发生了变化。 如果你将交换设置为零，即关闭它，那么迟早，即使还有一些 RAM 剩余，OOM 杀手也会来找你杀死最密集的消费者。 因为他会考虑到这么大的工作量我们还剩下一点点，我们就会跳出来，就是不去敲定系统流程，而是去敲定一些不太重要的东西。 这个不太重要的角色是共享内存的密集消耗者，即邮政局长。 在那之后，如果不需要修复基地就好了。

因此，据我所知，现在默认情况下，大多数发行版都在 6 左右，即您应该在什么时候开始使用交换，具体取决于剩余内存量。 我们现在建议设置 vm.swappiness = 1，因为这实际上会将其关闭，但不会产生与意外到达并杀死整个事件的 OOM 杀手相同的效果。

下一步是什么？ 当我们谈论数据库的性能并逐渐转向磁盘时，每个人都开始抓头。 因为磁盘慢、内存快这个道理大家从小就熟悉。 而且大家都知道数据库会出现磁盘性能问题。

与检查点峰值相关的主要 PostgreSQL 性能问题不会发生，因为磁盘速度很慢。 这很可能是由于内存和磁盘带宽不平衡造成的。 然而，它们在不同的地方可能并不平衡。 PostgreSQL未配置、操作系统未配置、硬件未配置、硬件不正确。 只有当一切都按其应有的方式发生时，即没有负载，或者设置和硬件选择良好时，这个问题才不会发生。

它是什么以及它看起来像什么？ 通常使用 PostgreSQL 的人都会不止一次地涉及到这个问题。 我会解释一下。 正如我所说，PostgreSQL 定期创建检查点以将共享内存中的脏页转储到磁盘。 如果我们有大量共享内存，那么检查点开始对磁盘产生强烈影响，因为它会使用 fsync 转储这些页面。 它到达内核缓冲区并使用 fsync 写入磁盘。 如果该业务量很大，那么我们可以观察到一个令人不快的效果，即磁盘利用率非常高。

这里我有两张照片。 我现在将解释它是什么。 这是两个时间相关的图。 第一张图是磁盘利用率。 此时它几乎达到了 90%。 如果您的物理磁盘出现数据库故障，并且 RAID 控制器利用率为 90%，那么这是个坏消息。 这意味着再多一点，就会达到 100，I/O 将停止。

如果您有磁盘阵列，那么情况会略有不同。 这取决于它的配置方式、它是什么类型的数组等等。

同时，这里配置了来自内部 postgres 视图的图表，它告诉我们检查点是如何发生的。 这里的绿色显示了有多少缓冲区，这些脏页，在那一刻到达了这个检查点进行同步。 这是您需要了解的主要内容。 我们看到这里有很多页面，在某个时刻我们撞到了木板，也就是说，我们写了又写，这里磁盘系统显然非常繁忙。 而我们的检查点对磁盘的影响非常大。 理想情况下，情况应该更像这样，即我们这里的录音较少。 我们可以通过设置来修复它，以便它继续这样。 也就是说，回收量很小，但我们正在这里某处写一些东西。

需要做什么来克服这个问题？ 如果你已经停止了数据库下的IO，这意味着所有前来满足其请求的用户都将等待。

如果你从 Linux 的角度来看，如果你使用了良好的硬件，正确配置了它，正常配置了 PostgreSQL，这样就可以减少这些检查点的频率，随着时间的推移将它们分散在彼此之间，那么你就进入了默认的 Debian 参数。 对于大多数 Linux 发行版，如下图：vm.dirty_ratio=20，vm.dirty_background_ratio=10。

这是什么意思？ 2.6 内核中出现了一个刷新恶魔。 Pdglush，取决于谁在使用哪个，它从事后台丢弃内核缓冲区中的脏页，并在无论如何都需要丢弃脏页时丢弃，当后台丢弃没有帮助时。

背景什么时候来？ 当服务器上可用总 RAM 的 10% 被内核缓冲区中的脏页占用时，会在后台调用一个特殊的注销函数。 为什么是背景呢？ 作为一个参数，它考虑了要注销的页数。 假设他注销了 N 页。 有一段时间这个东西睡着了。 然后她又来了，又复印了几页。

这是一个极其简单的故事。 这里的问题就像游泳池一样，当水倒入一根管子时，它就会流入另一根管子。 我们的检查点到达了，如果它发送了一些脏页进行丢弃，那么整个事情将逐渐从内核缓冲区 pgflush 中得到巧妙的解决。

如果这些脏页继续积累，它们会积累到20%，之后操作系统的优先级就是将整个内容写到磁盘上，因为电源将会失效，一切都会对我们不利。 例如，我们将丢失这些数据。

有什么窍门呢？ 诀窍在于，在现代世界中，这些参数分别占机器上总 RAM 的 20% 和 10%，就您拥有的任何磁盘系统的吞吐量而言，它们绝对是巨大的。

假设您有 128 GB 的 RAM。 12,8 GB 到达您的磁盘系统。 无论你有什么缓存，无论你有什么阵列，它们都不会持续那么久。

因此，我们建议您立即根据 RAID 控制器的功能调整这些数字。 我立即在这里推荐了具有 512 MB 缓存的控制器。

一切都被认为非常简单。 您可以将 vm.dirty_background 以字节为单位。 而这些设置取消了前面的两项。 要么是默认的比例，要么激活带字节的，那么带字节的就可以了。 但由于我是一名 DBA 顾问，并且与不同的客户合作，所以我会尝试抽签，因此，如果以字节为单位，那就以字节为单位。 没有人能保证优秀的管理员不会向服务器添加更多内存，重新启动服务器，并且数字将保持不变。 只需计算这些数字，以便一切都符合其中的保证。

如果你不适应会发生什么？ 我曾经写过，任何冲水都会被有效地阻止，但实际上这是一种比喻。 操作系统有一个大问题 - 它有很多脏页，因此客户端生成的 IO 实际上已停止，即应用程序已向数据库发送 sql 查询，它正在等待。 它的任何输入/输出都是最低优先级的，因为数据库被检查点占用。 她什么时候能完成还完全不清楚。 而当你实现了非后台刷新，就意味着你所有的IO都被它占用了。 在它结束之前，你什么也做不了。

这里还有两点超出了本报告的范围。 这些设置应该与 postgresql.conf 中的设置匹配，即检查点设置。 并且您的磁盘系统必须经过充分配置。 如果 RAID 上有缓存，那么它必须有电池。 人们购买具有良好缓存的 RAID，但不带电池。 如果你有RAID的SSD，那么它们一定是服务器的，那里一定有电容。 这是详细的清单。 此链接包含我有关如何在 PostgreSQL 中配置性能磁盘的报告。 那里有所有这些清单。

还有什么能让生活变得非常困难呢？ 这是两个参数。 它们相对较新。 默认情况下，它们可以包含在不同的应用程序中。 如果它们的开启方式不正确，它们也会让生活变得同样困难。

有两个相对较新的事物。 他们已经出现在了第三核心之中。 这是以纳秒为单位的 sched_migration_cost 和 sched_autogroup_enabled，默认情况下为 XNUMX。

他们如何毁掉你的生活？ 什么是 sched_migration_cost？ 在 Linux 上，调度程序可以将进程从一个 CPU 迁移到另一个 CPU。 而对于执行查询的 PostgreSQL 来说，迁移到另一个 CPU 是完全不清楚的。 从操作系统的角度来看，当你在openoffice和terminal之间切换窗口时，这可能很好，但是 对于数据库来说这是非常糟糕的。 因此，合理的策略是将migration_cost设置为某个大值，至少几千纳秒。

这对于调度程序意味着什么？ 在此期间，将认为该过程仍然是热的。 也就是说，如果您有一个长时间运行的事务，并且已经做了很长时间的某件事，那么调度程序就会理解这一点。 他将假设在超时过去之前，无需将此进程迁移到任何地方。 如果进程同时执行某些操作，那么它不会被迁移到任何地方，它将静静地在分配给它的 CPU 上工作。 结果非常好。

第二点是自动分组。 对于与现代数据库无关的特定工作负载，有一个好主意 - 即按启动进程的虚拟终端对进程进行分组。 这对于某些任务来说很方便。 实际上，PostgreSQL 是一个多进程系统，具有从单个终端运行的预分叉。 您有一个锁编写器、检查点，并且所有客户端请求将被分组到每个 CPU 的一个调度程序中。 他们会齐声在那里等待他自由，以便互相干扰，让他忙得更久。 这是一个在这样的负载情况下完全没有必要的故事，因此需要将其关闭。

我的同事 Alexey Lesovsky 使用一个简单的 pgbench 进行了测试，他将 migration_cost 增加了一个数量级并关闭了 autogroup。 坏硬件上的差异几乎为 10%。 在 postgres 邮件列表上有一个讨论，人们给出了类似的查询速度变化的结果 影响50%。 这样的故事还有很多。

最后，关于节能政策。 好消息是 Linux 现在可以在笔记本电脑上使用。 据说它会很好地耗尽电池。 但突然发现这也可能发生在服务器上。

此外，如果您从某个托管商那里租用服务器，那么“好”托管商并不关心您是否有更好的性能。 他们的任务是确保尽可能有效地利用铁。 因此，默认情况下他们可以在操作系统上启用笔记本电脑省电模式。

如果你在数据库负载很重的服务器上使用这个东西，那么你的选择是 acpi_cpufreq + permormance。 即使使用 ondemand 也会出现问题。

Intel_pstate 是一个略有不同的驱动程序。 现在优先选择这个，因为它更晚并且效果更好。

而且，相应地，州长只是表现。 点播、省电和其他一切都与您无关。

如果启用 powersave，解释分析 PostgreSQL 的结果可能会相差几个数量级，因为实际上数据库下的 CPU 将以完全不可预测的方式运行。

默认情况下可能包含这些项目。 仔细查看他们是否默认打开它。 这可能是一个很大的问题。

最后，我想对 PosgreSQL 咨询 DBA 团队的 Max Boguk 和 Alexey Lesovsky 表示感谢，他们每天都在这个问题上取得进展。 我们尽力为客户提供最好的服务，让一切都对他们有利。 就像航空安全说明一样。 这里的一切都是用血写成的。 这些坚果中的每一个都是在某种问题的过程中发现的。 我很高兴与您分享它们。

问题：

谢谢你！ 例如，如果一家公司想要省钱，将数据库和应用程序逻辑放在一台服务器上，或者如果公司遵循微服务架构的流行趋势，其中 PostgreSQL 在容器中运行。 有什么窍门呢？ Sysctl会全局影响整个内核。 我还没有听说过 sysctls 以某种方式虚拟化，以便它们在容器上单独工作。 只有一个cgroup，并且那里只有部分控制。 你怎么能忍受这个呢？ 或者如果您想要性能，那么在单独的硬件服务器上运行 PostgreSQL 并对其进行调整？

我们通过大约三种方式回答了你的问题。 如果我们不是在谈论可以调整的硬件服务器等，那么放松一下，没有这些设置一切都会正常工作。 如果你有这样的负载，你需要进行这些设置，那么你会比这些设置更早来到iron服务器。

问题是什么？ 如果这是虚拟机，那么您很可能会遇到很多问题，例如，在大多数虚拟机上，磁盘的延迟非常不一致。 即使磁盘吞吐量很好，那么一个失败的 I/O 事务不会对检查点时或写入 WAL 时发生的平均吞吐量产生很大影响，那么数据库将受到很大影响。 在遇到这些问题之前您会注意到这一点。

如果你在同一台服务器上有NGINX，你也会遇到同样的问题。 他将为共享记忆而战。 而且您不会遇到此处描述的问题。

但另一方面，其中一些参数仍然与您相关。 例如，使用 sysctl 设置 dirty_ratio，这样它就不会那么疯狂 - 无论如何，这都会有所帮助。 无论哪种方式，您都将与磁盘进行交互。 而且它会遵循错误的模式。 这通常是我所展示的参数的默认值。 无论如何，最好改变它们。

但NUMA可能会出现问题。 例如，VmWare 可以在完全相反的设置下与 NUMA 配合良好。 在这里你必须选择 - 铁制服务器或非铁制服务器。

我有一个与 Amazon AWS 相关的问题。 他们预先配置了图像。 其中之一称为 Amazon RDS。 他们的操作系统有任何自定义设置吗？

那里有设置，但它们是不同的设置。 这里我们根据数据库如何使用这个东西来配置操作系统。 还有一些参数决定我们现在应该去哪里，例如塑造。 也就是说，我们需要如此多的资源，我们现在就把它们吃光了。 此后，Amazon RDS 会收紧这些资源，并且性能会下降。 有一些关于人们如何开始搞乱这个问题的故事。 有时甚至相当成功。 但这与操作系统设置无关。 这就像破解云。 那是一个不同的故事。

为什么透明大页与Huge TLB相比没有效果？

不要给。 这可以从很多方面来解释。 但事实上他们根本不给。 PostgreSQL 的历史是什么？ 启动时，它会分配一大块共享内存。 它们是否透明完全无关紧要。 他们一开始就脱颖而出的事实说明了一切。 如果有大量内存并且需要重建shared_memory段，那么透明大页面将是相关的。 在 PostgreSQL 中，它只是在开始时被分配在一个巨大的块中，仅此而已，然后就没有什么特别的事情发生了。 当然，您可以使用它，但是当它重新分配某些内容时，有可能会损坏共享内存。 PostgreSQL 不知道这一点。

来源： habr.com