Hello.
As it turned out to be iowait, I'd recommend to try to load at least
some hot relations into FS cache with dd on startup. With a lot of RAM
on FreeBSD I even sometimes use this for long queries that require a lot
of index scans.
This converts random IO into sequential IO that is much m
On 7/09/2011 2:31 AM, Anibal David Acosta wrote:
Hi everyone,
My question is, if I have a table with 500,000 rows, and a SELECT of
one row is returned in 10 milliseconds, if the table has 6,000,000 of
rows and everything is OK (statistics, vacuum etc)
can i suppose that elapsed time will be
If you are not doing so already, another approach to preventing the slam at
startup would be to implement some form of caching either in memcache or an
http accelerator such as varnish (https://www.varnish-cache.org/). Depending
on your application and the usage patterns, you might be able to fairl
Thanks!
De: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] En nombre de Craig James
Enviado el: martes, 06 de septiembre de 2011 03:18 p.m.
Para: pgsql-performance@postgresql.org
Asunto: Re: [PERFORM] how fast index works?
On 9/6/11 11:31 AM, Aniba
On September 6, 2011 12:35:35 PM Richard Shaw wrote:
> Thanks for the advice, It's one under consideration at the moment. What
> are your thoughts on increasing RAM and shared_buffers?
>
If it's running OK after the startup rush, and it seems to be, I would leave
them alone. More RAM is always
Thanks for the advice, It's one under consideration at the moment. What are
your thoughts on increasing RAM and shared_buffers?
On 6 Sep 2011, at 20:21, Alan Hodgson wrote:
> On September 6, 2011 12:11:10 PM Richard Shaw wrote:
>> 24 :)
>>
>> 4 x Intel Xeon-NehalemEX E7540-HexCore [2GHz]
>>
On September 6, 2011 12:11:10 PM Richard Shaw wrote:
> 24 :)
>
> 4 x Intel Xeon-NehalemEX E7540-HexCore [2GHz]
>
Nice box.
Still I/O-bound, though. SSDs would help a lot, I would think.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subsc
On 9/6/11 11:31 AM, Anibal David Acosta wrote:
Hi everyone,
My question is, if I have a table with 500,000 rows, and a SELECT of one row is
returned in 10 milliseconds, if the table has 6,000,000 of rows and everything
is OK (statistics, vacuum etc)
can i suppose that elapsed time will be ne
24 :)
4 x Intel Xeon-NehalemEX E7540-HexCore [2GHz]
On 6 Sep 2011, at 20:07, Alan Hodgson wrote:
> On September 5, 2011 03:36:09 PM you wrote:
>> After Restart
>>
>> procs ---memory-- ---swap-- -io --system--
>> -cpu-- r b swpd free buff cache si so
On September 5, 2011 03:36:09 PM you wrote:
> After Restart
>
> procs ---memory-- ---swap-- -io --system--
> -cpu-- r b swpd free buff cache si sobibo in
> cs us sy id wa st 2 34 2332 5819012 75632 258553680089
> 420
Hi everyone,
My question is, if I have a table with 500,000 rows, and a SELECT of one row
is returned in 10 milliseconds, if the table has 6,000,000 of rows and
everything is OK (statistics, vacuum etc)
can i suppose that elapsed time will be near to 10?
On 6 Září 2011, 10:55, Gerhard Wohlgenannt wrote:
>
>> That's why I love dstat, just do this
>>
>> $ dstat -C 0,1,2,3,4,5,6,7
>>
>> and you know all you need.
>
> dstat looks like a very nice tool, results below ..
> (now the system load seems a bit lower then before when generating
> results for v
That's a good thought, maybe the stats are old and you have bad
plans? It could also be major updates to the data too (as opposed to
growth).
we have made checks for number of dead tuples etc recently, but looks
ok. and as "everything" in the database seems to be very slow atm, I
guess th
That's why I love dstat, just do this
$ dstat -C 0,1,2,3,4,5,6,7
and you know all you need.
dstat looks like a very nice tool, results below ..
(now the system load seems a bit lower then before when generating
results for vmstat and iostat)
Good catch, thanks Scott.
Yes, good catch.
Sti
hi,
What does a "normal load" mean? Does that mean a time when the queries are
slow?
yes, we are have slow queries (according to postgresql.log) with such load
Are you sure the machine really has 48GB of RAM? Because from the vmstat
output it seems like there's just 32GB.
procs ---me
Thanks a lot to everybody for their helpful hints!!!
I am running all these benchmarks while the VMs are up .. with the
system under something like "typical" loads ..
The RAID is hardware based. On of my colleagues will check if there is
any hardware problem on the RAID (the disks) today, but
On Monday 05 Sep 2011 22:23:32 Scott Marlowe wrote:
> On Mon, Sep 5, 2011 at 11:24 AM, Andres Freund wrote:
> > On Monday, September 05, 2011 14:57:43 Richard Shaw wrote:
> >> Autovacuum has been disabled and set to run manually via cron during a
> >> quiet period and fsync has recently been turne
/
OS and Postgres on same mount point
On 6 Sep 2011, at 00:31, Scott Marlowe wrote:
> On Mon, Sep 5, 2011 at 4:36 PM, Richard Shaw wrote:
>> Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz
>> avgqu-sz await svctm %util
>> sda 1.00 143.00 523.50 108.0
On 09/06/2011 08:45 AM, Stefan Keller wrote:
Do you think my problem would now be solved with NVRAM PCI card?
That's a tough call. Part of the reason I'm doing the presentation is
because there are a lot of other high OLTP databases out there which
have (or will) reached critical mass where
Shaun,
2011/9/2 Shaun Thomas :
> Ironically, this is actually the topic of my presentation at Postgres Open.>
Do you think my problem would now be solved with NVRAM PCI card?
Stefan
-- Forwarded message --
From: Stefan Keller
Date: 2011/9/3
Subject: Re: [PERFORM] Summaries on S
On 6 Září 2011, 10:26, Gerhard Wohlgenannt wrote:
> Thanks a lot to everybody for their helpful hints!!!
>
> I am running all these benchmarks while the VMs are up .. with the
> system under something like "typical" loads ..
>
> The RAID is hardware based. On of my colleagues will check if there is
21 matches
Mail list logo
