Just wondering if anyone has any thoughts on what I can do to alleviate
this issue?
I'll kinda at a loss as to what to try to tweak for this.
The most critical bit of advice I've found is setting this preference:
https://amplitude.engineering/how-a-single-postgresql-config-change-improved-slow-query-performance-by-50x-85593b8991b0
I'm using 4 512GB Samsung 850 EVOs in a hardware RAID 10 on a 1U server with
about 144 GB RAM and 8 Xeon
We have been using the Intel S3710 (or minor model variations thereof).
They have been great (consistent performance, power off safe and good
expected lifetime). Also 2 of them in RAID1 easily outperform a
reasonably large number of 10K spinners in RAID10.
Now you *can* still buy the S37xx series,
Well, I can give a measurement on my home PC, a Linux box running Ubuntu
17.10 with a Samsung 960 EVO 512GB NVME disk containing Postgres 10. Using
your pgbench init I got for example:
pgbench -c 10 -t 1 test
starting vacuum...end.
transaction type:
scaling factor: 100
query mode: simple
numb
> On Apr 10, 2018, at 3:11 PM, Dmitry Shalashov wrote:
>
> > SSDs are generally slower than spinning at sequential IO and way faster at
> > random.
>
> Unreleased yet Seagate HDD boasts 480MB/s sequential read speed [1], and no
> HDD now can achieve that.
> Even SATA-3 SSD's could be faster
> SSDs are generally slower than spinning at sequential IO and way faster
at random.
Unreleased yet Seagate HDD boasts 480MB/s sequential read speed [1], and no
HDD now can achieve that.
Even SATA-3 SSD's could be faster than that for years now (550MB/s are
quite typical), and NVME ones could be e
RDBMS such as pg are beasts that turn random IO requests, traditionally slow in
spinning drives, into sequential. WAL is a good example of this.
SSDs are generally slower than spinning at sequential IO and way faster at
random.
Expect therefore for SSD to help if you are random IO bound. (Some
You don't mention the size of your database. Does it fit in memory? If so
your disks aren't going to matter a whole lot outside of potentially being
i/o bound on the writes. Otherwise getting your data into SSDs absolutely
can have a few multiples of performance impact. The NVME M.2 drives can
real
On Tue, Apr 10, 2018 at 12:21 AM, Andreas Joseph Krogh
wrote:
> På tirsdag 10. april 2018 kl. 04:36:27, skrev Craig James <
> cja...@emolecules.com>:
>
> One of our four "big iron" (spinning disks) servers went belly up today.
> (Thanks, Postgres and pgbackrest! Easy recovery.) We're planning to
På tirsdag 10. april 2018 kl. 04:36:27, skrev Craig James mailto:cja...@emolecules.com>>:
One of our four "big iron" (spinning disks) servers went belly up today.
(Thanks, Postgres and pgbackrest! Easy recovery.) We're planning to move to a
cloud service at the end of the year, so bad timing on t
10 matches
Mail list logo
