On Thu, Jun 5, 2014 at 8:47 AM, Tom Lane wrote:
> Vince Lasmarias writes:
>> For the past few days, we've been seeing unexpected high CPU spikes in our
>> system.
>
> Recent reports have suggested that disabling transparent huge page
> management in your kernel can help with this. If the excess
Vince Lasmarias writes:
> For the past few days, we've been seeing unexpected high CPU spikes in our
> system.
Recent reports have suggested that disabling transparent huge page
management in your kernel can help with this. If the excess CPU
load is mostly "system" time not "user" time then this
For the past few days, we've been seeing unexpected high CPU spikes in our
system. We observed the following:
- every single CPU spike was preceded by low 'free' memory even though
'cached' is quite high
- as soon as we shut down any of our applications which is occupying some
DB connections (e.g.
On Fri, Oct 9, 2009 at 3:11 AM, Shiva Raman wrote:
> Dear all
> with reference to the discussions and valuable suggestions i got from the
> list, the code has been reviewed and updated with explicit commit . There is
> a good improvement in performance .I am also planning to upgrade the
> datab
Dear all
with reference to the discussions and valuable suggestions i got from the
list, the code has been reviewed and updated with explicit commit . There is
a good improvement in performance .I am also planning to upgrade the
database from 8.1 to 8.3 /8.4 .
My current OS is SLES 10 SP3 def
Gerhard Wiesinger wrote:
Hello Craig,
Are you sure this is correct?
The test program (see below) with autocommit=0 counts up when an insert
is done in another session and there is no commit done.
I think with each new select a new implicit transaction is done when no
explicit "BEGIN" has be
Hello Craig,
Are you sure this is correct?
The test program (see below) with autocommit=0 counts up when an insert is
done in
another session and there is no commit done.
I think with each new select a new implicit transaction is done when no
explicit "BEGIN" has been established.
Can one
As suggested, i had changed the log_statement='ddl' and now it is logging
only
the ddl statements . thanks for the tip.
Can i delete the old log files in pg_log after backing up as zip archive ?
is it neccesary to keep those log files ?
Regards
Shiva Raman
>
> 2009/9/25 Grzegorz Jaśkiewicz
>
>
2009/9/25 Shiva Raman
> As suggested, i had changed the log_statement='ddl' and now it is logging
> only
> the ddl statements . thanks for the tip.
> Can i delete the old log files in pg_log after backing up as zip archive ?
> is it neccesary to keep those log files ?
>
they're yours, you can d
On Fri, Sep 25, 2009 at 9:06 AM, Shiva Raman wrote:
> Hi Gerhard
> I also found the pg_log has 73 G of data .
>
> clusternode2:/var/lib/pgsql/data # du -sh pg_log/
> 73G pg_log/
>
> Is it necessary to keep this Log files? Can i backup the logs and delete it
> from the original directory ? Is
Hi Gerhard
I also found the pg_log has 73 G of data .
clusternode2:/var/lib/pgsql/data # du -sh pg_log/
73G pg_log/
Is it necessary to keep this Log files? Can i backup the logs and delete it
from the original directory ? Is this logs files necessary in case any data
recovery to be done ?
I
Hi Gerhard
Thanks for the mail
On Thu, Sep 24, 2009 at 7:19 PM, Gerhard Wiesinger wrote:
> Hello Shiva,
>
> What I see from top (0.0%wa) you don't have any I/O problem but a major CPU
> problem. But this is contrast to iostat where up to 50% of iowait is there
> (sometimes).
>
> I think you ha
Dave Dutcher wrote:
You need a COMMIT for every BEGIN. If you just run a SELECT statement
without first beginning a transaction, then you should not end up with a
connection that is Idle in Transaction. If you are beginning a transaction,
doing a select, and then not committing, then yes that i
Dave Dutcher wrote:
>> From: Shiva Raman
>> Subject: Re: [PERFORM] High CPU load on Postgres Server during Peak
>>
> not explicitly committed.
>
>> We have started updating the code on this.
>>
>
> You need a COMMIT for every BEGIN. If
>From: Shiva Raman
>Subject: Re: [PERFORM] High CPU load on Postgres Server during Peak
times
>
>Andy Colson Wrote : ,
>>Eww. I think that's bad. A connection that has a transaction open will
cause lots of row versions,
>>which use up ram, and make it slo
Andy Colson wrote:
> Shiva Raman wrote:
>> Hi
>>
>> Today the load observed very high load . I am pasting the top.
>>
>> _*TOP *_
>> top - 12:45:23 up 79 days, 14:42, 1 user, load average: 45.84,
>> 33.13, 25.84
>> Tasks: 394 total, 48 running, 346 sleeping, 0 stopped, 0 zombie
>> Cpu(s): 49
Shiva Raman wrote:
Hi
Today the load observed very high load . I am pasting the top.
_*TOP *_
top - 12:45:23 up 79 days, 14:42, 1 user, load average: 45.84, 33.13,
25.84
Tasks: 394 total, 48 running, 346 sleeping, 0 stopped, 0 zombie
Cpu(s): 49.2%us, 0.8%sy, 0.0%ni, 0.0%id, 0.0%wa,
For 'idle in transaction' issues, you have to fix your code. I faced this
issue couple of months back. How good is your exception handling? Are you
rollingback/comitting your transactions while exceptions are thrown, during
the course of db operations?
Honestly I wouldn't go for these scripts w
Hi
Today the load observed very high load . I am pasting the top.
*TOP *
top - 12:45:23 up 79 days, 14:42, 1 user, load average: 45.84, 33.13,
25.84
Tasks: 394 total, 48 running, 346 sleeping, 0 stopped, 0 zombie
Cpu(s): 49.2%us, 0.8%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.1%si,
50.0%s
On Wed, Sep 23, 2009 at 12:25 PM, Shiva Raman wrote:
First let me say that upgrading to a later version is likely going to
help as much as anything else you're likely to pick up from this
discussion. Not that this discussion isn't worthwhile, it is.
> If you run a 'ps ax|grep post' do you see a
Fernando Hevia wrote:
User Access
Total Number of Users is 500
Maximum number of Concurrent users will be 500 during peak time
Off Peak time the maximum number of concurrent user will be
around 150 to 200.
>>> A connection pooler like pgpool or pgbouncer
>>>
>>> User Access
>>> Total Number of Users is 500
>>> Maximum number of Concurrent users will be 500 during peak time
>>> Off Peak time the maximum number of concurrent user will be
>>> around 150 to 200.
>>>
>>
>>A connection pooler like pgpool or pgbouncer would considerably reduce the
>>burde
Shiva Raman wrote:
/If you run a 'ps ax|grep post' do you see anything that says 'idle in
transaction'? (I hope that old of version will show it. my processes
show up as postgres not postmaster)/
Lots of requests shows as 'idle in transaction'.
Eww. I think that's bad. A connection that
Hi
Thanks for your mail.
*Some quick advice:*
*
*
*>*
*> clusternode2:~ # rpm -qa | grep postgres*
*> postgresql-devel-8.1.9-1.2*
*> postgresql-8.1.9-1.2*
*> postgresql-docs-8.1.9-1.2*
*> postgresql-server-8.1.9-1.2*
*> postgresql-libs-64bit-8.1.9-1.2*
*> postgresql-libs-8.1.9-1.2*
*> p
Hi
Thanks a lot for the reply.
*I see you are on a pretty old version of pg. Are you vacuuming regularly?*
Yes, Vaccuuming is done every day morning at 06 am
It is running perfectly fine.
*
*
*If you run a 'ps ax|grep post' do you see anything that says 'idle in
transaction'? (I hope t
> -Mensaje original-
> De: Shiva Raman
> Enviado el: Martes, 22 de Septiembre de 2009 10:55
> Para: pgsql-performance@postgresql.org
> Asunto: [PERFORM] High CPU load on Postgres Server during
> Peak times
>
> Dear all
>
> I am having a problem of
Andy Colson wrote:
Shiva Raman wrote:
Dear all
I am having a problem of high cpu loads in my postgres server during
peak time. Following are the
details of my setup (details as per the postgres wiki) .
*Following is the output of TOP command during offpeak time.*
top - 18:36:56 up 77 da
Shiva Raman wrote:
Dear all
I am having a problem of high cpu loads in my postgres server during
peak time. Following are the
details of my setup (details as per the postgres wiki) .
*Following is the output of TOP command during offpeak time.*
top - 18:36:56 up 77 days, 20:33, 1 user,
On Tue, Sep 22, 2009 at 9:54 AM, Shiva Raman wrote:
> Dear all
>
> I am having a problem of high cpu loads in my postgres server during peak
> time. Following are the
> details of my setup (details as per the postgres wiki) .
>
> * PostgreSQL version
> o Run "select pg_version();" in ps
Dear all
I am having a problem of high cpu loads in my postgres server during peak
time. Following are the
details of my setup (details as per the postgres wiki) .
** PostgreSQL version
o Run "select pg_version();" in psql or PgAdmin III and provide the
full, exact output.*
clusterno
Hi All,
I reply to me, we solved a CPU Load problem. We had an external batch
who used an expensive SQL view and took 99% of the CPU.
Thanks all for you help !
---
I started the HAPlatform open-source project is a part of Share'nGo
Pro
Hi, Markus,
Le mardi 19 septembre 2006 à 15:09 +0200, Markus Schaber a écrit :
> Hi, Jerome,
>
> Jérôme BENOIS wrote:
>
> >>> Now i Have 335 concurrent connections, i decreased work_mem parameter to
> >>> 32768 and disabled Hyper Threading in BIOS. But my CPU load is still
> >>> very important.
Hi, Jerome,
Jérôme BENOIS wrote:
>>> Now i Have 335 concurrent connections, i decreased work_mem parameter to
>>> 32768 and disabled Hyper Threading in BIOS. But my CPU load is still
>>> very important.
>> What are your settings for commit_siblings and commit_delay?
> It default :
>
> #commit_de
Markus,
Le mardi 19 septembre 2006 à 11:53 +0200, Markus Schaber a écrit :
> Hi, Jerome,
>
> Jérôme BENOIS wrote:
>
> > Now i Have 335 concurrent connections, i decreased work_mem parameter to
> > 32768 and disabled Hyper Threading in BIOS. But my CPU load is still
> > very important.
>
> What
Hi, Jerome,
Jérôme BENOIS wrote:
> Now i Have 335 concurrent connections, i decreased work_mem parameter to
> 32768 and disabled Hyper Threading in BIOS. But my CPU load is still
> very important.
What are your settings for commit_siblings and commit_delay?
> Tomorrow morning i plan to add 2Gig
On 9/18/06, Jérôme BENOIS <[EMAIL PROTECTED]> wrote:
Tomorrow morning i plan to add 2Go RAM in order to test difference with
my actual config.
I don't think more RAM will change anything if you don't swap at all.
You can try to set shared_buffers lower (try 32768 and 16384) but I
don't
Hi Markus,
Le vendredi 15 septembre 2006 à 11:43 +0200, Markus Schaber a écrit :
> Hi, Jérôme,
>
> Jérôme BENOIS wrote:
>
> > max_connections = 512
>
> Do you really have that much concurrent connections? Then you should
> think about getting a larger machine, probably.
>
> You will definitely
Hi Guillaume,
Now i disable Hyper Threading in BIOS, and "context switch storms"
disappeared. (when i look with command sar -t)
I decreased work_mem parameter to 32768. My CPU load is better. But it
is still too high, in example :
top - 16:27:05 up 9:13, 3 users, load average
Jérôme,
How many concurrent connections do you have?
Because You've got only 2GB of ram this is important! Postgres process
takes some bytes in memory =) .. I don't exactly how many,
but thinking if it is about 2Mb you'll get about 1Gb of ram used only by
postgres' processes (for 512 connections)
On 9/15/06, Markus Schaber <[EMAIL PROTECTED]> wrote:
For xeons, there were rumours about "context switch storms" which kill
performance.
It's not that much a problem in 8.1. There are a few corner cases when
you still have the problem but on a regular load you don't have it
anymore (validated
Hi, Jérôme,
Jérôme BENOIS wrote:
> max_connections = 512
Do you really have that much concurrent connections? Then you should
think about getting a larger machine, probably.
You will definitely want to play with commit_delay and commit_siblings
settings in that case, especially if you have writ
>Hyper threading. It's usually not recommended to enable it on
>PostgreSQL servers. On most servers, you can disable it directly in
>the BIOS.
Maybe for specific usage scenarios, but that's generally not been my experience
with relatively recent versions of PG. We ran some tests with pgbench, and
On 9/14/06, Jérôme BENOIS <[EMAIL PROTECTED]> wrote:
Yes i have a lot of users ;-)
So your work_mem is probably far too high (that's what I told you in
my first message) and you probably swap when you have too many users.
Remember that work_mem can be used several times per query (and it's
espe
Hi Guillaume,
Le jeudi 14 septembre 2006 à 23:22 +0200, Guillaume Smet a écrit :
> Jérôme,
>
> Perhaps it's a stupid question but are your queries slower than
> before? You didn't tell it.
No, it's not stupid question !
Yes queries speed but when the load average exceeds 40 all queries are slower
Hi Evgeny,
Le jeudi 14 septembre 2006 à 20:47 +0400, Evgeny Gridasov a écrit :
> Jérôme,
>
> How many concurrent connections do you have?
I have between 300 and 400 concurrent connections.
> Because You've got only 2GB of ram this is important! Postgres process
> takes some bytes in memory =) ..
Jérôme,
Perhaps it's a stupid question but are your queries slower than
before? You didn't tell it.
IMHO, it's not a problem to have a high load if you have a lot of
users and your queries are fast (and with 8.1, they should be far
faster than before).
To take a real example, we had a problem w
=?ISO-8859-1?Q?J=E9r=F4me?= BENOIS <[EMAIL PROTECTED]> writes:
> Le jeudi 14 septembre 2006 =C3=A0 10:56 -0500, Scott Marlowe a =C3=A9crit :
>> I'm gonna make a SWAG here and guess that maybe your 7.4 db was initdb'd
>> with a locale of C and the new one is initdb'd with a real locale, like
>> en_U
Hi Scott,
Le jeudi 14 septembre 2006 à 10:56 -0500, Scott Marlowe a écrit :
> On Thu, 2006-09-14 at 10:02, Dave Dutcher wrote:
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of
> > > Jérôme BENOIS
> > >
> > explain analyze select distin
On Thu, 2006-09-14 at 10:02, Dave Dutcher wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > Jérôme BENOIS
> >
> explain analyze select distinct
> > INTEGER_VALUE,DATE_VALUE,EI_ID,VALUE_TYPE,FLOAT_VALUE,ID,TEXT_
> > VALUE,CATEGORY_ID
Hi Dave,
Le jeudi 14 septembre 2006 à 10:02 -0500, Dave Dutcher a écrit :
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > Jérôme BENOIS
> >
> explain analyze select distinct
> > INTEGER_VALUE,DATE_VALUE,EI_ID,VALUE_TYPE,FLOAT_VALUE,ID,TE
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Jérôme BENOIS
>
explain analyze select distinct
> INTEGER_VALUE,DATE_VALUE,EI_ID,VALUE_TYPE,FLOAT_VALUE,ID,TEXT_
> VALUE,CATEGORY_ID,STRING_VALUE,CATEGORYATTR_ID,NAME from (((
> select distinct e
Hello,
Le jeudi 14 septembre 2006 à 09:21 -0500, Scott Marlowe a écrit :
> On Thu, 2006-09-14 at 09:17, Jérôme BENOIS wrote:
> > Hi Tom,
> >
> > Le jeudi 14 septembre 2006 à 10:13 -0400, Tom Lane a écrit :
> > > =?ISO-8859-1?Q?J=E9r=F4me?= BENOIS <[EMAIL PROTECTED]> writes:
> > > >I migrat
On 9/14/06, Jérôme BENOIS <[EMAIL PROTECTED]> wrote:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
15667 postgres 25 0 536m 222m 532m R 98.8 11.0 1:39.29 postmaster
19533 postgres 25 0 535m 169m 532m R 92.9 8.3 0:38.68 postmaster
16278 postgres 25 0 537m 28
On Thu, 2006-09-14 at 09:17, Jérôme BENOIS wrote:
> Hi Tom,
>
> Le jeudi 14 septembre 2006 à 10:13 -0400, Tom Lane a écrit :
> > =?ISO-8859-1?Q?J=E9r=F4me?= BENOIS <[EMAIL PROTECTED]> writes:
> > >I migrated Postgres server from 7.4.6 to 8.1.4, But my server is
> > > completely full, by moment
On Thu, 2006-09-14 at 09:00, Jérôme BENOIS wrote:
> Hi Guillaume,
>
> Le jeudi 14 septembre 2006 à 15:46 +0200, Guillaume Smet a écrit :
> > On 9/14/06, Jérôme BENOIS <[EMAIL PROTECTED]> wrote:
> > >I migrated Postgres server from 7.4.6 to 8.1.4, But my server is
> > > completely full, by mome
Hi Tom,
Le jeudi 14 septembre 2006 à 10:13 -0400, Tom Lane a écrit :
> =?ISO-8859-1?Q?J=E9r=F4me?= BENOIS <[EMAIL PROTECTED]> writes:
> >I migrated Postgres server from 7.4.6 to 8.1.4, But my server is
> > completely full, by moment load average > 40
>
> Did you remember to ANALYZE the whole
=?ISO-8859-1?Q?J=E9r=F4me?= BENOIS <[EMAIL PROTECTED]> writes:
>I migrated Postgres server from 7.4.6 to 8.1.4, But my server is
> completely full, by moment load average > 40
Did you remember to ANALYZE the whole database after reloading it?
pg_dump/reload won't by itself regenerate statistic
Hi All,
I migrated Postgres server from 7.4.6 to 8.1.4, But my server is
completely full, by moment load average > 40
All queries analyzed by EXPLAIN, all indexes are used .. IO is good ...
My configuration is correct ?
- default configuration and se + somes updates :
max_connectio
Hi Guillaume,
Le jeudi 14 septembre 2006 à 15:46 +0200, Guillaume Smet a écrit :
> On 9/14/06, Jérôme BENOIS <[EMAIL PROTECTED]> wrote:
> >I migrated Postgres server from 7.4.6 to 8.1.4, But my server is
> > completely full, by moment load average > 40
> > All queries analyzed by EXPLA
On 9/14/06, Jérôme BENOIS <[EMAIL PROTECTED]> wrote:
I migrated Postgres server from 7.4.6 to 8.1.4, But my server is
completely full, by moment load average > 40
All queries analyzed by EXPLAIN, all indexes are used .. IO is good ...
What is the bottleneck? Are you CPU bound? Do you
60 matches
Mail list logo
