Re: Possible Corrputed shared memory

From: James Sebastian <james(dot)sebastian(at)gmail(dot)com>
To: Wei Shan <weishan(dot)ang(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-novice(at)postgresql(dot)org
Subject: Re: Possible Corrputed shared memory
Date: 2015-08-04 11:53:47
Message-ID: CA+ehAmF7Kj0ikCmBjKTFQ=vGfB7Rgfbb=kxpo2uyyWXqgnK1ig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

Total database size is very small. But probably I will increase
it..Initially it had only default 32 MB shared_buffers, later allocated 6
times to 144 MB.
Thanks for the suggestion..

On 3 August 2015 at 12:47, Wei Shan <weishan(dot)ang(at)gmail(dot)com> wrote:

> Hi James,
>
> Your values seems too low. U allocate 2GB to an application server but
> only 144M for the DB server. Doesn't it look weird to you?
>
> Perhaps you should consider bumping it up to least 2GB.
>
> Cheers.
>
> On 2 August 2015 at 11:11, James Sebastian <james(dot)sebastian(at)gmail(dot)com>
> wrote:
>
>>
>>
>> >> [ scratches head... ] It should certainly not have taken very long to
>>> >> replay 10 WAL segments worth of data. I surmise that the problems
>>> >> you were having before the shutdown were worse than you thought, ie
>>> >> checkpoints were failing to complete, probably due to a persistent
>>> >> I/O error, so that there was a whole lot more than normal to replay
>>> >> after the last successful checkpoint. Is there any evidence of such
>>> >> distress in the postmaster log?
>>>
>>> > We had very slow application performance and many hanging threads as
>>> per
>>> > pgadmin -> server status
>>> > Also logs had the following which also indicating probably high I/O
>>> (as per
>>> > google search results)
>>>
>>> > 2015-07-30 10:10:21 IST WARNING: pgstat wait timeout
>>> > 2015-07-30 10:12:21 IST WARNING: pgstat wait timeout
>>>
>>> Well, those might mean problems with the stats collector subprocess, but
>>> that's pretty noncritical; it would certainly not have prevented
>>> checkpoints from completing. No other unexplained log entries?
>>>
>>>
>> None. I have default log configuration as given by Ubuntu as default.
>> Probably I would need to increase them to get some more detailed level. I
>> will do some reading on them.
>> As of now, logging_collector and other log related are commented out, so
>> whatever is default is functioning and logging to postgresql-9.1-main.log
>>
>> If you have some suggestions, please let me know.
>>
>> One area of concern, I am realising now which might have contributed to
>> this is below.
>>
>> I am using postgres as backend db of a java based application over
>> tomcat. JVM is allocated 2048 MB memory heap size from tomcat.
>> But shared_buffers in postgres was at the default of 32m. I increased
>> them to 144 M and increased shmmax to 320 M. This machine has 8 GB RAM and
>> used as Database and Tomcat/application server. I can allocate more
>> memory, but my application side colleagues like to know why we keep high
>> and how to figure out instead of blindly allocating a high memory.
>>
>> I am not even sure how to figure out what should be my buffers.
>> I now kept
>> effective_cache_size = 256MB
>> max_connections = 100
>> work_mem = 10MB
>> and all others are default provided by postgres 9.1 in Ubuntu 12.04
>>
>> Let me know any of them looks bad and worse.
>>
>> Regards
>> James
>>
>
>
>
> --
> Regards,
> Ang Wei Shan
>

In response to

Browse pgsql-novice by date

  From Date Subject
Next Message Patrik Karlsson 2015-08-18 09:33:02 What should I do after a power loss?
Previous Message Wei Shan 2015-08-03 07:17:07 Re: Possible Corrputed shared memory