本地卷K8s上的性能Postgresql

Question

目前，我将我们的PostgreSQL集群从一个简单的“裸金属”(vms)工作负载转换为一个容器化的K8s集群(也是在vms上)。

目前，我们运行zalando-incubator/postgres-operator并使用本地卷和volumeMode: FileSystem，卷本身是一个安装在主机上的“简单”xfs卷。

然而，我们实际上看到，在k8s内部的postgres集群中，性能下降了50%。实际上，一些重连接工作负载的性能要比以前的集群差得多，而旧集群根本不使用容器。

是否有办法调整行为，或至少衡量I/O的性能，以找出实际的瓶颈(即什么是衡量I/O的好方法，等等)。

Answer 1

有没有办法调整行为

注意可能影响集群内行为的两件事:增加缓存冲击和在节点上运行并发容器的固有问题。如果你还没有试过它，你可能想要使用污点和容忍来隔离你的PG Pods从其他的Pods，看看这是否有帮助。

测量I/O等的好方法是什么？

我希望人们习惯使用的相同的iostat工具能够在Node上工作，因为不管内核名称空间欺骗了多少，它仍然是Linux内核。

Prometheus (可能还有很多其他这样的玩具)在容器上出现了一些I/O的特定指标，我认为它们是在刮擦粒度，这意味着您可以增加刮伤频率，同时考虑到影响您的度量的观察成本:-(

它看起来像新的docker守护进程附带Prom指标。，虽然我不知道是哪个版本引入了这个功能。单独的一页正在讨论高频度量收集的含义。除了普罗米修斯出口商之外，还存在用于监视任意进程的PostgreSQL专用出口商。

在我看来，与ext4与非传统FS (如xfs )进行正面对质可能是一个非常合理的实验。我甚至不知道ext4有多少额外的生产经验，仅仅是因为地球上几乎每一个默认部署在它上的Linux的优点。您可能有很好的使用xfs的理由，但我只想确保您至少考虑到了xfs可能具有的性能特性，这使得它在像kubernetes集群这样的共享环境中成为问题。