On 10/06/2015 02:33 AM, FattahRozzaq wrote:
> @Merlin Moncure, I got the calculation using pg_tune. And I modified
> the shared_buffers=24GB and the effective_cache_size=64GB
I really need to get Greg to take down pg_tune. It's way out of date.
Probably, I should replace it.
--
Josh Berkus
Post
I have checked the transparent huge pages and zone reclaim mode and those are
already disabled.
As a trial and error method, I have reduced the shared buffer size from
8500MB to 3000MB.
The CPU i/o wait is icreased a little. But the periodical over load has not
occurred afterwards. (3 days passed
On Tue, Oct 6, 2015 at 10:10 AM, Scott Marlowe wrote:
> On Tue, Oct 6, 2015 at 3:33 AM, FattahRozzaq wrote:
>> @Merlin Moncure, I got the calculation using pg_tune. And I modified
>> the shared_buffers=24GB and the effective_cache_size=64GB
>>
>> @Igor Neyman,
>> Yes, I had performance problem wh
On Tue, Oct 6, 2015 at 3:33 AM, FattahRozzaq wrote:
> @Merlin Moncure, I got the calculation using pg_tune. And I modified
> the shared_buffers=24GB and the effective_cache_size=64GB
>
> @Igor Neyman,
> Yes, I had performance problem which sometimes the response time took
> 11ms, with the exactly
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Carlo
Sent: Monday, October 05, 2015 11:11 PM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] One long transaction or multiple short transactions?
We have a system which is constant
@Merlin Moncure, I got the calculation using pg_tune. And I modified
the shared_buffers=24GB and the effective_cache_size=64GB
@Igor Neyman,
Yes, I had performance problem which sometimes the response time took
11ms, with the exactly same query it took 100ms, and the response time
seems randomly f
