subject:"\[PERFORM\] Tuning"

Re: [PERFORM] Tuning one Recurcive CTE

2016-11-09 Thread Andreas Joseph Krogh

På onsdag 09. november 2016 kl. 15:30:20, skrev Henrik Ekenberg <
hen...@ekenberg.pw >:
Hi,

 I will need to anonymized before sending it.
 Do you know if there is any tuning documents related to CTE scans

You might want to read this:
http://blog.2ndquadrant.com/postgresql-ctes-are-optimization-fences/

https://robots.thoughtbot.com/advanced-postgres-performance-tips#common-table-expressions-and-subqueries

https://www.postgresql.org/message-id/CAPo4y_XUJR1sijvTySy9W%2BShpORwzbhSdEzE9pgtc1%3DcTkvpkw%40mail.gmail.com
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com

Re: [PERFORM] Tuning one Recurcive CTE

2016-11-09 Thread Henrik Ekenberg


Hi,

I will need to anonymized before sending it.
Do you know if there is any tuning documents related to CTE scans

//H


På onsdag 09. november 2016 kl. 14:05:55, skrev Henrik Ekenberg
:


Hi,

I try to tune one Recursive CTE.

Explain Plan can be found here
https://explain.depesz.com/s/yLVd

Anyone can give me direction to check?

//H.


   
  Rule number one; Always provide the query in question when asking for
help tuning it.
   
 --ANDREAS JOSEPH KROGH
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com
www.visena.com[1]
[1]

   




Links:
--
[1] https://www.visena.com

Re: [PERFORM] Tuning one Recurcive CTE

2016-11-09 Thread Andreas Joseph Krogh

På onsdag 09. november 2016 kl. 14:05:55, skrev Henrik Ekenberg <
hen...@ekenberg.pw >:
Hi,

 I try to tune one Recursive CTE.

 Explain Plan can be found here
 https://explain.depesz.com/s/yLVd

 Anyone can give me direction to check?

 //H.

 
Rule number one; Always provide the query in question when asking for help 
tuning it.
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com

[PERFORM] Tuning one Recurcive CTE

2016-11-09 Thread Henrik Ekenberg


Hi,

I try to tune one Recursive CTE.

Explain Plan can be found here
https://explain.depesz.com/s/yLVd

Anyone can give me direction to check?

//H.

Re: [PERFORM] Tuning Checkpoints

2016-10-31 Thread Tomas Vondra


On 10/31/2016 08:19 PM, Andre Henry wrote:

My PG 9.4.5 server runs on Amazon RDS some times of the day we have a
lot of checkpoints really close (less than 1 minute apart, see logs
below) and we are trying to tune the DB to minimize the impact of the
checkpoint or reduce the number of checkpoints.

Server Stats

· Instance Type db.r3.4xl

• 16 vCPUs 122GB of RAM

• PostgreSQL 9.4.5 on x86_64-unknown-linux-gnu, compiled by gcc
(GCC) 4.8.2 20140120 (Red Hat 4.8.2-16), 64-bit



Some PG Stats

• Shared Buffers = 31427608kB

• Checkpoint Segments = 64

• Checkpoint completion target = .9

• Rest of the configuration is below



Things we are doing

• We have a huge table where each row is over 1kB and its very
busy. We are splitting that into multiple tables especially the one json
field that making it large.



Questions

• Each checkpoint log writes out the following checkpoint
complete: wrote 166481 buffers (4.2%); 0 transaction log file(s) added,
0 removed, 64 recycled; write=32.441 s, sync=0.050 s, total=32.550 s;
sync files=274, longest=0.049 s, average=0.000 s



OK, each checkpoint has to write all dirty data from checkpoints. You 
have ~170k buffers worth of dirty data, i.e. ~1.3GB.



• What does buffers mean? How do I find out how much RAM that is
equivalent to?



Buffer holds 8kB of data, which is the "chunk" of data files.


• Based on my RDS stats I don't think IOPs will help, because I
don't see any flat lines on my write operations / second graph. Is this
a good assumption?



Not sure what you mean by this. Also, maybe you should talk to AWS if 
you're on RDS.



• What else can we tune to spread out checkpoints?



Based on the logs, your checkpoints are triggered by filling WAL. I see 
your checkpoints happen every 30 - 40 seconds, and you only have 64 
segments.


So to get checkpoints checkpoints triggered by timeout (which I assume 
is 5 minutes, because you have not mentioned checkpoint_timeout), you 
need to increase checkpoint_segments enough to hold 5 minutes worth of WAL.


That means 300/30 * 64, i.e. roughly 640 segments (it's likely an 
overestimate, due to full page writes, but well).


regards

--
Tomas Vondra  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

2016-07-07 Thread Mark Kirkwood


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 (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

2016-07-07 Thread Kaixi Luo

> 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

Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

2016-07-07 Thread Scott Marlowe

On Thu, Jul 7, 2016 at 10:27 AM, Merlin Moncure  wrote:
> On Wed, Jul 6, 2016 at 4:48 PM, Scott Marlowe  wrote:
>> On Wed, Jul 6, 2016 at 12:13 PM, Merlin Moncure  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 (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

2016-07-07 Thread Merlin Moncure

On Wed, Jul 6, 2016 at 4:48 PM, Scott Marlowe  wrote:
> On Wed, Jul 6, 2016 at 12:13 PM, Merlin Moncure  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 (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

2016-07-07 Thread Wes Vaske (wvaske)

?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: pgsql-performance-ow...@postgresql.org 
<pgsql-performance-ow...@postgresql.org> on behalf of Kaixi Luo 
<kaixi...@gmail.com>
Sent: Thursday, July 7, 2016 2:49 AM
To: Mark Kirkwood
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

It's a Crucial CT250MX200SSD1 and a Samsung MZ7LM480HCHP-3.

Regards,

Kaixi


On Thu, Jul 7, 2016 at 6:59 AM, Mark Kirkwood 
<mark.kirkw...@catalyst.net.nz<mailto:mark.kirkw...@catalyst.net.nz>> 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 <kaixi...@gmail.com<mailto:kaixi...@gmail.com>> 
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 
(pgsql-performance@postgresql.org<mailto:pgsql-performance@postgresql.org>)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

2016-07-07 Thread Kaixi Luo

It's a Crucial CT250MX200SSD1 and a Samsung MZ7LM480HCHP-3.

Regards,

Kaixi


On Thu, Jul 7, 2016 at 6:59 AM, Mark Kirkwood  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  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 (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

2016-07-06 Thread Mark Kirkwood


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  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 (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

2016-07-06 Thread Wes Vaske (wvaske)

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: pgsql-performance-ow...@postgresql.org 
<pgsql-performance-ow...@postgresql.org> on behalf of Merlin Moncure 
<mmonc...@gmail.com>
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 <kaixi...@gmail.com> 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%40mail.gmail.com

merlin

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

2016-07-06 Thread Scott Marlowe

On Wed, Jul 6, 2016 at 12:13 PM, Merlin Moncure  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 (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

2016-07-06 Thread Merlin Moncure

On Tue, Jul 5, 2016 at 9:50 AM, Kaixi Luo  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%40mail.gmail.com

merlin

-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

2016-07-05 Thread Mkrtchyan, Tigran

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 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 RAMBattery 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

1 2 3 >

1 - 100 of 235 matches

Mail list logo