Samuel Gendler writes:
> On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer
> wrote:
>> If you're not using a connection pool, start using one.
> I see this issue and subsequent advice cross this list awfully
> frequently. Is there in architectural reason why postgres itself
> cannot pool incoming co
On Thu, Jul 8, 2010 at 8:11 PM, Craig Ringer
wrote:
> If you're not using a connection pool, start using one.
>
> Do you really need 100 *active* working query threads at one time? Because
> if you do, you're going to need a scary-big disk subsystem and a lot of
> processors.
I see this issue and
On 9/07/2010 3:20 AM, Harpreet singh Wadhwa wrote:
Hi,
I want to fine tune my postgresql to increase number of connects it
can handle in a minutes time.
Decrease the response time per request etc.
The exact case will be to handle around 100 concurrent requests.
If you're not using a connectio
On 7/8/2010 3:18 PM, timothy.noo...@emc.com wrote:
How does the linux machine know that there is a BBU installed and to
change its behavior or change the behavior of Postgres? I am
experiencing performance issues, not with searching but more with IO.
It doesn't change its behavior at all. It'
On 7/8/10 2:18 PM, timothy.noo...@emc.com wrote:
How does the linux machine know that there is a BBU installed and to
change its behavior or change the behavior of Postgres? I am
experiencing performance issues, not with searching but more with IO.
It doesn't. It trusts the disk controller. L
Thursday, July 8, 2010, 11:02:50 PM you wrote:
> Here is what I got:
> # ./tw_cli /c0 show
If that's all you get, than there's no BBU installed, or not correctly
connected to the controller.
You could try 'tw_cli /c0/bbu show all' to be sure, but I doubt your output
will change-
--
Jochen Erw
How does the linux machine know that there is a BBU installed and to
change its behavior or change the behavior of Postgres? I am
experiencing performance issues, not with searching but more with IO.
-Original Message-
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-
On Thu, Jul 8, 2010 at 12:13 PM, Jochen Erwied <
joc...@pgsql-performance.erwied.eu> wrote:
> Thursday, July 8, 2010, 7:16:47 PM you wrote:
>
> > Thanks. The server is hosted, so it is a bit of a hassle to figure this
> > stuff out, but I am having someone check.
>
> If you have root access to th
On 7/8/10 12:47 PM, Ryan Wexler wrote:
On Thu, Jul 8, 2010 at 12:46 PM, Kevin Grittner
mailto:kevin.gritt...@wicourts.gov>> wrote:
Ryan Wexler mailto:r...@iridiumsuite.com>>
wrote:
> One thing I don't understand is why BBU will result in a huge
> performance gain. I thought
Harpreet singh Wadhwa wrote:
> I want to fine tune my postgresql to increase number of connects
> it can handle in a minutes time.
> Decrease the response time per request etc.
> The exact case will be to handle around 100 concurrent requests.
I have found that connection pooling is crucial.
Richard Yen wrote:
> When you say "bulk-loaded," I suppose that also includes loading
> the data via slony ADD NODE as well--correct?
I would think so. Anything which loads a lot of data in relatively
few database transactions would qualify; I would think slony would
do this, as it's generall
On Jul 8, 2010, at 12:50 PM, Kevin Grittner wrote:
> Richard Yen wrote:
>
>> there were moments where 129 WAL files were generated in one
>> minute. Is it plausible that this autovacuum could be responsible
>> for this?
>
> I don't remember seeing your autovacuum and vacuum config settings,
>
On Jul 8, 2010, at 12:50 PM, Tom Lane wrote:
> Richard Yen writes:
>> My concern is that--as in the original post--there were moments where 129
>> WAL files were generated in one minute. Is it plausible that this
>> autovacuum could be responsible for this?
>
> That's not a particularly surp
Ryan Wexler wrote:
> It still amazes me that it would account for a 5x change in IO.
If you were doing one INSERT per database transaction, for instance,
that would not be at all surprising. If you were doing one COPY in
of a million rows, it would be a bit more surprising.
Each COMMIT of a
On 7/8/2010 1:47 PM, Ryan Wexler wrote:
Thanks for the explanations that makes things clearer. It still
amazes me that it would account for a 5x change in IO.
The buffering allows decoupling of the write rate from the disk rotation
speed.
Disks don't spin that fast, at least not relative to t
Richard Yen writes:
> My concern is that--as in the original post--there were moments where 129 WAL
> files were generated in one minute. Is it plausible that this autovacuum
> could be responsible for this?
That's not a particularly surprising WAL creation rate for a busy
database. I wouldn'
Richard Yen wrote:
> there were moments where 129 WAL files were generated in one
> minute. Is it plausible that this autovacuum could be responsible
> for this?
I don't remember seeing your autovacuum and vacuum config settings,
or an answer to my question about whether there was a bulk load
On Thu, Jul 8, 2010 at 12:46 PM, Kevin Grittner wrote:
> Ryan Wexler wrote:
>
> > One thing I don't understand is why BBU will result in a huge
> > performance gain. I thought BBU was all about power failures?
>
> Well, it makes it safe for the controller to consider the write
> complete as soo
Ryan Wexler wrote:
> One thing I don't understand is why BBU will result in a huge
> performance gain. I thought BBU was all about power failures?
Well, it makes it safe for the controller to consider the write
complete as soon as it hits the RAM cache, rather than waiting for
persistence to
On Jul 8, 2010, at 12:37 PM, Ryan Wexler wrote:
> One thing I don't understand is why BBU will result in a huge performance
> gain. I thought BBU was all about power failures?
When you have a working BBU, the raid card can safely do write caching. Without
it, many raid cards are good about tur
On Thu, Jul 8, 2010 at 12:32 PM, Jochen Erwied <
joc...@pgsql-performance.erwied.eu> wrote:
> Thursday, July 8, 2010, 9:18:20 PM you wrote:
>
> > However, I just verified with the hosting company that BBU is off on the
> > raid controller. I am trying to find out my options, turn it on,
> differe
On Jul 8, 2010, at 12:27 PM, Tom Lane wrote:
>
> (Hmm ... but those complaints are logged at level WARNING, which as
> discussed elsewhere is really lower than LOG. Should we change them?)
Hmm, I did a grep on "WARNING" on my log, and the only thing that turns up are
the "WARNING: terminating
Thursday, July 8, 2010, 9:18:20 PM you wrote:
> However, I just verified with the hosting company that BBU is off on the
> raid controller. I am trying to find out my options, turn it on, different
> card, etc...
Turning it on requires the external BBU to be installed, so even if a 9650
has BBU
Ryan Wexler wrote:
> I just verified with the hosting company that BBU is off on the
> raid controller. I am trying to find out my options, turn it on,
> different card, etc...
In the "etc." category, make sure that when you get it turned on,
the cache is configured for "write back" mode, not
"Kevin Grittner" writes:
> You're not alone. At first I was assuming that it was because of
> archiving, but the OP says that's turned off. Unless it had been on
> and there wasn't a *restart* after changing the configuration,
Yeah, I was less than convinced by his eyeball report of that, too.
On Jul 8, 2010, at 12:04 PM, Kevin Grittner wrote:
> Robert Haas wrote:
>
>> I don't understand how you managed to fill up 37GB of disk with
>> WAL files. Every time you fill up checkpoint_segments * 16MB of
>> WAL files, you ought to get a checkpoint. When it's complete, WAL
>> segments comp
Hi,
I want to fine tune my postgresql to increase number of connects it
can handle in a minutes time.
Decrease the response time per request etc.
The exact case will be to handle around 100 concurrent requests.
Can any one please help me in this.
Any hardware suggestions are also welcomed.
Reg
On Thu, Jul 8, 2010 at 12:13 PM, Jochen Erwied <
joc...@pgsql-performance.erwied.eu> wrote:
> Thursday, July 8, 2010, 7:16:47 PM you wrote:
>
> > Thanks. The server is hosted, so it is a bit of a hassle to figure this
> > stuff out, but I am having someone check.
>
> If you have root access to th
Thursday, July 8, 2010, 7:16:47 PM you wrote:
> Thanks. The server is hosted, so it is a bit of a hassle to figure this
> stuff out, but I am having someone check.
If you have root access to the machine, you should try 'tw_cli /cx show',
where the x in /cx is the controller number. If not presen
Robert Haas wrote:
> I don't understand how you managed to fill up 37GB of disk with
> WAL files. Every time you fill up checkpoint_segments * 16MB of
> WAL files, you ought to get a checkpoint. When it's complete, WAL
> segments completely written before the start of the checkpoint
> should b
On Wed, Jul 7, 2010 at 3:32 PM, Richard Yen wrote:
> On Jul 6, 2010, at 8:25 PM, Scott Marlowe wrote:
>
>> Tell us what you can about your hardware setup.
>
> Sorry, I made the bad assumption that the hardware setup would be
> irrelevant--dunno why I thought that.
>
> My hardware setup is 2 Fusio
On Wed, Jul 7, 2010 at 10:39 AM, damien hostin wrote:
> Hello again,
>
> At last, I check the same query with the same data on my desktop computer.
> Just after loading the data, the queries were slow, I launch a vaccum
> analyse which collect good stats on the main table, the query became quick
>
-- Forwarded message --
From: Ryan Wexler
Date: Thu, Jul 8, 2010 at 10:12 AM
Subject: Re: [PERFORM] performance on new linux box
To: Craig James
On Thu, Jul 8, 2010 at 10:10 AM, Craig James wrote:
> On 7/8/10 9:31 AM, Ryan Wexler wrote:
>
>> Thanks a lot for all the comments.
On 7/8/10 9:31 AM, Ryan Wexler wrote:
Thanks a lot for all the comments. The fact that both my windows box
and the old linux box both show a massive performance improvement over
the new linux box seems to point to hardware to me. I am not sure how
to test the fsync issue, but i don't see how th
On Thu, Jul 08, 2010 at 09:31:32AM -0700, Ryan Wexler wrote:
> Thanks a lot for all the comments. The fact that both my windows box and
> the old linux box both show a massive performance improvement over the new
> linux box seems to point to hardware to me. I am not sure how to test the
> fsync
On Thu, 2010-07-08 at 09:31 -0700, Ryan Wexler wrote:
> The raid card the server has in it is:
> 3Ware 4 Port 9650SE-4LPML RAID Card
>
> Looking it up, it seems to indicate that it has BBU
No. It supports a BBU. It doesn't have one necessarily.
You need to go into your RAID BIOS. It will tell y
Thanks a lot for all the comments. The fact that both my windows box and
the old linux box both show a massive performance improvement over the new
linux box seems to point to hardware to me. I am not sure how to test the
fsync issue, but i don't see how that could be it.
The raid card the serve
Eliot Gable wrote:
> If you can post some of your queries, there are a lot of bright
> people on this discussion list that can probably help you solve
> your bottleneck
Sure, but the original post was because the brand new server class
machine was performing much worse than the single-drive de
On Thu, Jul 8, 2010 at 9:53 AM, Kevin Grittner
wrote:
> Eliot Gable
> >
> wrote:
>
> > For about $2k - $3k, you can get a server that will do upwards of
> > 300 MB/sec, assuming the bulk of that cost goes to a good
> > hardware-based RAID controller with a battery backed-up cache and
> > some goo
Eliot Gable wrote:
> For about $2k - $3k, you can get a server that will do upwards of
> 300 MB/sec, assuming the bulk of that cost goes to a good
> hardware-based RAID controller with a battery backed-up cache and
> some good 15k RPM SAS drives.
FWIW, I concur that the description so far sugg
On Wed, Jul 7, 2010 at 10:07 PM, Andy Colson wrote:
> On 07/07/2010 06:06 PM, Ryan Wexler wrote:
>
>> Postgresql was previously running on a single cpu linux machine with 2
>> gigs of memory and a single sata drive (v8.3). Basically a desktop with
>> linux on it. I experienced slow performance.
On the new system the bulk loads are extremely slower than on the
previous
machine and so are the more complex queries. The smaller transactional
queries seem comparable but i had expected an improvement. Performing a
db
import via psql -d databas -f dbfile illustrates this problem.
If
42 matches
Mail list logo
