Re: 回复: [External] Re: Separatevolumes
От | Bruce Momjian |
---|---|
Тема | Re: 回复: [External] Re: Separatevolumes |
Дата | |
Msg-id | 20200410210154.GC24987@momjian.us обсуждение исходный текст |
Ответ на | Re: 回复: [External] Re: Separate volumes (Erik Brandsberg <erik@heimdalldata.com>) |
Ответы |
Re: 回复: [External] Re: Separate volumes
|
Список | pgsql-sql |
On Fri, Apr 10, 2020 at 04:52:06PM -0400, Erik Brandsberg wrote: > A modern filesystem can help avoid even this complexity. As an example, I am > managing one PG setup that is self-hosted on an AWS EC2 instance, with 16TB of > raw storage. The bulk of that storage is in ST1, or the cheapest rotating disk > capacity available in EBS, but is using ZFS as the filesystem (with > compression, so realistically about 35TB of raw data). The instance type is a > Z1d.metal, which has two 900GB NVME drives, which have been divided to provide > swap space, as well as ZFS read and write caching. This setup has largely > offset the slow performance of the st1 disks, and kept the performance usable > (most of the data is legacy, and rarely used). I'm a big fan of keeping the > DB configuration simple, as it is way too easy to overlook tuning of a > filespace for an index, causing performance problems, while if you keep it > auto-tuning at the filesystem level, it "just works". You are saying the cloud automatically moves data between the fast and slow storage? I know many NAS systems do this, but I have also seen problems when NAS systems guess wrong. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-sql по дате отправления: