Steve Singer ssinger at ca.afilias.info
Fri Nov 11 11:09:21 PST 2011
On 11-11-11 02:04 PM, Mike Wilson wrote:
>
> Mike Wilson
> Predicate Logic
> Cell: (310) 600-8777
> SkypeID: lycovian
>
>
>  From my postgresql.log:
> 2011-11-11 11:03:15.237 PST db1.lax.jib(55096):LOG:  duration: 133.011 ms  statement: fetch 500 from LOG;
> 2011-11-11 11:03:17.241 PST db1.lax.jib(55096):LOG:  duration: 134.842 ms  statement: fetch 500 from LOG;
> 2011-11-11 11:03:19.239 PST db1.lax.jib(55096):LOG:  duration: 133.919 ms  statement: fetch 500 from LOG;
> 2011-11-11 11:03:21.240 PST db1.lax.jib(55096):LOG:  duration: 133.194 ms  statement: fetch 500 from LOG;
> 2011-11-11 11:03:23.241 PST db1.lax.jib(55096):LOG:  duration: 134.288 ms  statement: fetch 500 from LOG;
> 2011-11-11 11:03:25.241 PST db1.lax.jib(55096):LOG:  duration: 133.226 ms  statement: fetch 500 from LOG;
>
> I'm only logging statements that take longer than 100ms to run.
>
> Here is my output from sl_log1/2:
> select (select count(*) from sl_log_1) sl_log_1, (select count(*) from sl_log_2) sl_log_2;
>   sl_log_1 | sl_log_2
> ----------+----------
>     119239 |    43685

The fetch is taking a long time because sl_log_1 is big.  (The reason it 
takes so long is actually a bug that was fixed in 2.1)  sl_log_1 being 
that big probably means that log switching isn't happening.

Do you have any nodes that are behind?  (query sl_status on all your nodes)
Do you have any old nodes that are still listed in sl_node that you 
aren't using anymore?
Do (did) you have a long running transaction in your system that is 
preventing the log switch from taking place?





>
>
> On Nov 11, 2011, at 5:07 AM, Steve Singer wrote:
>
>> On 11-11-09 01:19 PM, Mike Wilson wrote:
>>> Seeing "fetch 500 from LOG" almost continuously in my PG logs for a new Slony 2.0.7 install.  The previous version (2.0.3?) didn't show these messages in the PG log.  Researching the issue, historically, this message was usually accompanied by a performance issue.  This isn't the case with my databases though, they appear to be running just as well as ever and the lag between replicated nodes appears to be about the same as the previous version.
>>>
>>> I guess my question is what does this message mean in this version of Slony?  Is it an indication of sub-optimal slon parameters?
>>> slon -g 20 $SLON_CLUSTER "host=$HOSTNAME port=$PORT dbname=$DB user=$USER"
>>>
>>> And how can I get rid of it if it's not an issue?
>>>
>>> Mike
>>
>> What is causing the 'fetch 500' statements to show up in the server log? Are you only logging SQL that takes longer than x milliseconds? If so how long are your fetch 500 statements taking?  How many rows are in your sl_log_1 and sl_log_2?
>>
>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Slony1-general mailing list
>>> Slony1-general at lists.slony.info
>>> http://lists.slony.info/mailman/listinfo/slony1-general
>>
>



More information about the Slony1-general mailing list