Thanks,I am already have started doing that. i.e. running the dummy task to get
the tables loaded again and it worked fine today.
regardsAlex
> To: ainto...@hotmail.com
> CC: scott.marl...@gmail.com; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] PL/Perl Performance Problem
Alex - writes:
> Tom, Scott, Alvaro,thanks for the hints on this issue. It looks as if one of
> the EOD maintenance jobs which does a few extensive queries does push data
> out of memory leading to this behavior.
> Is there a way to permanently cash some tables into memory?
Not as such, and if
:10:36 -0700
> Subject: Re: [GENERAL] PL/Perl Performance Problems
> From: scott.marl...@gmail.com
> To: ainto...@hotmail.com
> CC: t...@sss.pgh.pa.us; pgsql-general@postgresql.org
>
> According to your original post, you do selects in step 1 and 2... Or
> is this a differe
inserts and no selects.
> > Alex
> >
> >> Date: Fri, 18 Dec 2009 23:45:07 -0700
> >> Subject: Re: [GENERAL] PL/Perl Performance Problems
> >> From: scott.marl...@gmail.com
> >> To: ainto...@hotmail.com
> >> CC: t...@sss.pgh.pa.us; pgsql-genera
wrote:
> On a 2nd thought... where does the cach come into play when i only do
> inserts and no selects.
> Alex
>
>> Date: Fri, 18 Dec 2009 23:45:07 -0700
>> Subject: Re: [GENERAL] PL/Perl Performance Problems
>> From: scott.marl...@gmail.com
>> To: ainto...@hot
On a 2nd thought... where does the cach come into play when i only do inserts
and no selects.
Alex
> Date: Fri, 18 Dec 2009 23:45:07 -0700
> Subject: Re: [GENERAL] PL/Perl Performance Problems
> From: scott.marl...@gmail.com
> To: ainto...@hotmail.com
> CC: t...@sss.pgh.pa.us
18 Dec 2009 23:45:07 -0700
> Subject: Re: [GENERAL] PL/Perl Performance Problems
> From: scott.marl...@gmail.com
> To: ainto...@hotmail.com
> CC: t...@sss.pgh.pa.us; pgsql-general@postgresql.org
>
> On Fri, Dec 18, 2009 at 11:37 PM, Alex - wrote:
> > Hmm...
> > how can
On Fri, Dec 18, 2009 at 11:37 PM, Alex - wrote:
> Hmm...
> how can that be. This is happening every day, so its not a one off or
> happens once in the morning then in the afternoon. There is also no other
> task running on the system, its dedicated to postgres.
> Could the Autovacuum cause problem
day but the keep silent till the day timestamp breaks ?
The think is that I have 4 servers setup in a similar way and all have exactly
the same problem.
> Date: Fri, 18 Dec 2009 23:00:16 -0700
> Subject: Re: [GENERAL] PL/Perl Performance Problems
> From: scott.marl...@gmail.com
&g
Note that you seem to have a lot more IO wait in the first run than in
the second, which means that the task is hitting the disks more in the
first run than in the second one. Once IO wait starts to climb,
performance starts to dive, generally.
--
Sent via pgsql-general mailing list (pgsql-gener
I run AutovacuumI run a Vaccum Full Analyze every SatI re-index the tables
every Sat
> Date: Fri, 18 Dec 2009 21:20:23 -0300
> From: alvhe...@commandprompt.com
> To: ainto...@hotmail.com
> CC: t...@sss.pgh.pa.us; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] PL/Perl Perfo
Alex - wrote:
>
> Tom, I am logging these stats now, but i am having a similar issue. both jobs
> in the morning and after noon insert about 400k records (200k each)
> In the morning that job takes 450secIn the afternoon only 150; No select,
> simple parsing a file and insert the records
> These
0 1238 6720 2611 352 15 1 75 10 0
> To: ainto...@hotmail.com
> CC: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] PL/Perl Performance Problems
> Date: Fri, 18 Dec 2009 15:36:15 -0500
> From: t...@sss.pgh.pa.us
>
> Alex - writes:
> > I actually looked
Thank, I will check that out.
> To: ainto...@hotmail.com
> CC: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] PL/Perl Performance Problems
> Date: Fri, 18 Dec 2009 15:36:15 -0500
> From: t...@sss.pgh.pa.us
>
> Alex - writes:
> > I actually looked at that to
Alex - writes:
> I actually looked at that too, but there is no swapping going on.
If you were only watching for swapping, that wouldn't catch what I'm
talking about. Replacing cached disk buffers with other disk data
doesn't count as swapping in any system I've used.
re
I actually looked at that too, but there is no swapping going on. The system
also has 16GB memory allocated to postgres and during the processing there is
not other process really active.
> To: ainto...@hotmail.com
> CC: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] PL/Perl Pe
Alex - writes:
> Now here is what I noticed.
> a) if I run it in the morning, processing starts very slow, but after a few
> thousand records it will speed up until I actually get about 100 records
> processed per millisecond.
> b) it sometime takes about 5-10k records till i really get up to sp
17 matches
Mail list logo
