| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
| Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Time to up bgwriter_lru_maxpages? |
| Date: | 2016-11-29 04:22:33 |
| Message-ID: | CAB7nPqThotkQx4BnTm8XgivjktF8PdoGzZrXLu8cDy0GJ7e2+w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 29, 2016 at 6:20 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> On 11/28/16 11:53 AM, Joshua D. Drake wrote:
>>
>> On 11/28/2016 11:40 AM, Jim Nasby wrote:
>>>
>>> With current limits, the most bgwriter can do (with 8k pages) is 1000
>>> pages * 100 times/sec = 780MB/s. It's not hard to exceed that with
>>> modern hardware. Should we increase the limit on bgwriter_lru_maxpages?
>>
>>
>> Considering a single SSD can do 70% of that limit, I would say yes.
>
>
> Next question becomes... should there even be an upper limit?
Looking at the log history the current default dates of cfeca621, it
would be time to raise the bar a little bit more. Even an utterly high
value could make sense for testing.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2016-11-29 04:24:52 | Re: Re: BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled |
| Previous Message | Dilip Kumar | 2016-11-29 04:17:29 | Re: Proposal: scan key push down to heap [WIP] |