当前位置： 文江博客话题详情

EC2/EBS 上的 PostgreSQL 性能

发布于 2024-09-04 22:23:50 字数 221 浏览 8 评论 0原文

在 EC2 上运行 PostgreSQL 的最佳性能是什么？ RAID 中的 EBS？ /mnt 上的 PGData？

您有什么偏好或经历吗？在 EBS 上运行 PostgreSQL 的主要“优点”是从一个实例切换到另一个实例。这可能是比使用 /mnt 分区慢的原因吗？

PS：我正在运行 PostgreSQL 8.4，数据/大小约为 50G，Amazon EC2 xlarge(64) 实例。

原文

What gives best performance for running PostgreSQL on EC2? EBS in RAID? PGData on /mnt?

Do you have any preferences or experiences? Main "plus" for running PostgreSQL on EBS is switching from one to another instance. Can this be the reason to be slower than using the /mnt partition?

PS: I'm running PostgreSQL 8.4 with datas/size about 50G, Amazon EC2 xlarge(64) instance.

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（1）

苍景流年 2024-09-11 22:23:50

这里有一些链接信息。主要内容是 Bryan Murphy 的这篇文章：

在 Amazon 上运行一个非常繁忙的 170+ GB OLTP postgres 数据库
现在1.5年了。我不能说我很“高兴”，但我已经成功了，并且仍然更喜欢在凌晨 3 点有事时跑到市中心去科罗拉多州。
出错了。

<块引用>

有两点需要警惕：

1) 物理 I/O 不是很好，因此第一个系统如何使用 RAID0。

让我们明确一点，物理 I/O 有时很糟糕。 :)

如果您有更大的数据库，EBS 卷将成为
真正的瓶颈。我们的主数据库需要 RAID 中的 8 个 EBS 卷
驱动器，我们使用 slony 将请求卸载到两台从机上，
它仍然无法真正跟上。

我们无法在单个 EBS 卷上运行此数据库。

我还建议您使用 RAID10，而不是 RAID0。 EBS 卷失败。更多的
通常，单卷会经历很长的不良时期
表现。您的团队中拥有的驱动器越多，您获得的驱动器就越多
让事情顺利进行。然而，我们也曾遇到过这样的情况
将性能不佳的卷替换为新卷并重建
RAID 使一切恢复正常。 RAID0 无法做到这一点
数组。

<块引用>

2) 按照数据库标准，EBS 的可靠性非常糟糕；我对此发表评论
已经有点了
http://archives.postgresql.org/pgsql-general/2009- 06/msg00762.php结束
结果是您必须小心如何备份数据，并使用
推荐的方法是通过 WAL 传输进行连续流备份。
在失去一个的情况下我不会部署到这个环境中
如果 EC2/EBS 发生故障，则一两分钟的事务将
不可接受，因为这种情况更有可能发生
这里比大多数数据库硬件上都要好。

同意。我们有 3 个 WAL 运送的备件。一个流式传输我们的 WAL 文件
到我们用于最坏情况快照的单个 EBS 卷
备份。另外两个是我们主数据库的精确副本
（一个位于西海岸数据中心，另一个位于东海岸
数据中心），我们有用于故障转移的。

如果我们必须从我们的 EBS 之一进行最坏情况的恢复
快照，我们停机了六个小时，因为我们必须流式传输
数据从我们的 EBS 快照返回到 EBS raid 阵列。 170GB 于
20mb/秒（如果你幸运的话）需要很长时间。需要30到60
一旦我们创建了一个快照，其中一个快照将在几分钟内变得“可用”
从中驱动，然后我们仍然需要启动数据库并
等待热数据流回内存的时间非常长。

在过去 1.5 年里，我们不得不两次将故障转移到其中一个备用设备。
不好玩。两次都是由于实例故障造成的。

可以在 EC2 上运行更大的数据库，但这需要大量的资源
工作、周密的计划和厚脸皮。

布莱恩

Here there is some linked info. The main take-away is this post from Bryan Murphy:

Been running a very busy 170+ gb OLTP postgres database on Amazon for
1.5 years now. I can't say I'm "happy" but I've made it work and still prefer it to running downtown to a colo at 3am when something
goes wrong.

There are two main things to be wary of:

1) Physical I/O is not very good, thus how that first system used a RAID0.

Let's be clear here, physical I/O is at times terrible. :)

If you have a larger database, the EBS volumes are going to become a
real bottleneck. Our primary database needs 8 EBS volumes in a RAID
drive and we use slony to offload requests to two slave machines and
it still can't really keep up.

There's no way we could run this database on a single EBS volume.

I also recommend you use RAID10, not RAID0. EBS volumes fail. More
frequently, single volumes will experience very long periods of poor
performance. The more drives you have in your raid, the more you'll
smooth things out. However, there have been occasions where we've had
to swap out a poor performing volume for a new one and rebuild the
RAID to get things back up to speed. You can't do that with a RAID0
array.

2) Reliability of EBS is terrible by database standards; I commented on this
a bit already at
http://archives.postgresql.org/pgsql-general/2009-06/msg00762.php The end
result is that you must be careful about how you back your data up, with a
continuous streaming backup via WAL shipping being the recommended approach.
I wouldn't deploy into this environment in a situation where losing a
minute or two of transactions in the case of a EC2/EBS failure would be
unacceptable, because that's something that's a bit more likely to hapen
here than on most database hardware.

Agreed. We have three WAL-shipped spares. One streams our WAL files
to a single EBS volume which we use for worst case scenario snapshot
backups. The other two are exact replicas of our primary database
(one in the west coast data center, and the other in an east coast
data center) which we have for failover.

If we ever have to worst-case-scenario restore from one of our EBS
snapshots, we're down for six hours because we'll have to stream the
data from our EBS snapshot back over to an EBS raid array. 170gb at
20mb/sec (if you're lucky) takes a LONG time. It takes 30 to 60
minutes for one of those snapshots to become "usable" once we create a
drive from it, and then we still have to bring up the database and
wait an agonizingly long time for hot data to stream back into memory.

We had to fail over to one of our spares twice in the last 1.5 years.
Not fun. Both times were due to instance failure.

It's possible to run a larger database on EC2, but it takes a lot of
work, careful planning and a thick skin.

Bryan

回复 原文
~没有更多了~

关于作者

︶葆Ⅱㄣ

暂无简介

0 文章
0 评论
24 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

苦中寻乐

文章 0 评论 0

lueluelue

文章 0 评论 0

嗼ふ静

文章 0 评论 0

王权女流氓

文章 0 评论 0

与花如笺

文章 0 评论 0

残酷

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文