On Friday 04 March 2005 09:38, Dr.Christian Storm wrote:
> I walked in this morning and looked at the load on our master db and
> saw that between 4:30-6PM last night the average load went steadily up
> from 0.5 to 2.5.  Using top I see that the two FETCH queries from Slony
> are swallowing two of our four CPUs:
>
>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 19029 postgres  16   0  671m 600m 668m R 73.0  7.9 788:58.38 postgres:
> postgres tii 192.168.1.42 FETCH
> 19206 postgres  16   0  671m 600m 668m R 72.7  7.9 788:46.65 postgres:
> postgres tii 192.168.1.43 FETCH
>
> The %CPU vacillates  between 70-90%.
>
> A further inspection of the stat activity confirms this:
>
> tii=# select procpid, query_start, age(now(),query_start),
> current_query from pg_stat_activity where current_query not like
> '%IDLE%' order by query_start;
>   procpid |          query_start          |       age       |
> current_query
> ---------+-------------------------------+-----------------
> +----------------------
>     19029 | 2005-03-04 09:29:44.71891-08  | 00:00:06.708432 | fetch 100
> from LOG;
>     19206 | 2005-03-04 09:29:47.768228-08 | 00:00:03.659114 | fetch 100
> from LOG;
>
> The age ranges anywhere from 0 to 9 seconds.
>
> The load on the two slaves hasn't changed.

What's the row count in _clustername.sl_log1 and  _clustername.sl_event

>
> BTW There are no idle in transactions over 5 seconds old.  We saw
> similar behavior before due to some poorly configured clients causing
> long
> transactions.
>
> Any help or thoughts would be greatly appreciated!
>
> Cheers,
>
> Christian
>
> Christian Storm, Ph.D.
> CTO iParadigms, LLC
>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general