public inbox for [email protected]
help / color / mirror / Atom feedTuning guidelines for server with 256GB of RAM and SSDs?
12+ messages / 6 participants
[nested] [flat]
* Tuning guidelines for server with 256GB of RAM and SSDs?
@ 2016-07-05 14:50 Kaixi Luo <[email protected]>
2016-07-06 18:13 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Merlin Moncure <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Kaixi Luo @ 2016-07-05 14:50 UTC (permalink / raw)
To: pgsql-performance
Hello,
I've been reading Mr. Greg Smith's "Postgres 9.0 - High Performance" book
and I have some questions regarding the guidelines I found in the book,
because I suspect some of them can't be followed blindly to the letter on a
server with lots of RAM and SSDs.
Here are my server specs:
Intel Xeon E5-1650 v3 Hexa-Core Haswell
256GB DDR4 ECC RAM
Battery backed hardware RAID with 512MB of WriteBack cache (LSI MegaRAID
SAS 9260-4i)
RAID1 - 2x480GB Samsung SSD with power loss protection (will be used to
store the PostgreSQL database)
RAID1 - 2x240GB Crucial SSD with power loss protection. (will be used to
store PostgreSQL transactions logs)
First of all, the book suggests that I should enable the WriteBack cache of
the HWRAID and disable the disk cache to increase performance and ensure
data safety. Is it still advisable to do this on SSDs, specifically the
step of disabling the disk cache? Wouldn't that increase the wear rate of
the SSD?
Secondly, the book suggests that we increase the device readahead from 256
to 4096. As far as I understand, this was done in order to reduce the
number of seeks on a rotating hard drive, so again, is this still
applicable to SSDs?
The other tunable I've been looking into is vm.dirty_ratio and
vm.dirty_background_ratio. I reckon that the book's recommendation to lower
vm.dirty_background_ratio to 5 and vm.dirty_ratio to 10 is not enough for a
server with such big amount of RAM. How much lower should I set these
values, given that my RAID's WriteBack cache size is 512MB?
Thank you very much.
Kaixi Luo
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Tuning guidelines for server with 256GB of RAM and SSDs?
2016-07-05 14:50 Tuning guidelines for server with 256GB of RAM and SSDs? Kaixi Luo <[email protected]>
@ 2016-07-06 18:13 ` Merlin Moncure <[email protected]>
2016-07-06 21:48 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Scott Marlowe <[email protected]>
2016-07-06 22:34 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Wes Vaske (wvaske) <[email protected]>
0 siblings, 2 replies; 12+ messages in thread
From: Merlin Moncure @ 2016-07-06 18:13 UTC (permalink / raw)
To: Kaixi Luo <[email protected]>; +Cc: pgsql-performance
On Tue, Jul 5, 2016 at 9:50 AM, Kaixi Luo <[email protected]> wrote:
> Hello,
>
> I've been reading Mr. Greg Smith's "Postgres 9.0 - High Performance" book
> and I have some questions regarding the guidelines I found in the book,
> because I suspect some of them can't be followed blindly to the letter on a
> server with lots of RAM and SSDs.
>
> Here are my server specs:
>
> Intel Xeon E5-1650 v3 Hexa-Core Haswell
> 256GB DDR4 ECC RAM
> Battery backed hardware RAID with 512MB of WriteBack cache (LSI MegaRAID SAS
> 9260-4i)
> RAID1 - 2x480GB Samsung SSD with power loss protection (will be used to
> store the PostgreSQL database)
> RAID1 - 2x240GB Crucial SSD with power loss protection. (will be used to
> store PostgreSQL transactions logs)
>
> First of all, the book suggests that I should enable the WriteBack cache of
> the HWRAID and disable the disk cache to increase performance and ensure
> data safety. Is it still advisable to do this on SSDs, specifically the step
> of disabling the disk cache? Wouldn't that increase the wear rate of the
> SSD?
At the time that book was written, the majority of SSDs were known not
to be completely honest and/or reliable about data integrity in the
face of a power event. Now it's a hit or miss situation (for example,
see here: http://blog.nordeus.com/dev-ops/power-failure-testing-with-ssds.htm).
The intel drives S3500/S3700 and their descendants are the standard
against which other drives should be judged IMO. The S3500 family in
particular offers tremendous value for database usage. Do your
research; the warning is still relevant but the blanket statement no
longer applies. Spinning drives are completely obsolete for database
applications in my experience.
Disabling write back cache for write heavy database loads will will
destroy it in short order due to write amplication and will generally
cause it to underperform hard drives in my experience.
With good SSDs and a good motherboard, I do not recommend a caching
raid controller; software raid is a better choice for many reasons.
One parameter that needs to be analyzed with SSD is
effective_io_concurrency. see
https://www.postgresql.org/message-id/CAHyXU0yiVvfQAnR9cyH%3DHWh1WbLRsioe%3DmzRJTHwtr%3D2azsTdQ%40ma...
merlin
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Tuning guidelines for server with 256GB of RAM and SSDs?
2016-07-05 14:50 Tuning guidelines for server with 256GB of RAM and SSDs? Kaixi Luo <[email protected]>
2016-07-06 18:13 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Merlin Moncure <[email protected]>
@ 2016-07-06 21:48 ` Scott Marlowe <[email protected]>
2016-07-07 16:27 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Merlin Moncure <[email protected]>
1 sibling, 1 reply; 12+ messages in thread
From: Scott Marlowe @ 2016-07-06 21:48 UTC (permalink / raw)
To: Merlin Moncure <[email protected]>; +Cc: Kaixi Luo <[email protected]>; pgsql-performance
On Wed, Jul 6, 2016 at 12:13 PM, Merlin Moncure <[email protected]> wrote:
> Disabling write back cache for write heavy database loads will will
> destroy it in short order due to write amplication and will generally
> cause it to underperform hard drives in my experience.
Interesting. We found our best performance with a RAID-5 of 10 800GB
SSDs (Intel 3500/3700 series) that we got MUCH faster performance with
all write caching turned off on our LSI MEgaRAID controllers. We went
from 3 to 4ktps to 15 to 18ktps. And after a year of hard use we still
show ~90% life left (these machines handle thousands of writes per
second in real use) It could be that the caching was getting in the
way of RAID calcs or some other issue. With RAID-1 I have no clue what
the performance will be with write cache on or off.
--
To understand recursion, one must first understand recursion.
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Tuning guidelines for server with 256GB of RAM and SSDs?
2016-07-05 14:50 Tuning guidelines for server with 256GB of RAM and SSDs? Kaixi Luo <[email protected]>
2016-07-06 18:13 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Merlin Moncure <[email protected]>
2016-07-06 21:48 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Scott Marlowe <[email protected]>
@ 2016-07-07 16:27 ` Merlin Moncure <[email protected]>
2016-07-07 17:00 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Scott Marlowe <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Merlin Moncure @ 2016-07-07 16:27 UTC (permalink / raw)
To: Scott Marlowe <[email protected]>; +Cc: Kaixi Luo <[email protected]>; pgsql-performance
On Wed, Jul 6, 2016 at 4:48 PM, Scott Marlowe <[email protected]> wrote:
> On Wed, Jul 6, 2016 at 12:13 PM, Merlin Moncure <[email protected]> wrote:
>> Disabling write back cache for write heavy database loads will will
>> destroy it in short order due to write amplication and will generally
>> cause it to underperform hard drives in my experience.
>
> Interesting. We found our best performance with a RAID-5 of 10 800GB
> SSDs (Intel 3500/3700 series) that we got MUCH faster performance with
> all write caching turned off on our LSI MEgaRAID controllers. We went
> from 3 to 4ktps to 15 to 18ktps. And after a year of hard use we still
> show ~90% life left (these machines handle thousands of writes per
> second in real use) It could be that the caching was getting in the
> way of RAID calcs or some other issue. With RAID-1 I have no clue what
> the performance will be with write cache on or off.
Right -- by that I meant disabling the write back cache on the drive
itself, so that all writes are immediately flushed. Disabling write
back on the raid controller should be the right choice; each of these
drives essentially is a 'caching raid controller' for all intents and
purposes. Hardware raid controllers are engineered around performance
and reliability assumptions that are no longer correct in an SSD
world. Personally I would have plugged the drives directly to the
motherboard (assuming it's a got enough lanes) and mounted the raid
against mdadm and compared.
merlin
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Tuning guidelines for server with 256GB of RAM and SSDs?
2016-07-05 14:50 Tuning guidelines for server with 256GB of RAM and SSDs? Kaixi Luo <[email protected]>
2016-07-06 18:13 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Merlin Moncure <[email protected]>
2016-07-06 21:48 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Scott Marlowe <[email protected]>
2016-07-07 16:27 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Merlin Moncure <[email protected]>
@ 2016-07-07 17:00 ` Scott Marlowe <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Scott Marlowe @ 2016-07-07 17:00 UTC (permalink / raw)
To: Merlin Moncure <[email protected]>; +Cc: Kaixi Luo <[email protected]>; pgsql-performance
On Thu, Jul 7, 2016 at 10:27 AM, Merlin Moncure <[email protected]> wrote:
> On Wed, Jul 6, 2016 at 4:48 PM, Scott Marlowe <[email protected]> wrote:
>> On Wed, Jul 6, 2016 at 12:13 PM, Merlin Moncure <[email protected]> wrote:
>>> Disabling write back cache for write heavy database loads will will
>>> destroy it in short order due to write amplication and will generally
>>> cause it to underperform hard drives in my experience.
>>
>> Interesting. We found our best performance with a RAID-5 of 10 800GB
>> SSDs (Intel 3500/3700 series) that we got MUCH faster performance with
>> all write caching turned off on our LSI MEgaRAID controllers. We went
>> from 3 to 4ktps to 15 to 18ktps. And after a year of hard use we still
>> show ~90% life left (these machines handle thousands of writes per
>> second in real use) It could be that the caching was getting in the
>> way of RAID calcs or some other issue. With RAID-1 I have no clue what
>> the performance will be with write cache on or off.
>
> Right -- by that I meant disabling the write back cache on the drive
> itself, so that all writes are immediately flushed. Disabling write
> back on the raid controller should be the right choice; each of these
> drives essentially is a 'caching raid controller' for all intents and
> purposes. Hardware raid controllers are engineered around performance
> and reliability assumptions that are no longer correct in an SSD
> world. Personally I would have plugged the drives directly to the
> motherboard (assuming it's a got enough lanes) and mounted the raid
> against mdadm and compared.
Oh yeah definitely. And yea we've found that mdadm and raw HBAs work
better than most RAID controllers for SSDs.
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Tuning guidelines for server with 256GB of RAM and SSDs?
2016-07-05 14:50 Tuning guidelines for server with 256GB of RAM and SSDs? Kaixi Luo <[email protected]>
2016-07-06 18:13 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Merlin Moncure <[email protected]>
@ 2016-07-06 22:34 ` Wes Vaske (wvaske) <[email protected]>
2016-07-07 21:06 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Kaixi Luo <[email protected]>
1 sibling, 1 reply; 12+ messages in thread
From: Wes Vaske (wvaske) @ 2016-07-06 22:34 UTC (permalink / raw)
To: Merlin Moncure <[email protected]>; Kaixi Luo <[email protected]>; +Cc: pgsql-performance
Regarding the Nordeus blog Merlin linked.
They say:
"This doesn't mean the data was really written to disk, it can still remain in the disk cache, but enterprise drives usually make sure the data was really written to disk on fsync calls."
This isn't actually true for enterprise drives (when I say enterprise in the context of an SSD, I'm assuming full power loss protection via capacitors on the drive like the Intel DC S3x00 series). Most enterprise SSDs will ignore calls to disable disk cache or to flush the disk cache as doing so is entirely unnecessary.
Regarding write back cache:
Disabling the write back cache won't have a real large impact on the endurance of the drive unless it reduces the total number of bytes written (which it won't). I've seen drives that perform better with it disabled and drives that perform better with it enabled. I would test in your environment and make the decision based on performance.
Regarding the Crucial drive for logs:
As far as I'm aware, none of the Crucial drives have power loss protection. To use these drives you would want to disable disk cache which would drop your performance a fair bit.
Write amplification:
I wouldn't expect write amplification to be a serious issue unless you hit every LBA on the device early in its life and never execute TRIM. This is one of the reasons software RAID can be a better solution for something like this. MDADM supports TRIM in RAID devices. So unless you run the drives above 90% full, the write amplification would be minimal so long as you have a daily fstrim cron job.
Wes Vaske | Senior Storage Solutions Engineer
Micron Technology
________________________________________
From: [email protected] <[email protected]> on behalf of Merlin Moncure <[email protected]>
Sent: Wednesday, July 6, 2016 1:13 PM
To: Kaixi Luo
Cc: postgres performance list
Subject: Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?
On Tue, Jul 5, 2016 at 9:50 AM, Kaixi Luo <[email protected]> wrote:
> Hello,
>
> I've been reading Mr. Greg Smith's "Postgres 9.0 - High Performance" book
> and I have some questions regarding the guidelines I found in the book,
> because I suspect some of them can't be followed blindly to the letter on a
> server with lots of RAM and SSDs.
>
> Here are my server specs:
>
> Intel Xeon E5-1650 v3 Hexa-Core Haswell
> 256GB DDR4 ECC RAM
> Battery backed hardware RAID with 512MB of WriteBack cache (LSI MegaRAID SAS
> 9260-4i)
> RAID1 - 2x480GB Samsung SSD with power loss protection (will be used to
> store the PostgreSQL database)
> RAID1 - 2x240GB Crucial SSD with power loss protection. (will be used to
> store PostgreSQL transactions logs)
>
> First of all, the book suggests that I should enable the WriteBack cache of
> the HWRAID and disable the disk cache to increase performance and ensure
> data safety. Is it still advisable to do this on SSDs, specifically the step
> of disabling the disk cache? Wouldn't that increase the wear rate of the
> SSD?
At the time that book was written, the majority of SSDs were known not
to be completely honest and/or reliable about data integrity in the
face of a power event. Now it's a hit or miss situation (for example,
see here: http://blog.nordeus.com/dev-ops/power-failure-testing-with-ssds.htm).
The intel drives S3500/S3700 and their descendants are the standard
against which other drives should be judged IMO. The S3500 family in
particular offers tremendous value for database usage. Do your
research; the warning is still relevant but the blanket statement no
longer applies. Spinning drives are completely obsolete for database
applications in my experience.
Disabling write back cache for write heavy database loads will will
destroy it in short order due to write amplication and will generally
cause it to underperform hard drives in my experience.
With good SSDs and a good motherboard, I do not recommend a caching
raid controller; software raid is a better choice for many reasons.
One parameter that needs to be analyzed with SSD is
effective_io_concurrency. see
https://www.postgresql.org/message-id/CAHyXU0yiVvfQAnR9cyH%3DHWh1WbLRsioe%3DmzRJTHwtr%3D2azsTdQ%40ma...
merlin
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Tuning guidelines for server with 256GB of RAM and SSDs?
2016-07-05 14:50 Tuning guidelines for server with 256GB of RAM and SSDs? Kaixi Luo <[email protected]>
2016-07-06 18:13 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Merlin Moncure <[email protected]>
2016-07-06 22:34 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Wes Vaske (wvaske) <[email protected]>
@ 2016-07-07 21:06 ` Kaixi Luo <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Kaixi Luo @ 2016-07-07 21:06 UTC (permalink / raw)
To: Wes Vaske (wvaske) <[email protected]>; Merlin Moncure <[email protected]>; +Cc: pgsql-performance
> Regarding write back cache:
> Disabling the write back cache won't have a real large impact on the
> endurance of the drive unless it reduces the total number of bytes written
> (which it won't). I've seen drives that perform better with it disabled and
> drives that perform better with it enabled. I would test in your
> environment and make the decision based on performance.
>
>
Thanks. I assume you are referring to the write back cache on the RAID
controller here and not the disk cache itself.
Kaixi
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Tuning guidelines for server with 256GB of RAM and SSDs?
@ 2016-07-05 19:17 Mkrtchyan, Tigran <[email protected]>
2016-07-07 04:59 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Mark Kirkwood <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Mkrtchyan, Tigran @ 2016-07-05 19:17 UTC (permalink / raw)
To: Kaixi Luo <[email protected]>; +Cc: pgsql-performance
<p dir="ltr">Hi, </p>
<p dir="ltr">We had a similar situation and the best performance was with 64MB background_bytes and 512 MB dirty_bytes.</p>
<p dir="ltr">Tigran.<br>
</p>
<div class="gmail_quote">On Jul 5, 2016 16:51, Kaixi Luo <[email protected]> wrote:<br type='attribution'><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br /></div><div>I've been reading Mr. Greg Smith's "Postgres 9.0 - High Performance" book and I have some questions regarding the guidelines I found in the book, because I suspect some of them can't be followed blindly to the letter on a server with lots of RAM and SSDs.</div><div><br /></div><div>Here are my server specs:</div><div><br /></div><div><div>Intel Xeon E5-1650 v3 <span style="line-height:1.5">Hexa-Core Haswell </span></div></div><div>256GB DDR4 ECC RAM</div><div>Battery backed hardware RAID with 512MB of WriteBack cache (LSI MegaRAID SAS 9260-4i)</div><div>RAID1 - 2x480GB Samsung SSD with power loss protection (will be used to store the PostgreSQL database)</div><div>RAID1 - 2x240GB Crucial SSD with power loss protection. (will be used to store PostgreSQL transactions logs)</div><div><br /></div><div>First of all, the book suggests that I should enable the WriteBack cache of the HWRAID and disable the disk cache to increase performance and ensure data safety. Is it still advisable to do this on SSDs, specifically the step of disabling the disk cache? Wouldn't that increase the wear rate of the SSD?</div><div><br /></div><div>Secondly, the book suggests that we increase the device readahead from 256 to 4096. As far as I understand, this was done in order to reduce the number of seeks on a rotating hard drive, so again, is this still applicable to SSDs?</div><div><br /></div><div>The other tunable I've been looking into is vm.dirty_ratio and vm.dirty_background_ratio. I reckon that the book's recommendation to lower vm.dirty_background_ratio to 5 and vm.dirty_ratio to 10 is not enough for a server with such big amount of RAM. How much lower should I set these values, given that my RAID's WriteBack cache size is 512MB?</div><div><br /></div><div>Thank you very much.</div><div><br /></div><div>Kaixi Luo</div></div>
</blockquote></div>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Tuning guidelines for server with 256GB of RAM and SSDs?
2016-07-05 19:17 Re: Tuning guidelines for server with 256GB of RAM and SSDs? Mkrtchyan, Tigran <[email protected]>
@ 2016-07-07 04:59 ` Mark Kirkwood <[email protected]>
2016-07-07 07:49 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Kaixi Luo <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Mark Kirkwood @ 2016-07-07 04:59 UTC (permalink / raw)
To: pgsql-performance
On 06/07/16 07:17, Mkrtchyan, Tigran wrote:
> Hi,
>
> We had a similar situation and the best performance was with 64MB
> background_bytes and 512 MB dirty_bytes.
>
> Tigran.
>
> On Jul 5, 2016 16:51, Kaixi Luo <[email protected]> wrote:
>
>
> Here are my server specs:
>
> RAID1 - 2x480GB Samsung SSD with power loss protection (will be used to
> store the PostgreSQL database)
> RAID1 - 2x240GB Crucial SSD with power loss protection. (will be used to
> store PostgreSQL transactions logs)
>
Can you tell the exact model numbers for the Samsung and Crucial SSD's?
It typically matters! E.g I have some Crucial M550 that have capacitors
and (originally) claimed to be power off safe, but with testing have
been shown to be not really power off safe at all. I'd be dubious about
Samsungs too.
The Intel Datacenter range (S3700 and similar) are known to have power
off safety that does work.
regards
Mark
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Tuning guidelines for server with 256GB of RAM and SSDs?
2016-07-05 19:17 Re: Tuning guidelines for server with 256GB of RAM and SSDs? Mkrtchyan, Tigran <[email protected]>
2016-07-07 04:59 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Mark Kirkwood <[email protected]>
@ 2016-07-07 07:49 ` Kaixi Luo <[email protected]>
2016-07-07 14:09 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Wes Vaske (wvaske) <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Kaixi Luo @ 2016-07-07 07:49 UTC (permalink / raw)
To: Mark Kirkwood <[email protected]>; +Cc: pgsql-performance
It's a Crucial CT250MX200SSD1 and a Samsung MZ7LM480HCHP-00003.
Regards,
Kaixi
On Thu, Jul 7, 2016 at 6:59 AM, Mark Kirkwood <[email protected]
> wrote:
> On 06/07/16 07:17, Mkrtchyan, Tigran wrote:
>
>> Hi,
>>
>> We had a similar situation and the best performance was with 64MB
>> background_bytes and 512 MB dirty_bytes.
>>
>> Tigran.
>>
>> On Jul 5, 2016 16:51, Kaixi Luo <[email protected]> wrote:
>>
>>
>> Here are my server specs:
>>
>> RAID1 - 2x480GB Samsung SSD with power loss protection (will be used
>> to
>> store the PostgreSQL database)
>> RAID1 - 2x240GB Crucial SSD with power loss protection. (will be
>> used to
>> store PostgreSQL transactions logs)
>>
>>
> Can you tell the exact model numbers for the Samsung and Crucial SSD's? It
> typically matters! E.g I have some Crucial M550 that have capacitors and
> (originally) claimed to be power off safe, but with testing have been shown
> to be not really power off safe at all. I'd be dubious about Samsungs too.
>
> The Intel Datacenter range (S3700 and similar) are known to have power off
> safety that does work.
>
> regards
>
> Mark
>
>
>
> --
> Sent via pgsql-performance mailing list ([email protected])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Tuning guidelines for server with 256GB of RAM and SSDs?
2016-07-05 19:17 Re: Tuning guidelines for server with 256GB of RAM and SSDs? Mkrtchyan, Tigran <[email protected]>
2016-07-07 04:59 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Mark Kirkwood <[email protected]>
2016-07-07 07:49 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Kaixi Luo <[email protected]>
@ 2016-07-07 14:09 ` Wes Vaske (wvaske) <[email protected]>
2016-07-08 03:13 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Mark Kirkwood <[email protected]>
0 siblings, 1 reply; 12+ messages in thread
From: Wes Vaske (wvaske) @ 2016-07-07 14:09 UTC (permalink / raw)
To: Kaixi Luo <[email protected]>; Mark Kirkwood <[email protected]>; +Cc: pgsql-performance
?The Crucial drive does not have power loss protection. The Samsung drive does.
(The Crucial M550 has capacitors to protect data that's already been written to the device but not the entire cache. For instance, if data is read from the device during a garbage collection operation, the M550 will protect that data instead of introducing corruption of old data. This is listed as "power loss protection" on the spec sheet but it's not the level of protection that people on this list would expect from a drive)
________________________________
From: [email protected] <[email protected]> on behalf of Kaixi Luo <[email protected]>
Sent: Thursday, July 7, 2016 2:49 AM
To: Mark Kirkwood
Cc: [email protected]
Subject: Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?
It's a Crucial CT250MX200SSD1 and a Samsung MZ7LM480HCHP-00003.
Regards,
Kaixi
On Thu, Jul 7, 2016 at 6:59 AM, Mark Kirkwood <[email protected]<mailto:[email protected]>> wrote:
On 06/07/16 07:17, Mkrtchyan, Tigran wrote:
Hi,
We had a similar situation and the best performance was with 64MB
background_bytes and 512 MB dirty_bytes.
Tigran.
On Jul 5, 2016 16:51, Kaixi Luo <[email protected]<mailto:[email protected]>> wrote:
Here are my server specs:
RAID1 - 2x480GB Samsung SSD with power loss protection (will be used to
store the PostgreSQL database)
RAID1 - 2x240GB Crucial SSD with power loss protection. (will be used to
store PostgreSQL transactions logs)
Can you tell the exact model numbers for the Samsung and Crucial SSD's? It typically matters! E.g I have some Crucial M550 that have capacitors and (originally) claimed to be power off safe, but with testing have been shown to be not really power off safe at all. I'd be dubious about Samsungs too.
The Intel Datacenter range (S3700 and similar) are known to have power off safety that does work.
regards
Mark
--
Sent via pgsql-performance mailing list ([email protected]<mailto:[email protected]>)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: Tuning guidelines for server with 256GB of RAM and SSDs?
2016-07-05 19:17 Re: Tuning guidelines for server with 256GB of RAM and SSDs? Mkrtchyan, Tigran <[email protected]>
2016-07-07 04:59 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Mark Kirkwood <[email protected]>
2016-07-07 07:49 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Kaixi Luo <[email protected]>
2016-07-07 14:09 ` Re: Tuning guidelines for server with 256GB of RAM and SSDs? Wes Vaske (wvaske) <[email protected]>
@ 2016-07-08 03:13 ` Mark Kirkwood <[email protected]>
0 siblings, 0 replies; 12+ messages in thread
From: Mark Kirkwood @ 2016-07-08 03:13 UTC (permalink / raw)
To: pgsql-performance
On 08/07/16 02:09, Wes Vaske (wvaske) wrote:
> ?The Crucial drive does not have power loss protection. The Samsung drive does.
>
>
> (The Crucial M550 has capacitors to protect data that's already been written to the device but not the entire cache. For instance, if data is read from the device during a garbage collection operation, the M550 will protect that data instead of introducing corruption of old data. This is listed as "power loss protection" on the spec sheet but it's not the level of protection that people on this list would expect from a drive)
>
Yes - the MX200 board (see):
http://www.anandtech.com/show/9258/crucial-mx200-250gb-500gb-1tb-ssd-review
looks to have the same sort of capacitors that the M550 uses, so not
ideal for db or transaction logs!
Cheers
Mark
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2016-07-08 03:13 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2016-07-05 14:50 Tuning guidelines for server with 256GB of RAM and SSDs? Kaixi Luo <[email protected]>
2016-07-06 18:13 ` Merlin Moncure <[email protected]>
2016-07-06 21:48 ` Scott Marlowe <[email protected]>
2016-07-07 16:27 ` Merlin Moncure <[email protected]>
2016-07-07 17:00 ` Scott Marlowe <[email protected]>
2016-07-06 22:34 ` Wes Vaske (wvaske) <[email protected]>
2016-07-07 21:06 ` Kaixi Luo <[email protected]>
2016-07-05 19:17 Re: Tuning guidelines for server with 256GB of RAM and SSDs? Mkrtchyan, Tigran <[email protected]>
2016-07-07 04:59 ` Mark Kirkwood <[email protected]>
2016-07-07 07:49 ` Kaixi Luo <[email protected]>
2016-07-07 14:09 ` Wes Vaske (wvaske) <[email protected]>
2016-07-08 03:13 ` Mark Kirkwood <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox