whole server farm).
For profiling (pgfouine), we have a crontab that change the postgresql
logging configuration for just a few mn.
and log "all" on the "everything but postgresql" partition.
around 2000 query/seconds/servers, no problem.
--
Laurent Laborde
Sysadmin at JFG-Netw
On Fri, Mar 13, 2009 at 9:28 AM, sathiya psql wrote:
> for profiling, you can also use the epqa.
>
> http://epqa.sourceforge.net/
or PGSI : http://bucardo.org/pgsi/
But it require a syslog date format we don't use here. So i wasn't
able to test it :/
--
F4FQM
Kerunix F
Using 3ware, 8 SAS HDD, Octocore (2x4) Xeon and 32GB RAM, on a custom
2.6.18 kernel.
--
Laurent Laborde
http://www.over-blog.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
you can also play with this-tiny-shiny tool :
http://pgfoundry.org/projects/pgiosim/
It just works and heavily stress the disk with random read/write.
--
F4FQM
Kerunix Flan
Laurent Laborde
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your
to change this page size ?
thank you.
--
F4FQM
Kerunix Flan
Laurent Laborde
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
in OS filesystem cache and 1 in shm (shared_buffer)).
I'd love to understand what's happening here ! Thank you :)
--
F4FQM
Kerunix Flan
Laurent Laborde
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
is useful to avoid out of memory
> errors".
> But if a loaded server starts to swap a lot, it is as good as dead
> anyway...
Not really, but we have it.
I tried with swappinness set to 0 and ... it swaps !
I'm back to 4GB of shared_buffer :)
I'll try various setting, maybe 16GB,
s restart)
Are you sure about the 2000 connections ?
Why don't you use a pgbouncer or pgpool instead ?
--
F4FQM
Kerunix Flan
Laurent Laborde
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
stants in a config file, or in any good documentation.
--
F4FQM
Kerunix Flan
Laurent Laborde
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On Tue, Jun 23, 2009 at 10:52 AM, Laurent Laborde wrote:
> On Mon, Jun 22, 2009 at 12:06 AM, Scott Marlowe
> wrote:
>> On Sun, Jun 21, 2009 at 12:28 PM, Peter Alban wrote:
>>> Hi,
>>>
>>> Here is the query :
>>> duration: 2533.734 ms statement:
Hi !
We recently had a problem with wal archiving badly impacting the
performance of our postgresql master.
And i discovered "cstream", that can limite the bandwidth of pipe stream.
Here is our new archive command, FYI, that limit the IO bandwidth to 500KB/s :
archive_command = '/bin/cat %p | cst
On Tue, Nov 10, 2009 at 3:05 PM, Ivan Voras wrote:
> Laurent Laborde wrote:
>>
>> Hi !
>> We recently had a problem with wal archiving badly impacting the
>> performance of our postgresql master.
>
> Hmmm, do you want to say that copying 16 MB files over the netw
checkpoint log :
checkpoint starting: time
checkpoint complete: wrote 1972 buffers (0.8%); 0 transaction log
file(s) added, 0 removed, 13 recycled;
write=179.123 s, sync=26.284 s, total=205.451 s
with a 10mn timeout.
--
ker2x
--
Sent via pgsql-performance mailing list
On Tue, Nov 10, 2009 at 4:11 PM, Ivan Voras wrote:
> Laurent Laborde wrote:
>
> Ok, this explains it. It also means you are probably not getting much
> runtime performance benefits from the logging and should think about moving
> the logs to different drive(s), among other things
On Tue, Nov 10, 2009 at 4:48 PM, Kevin Grittner
wrote:
> Laurent Laborde wrote:
>
>> BTW, if you have any idea to improve IO performance, i'll happily
>> read it. We're 100% IO bound.
>
> At the risk of stating the obvious, you want to make sure you have
>
On Tue, Nov 10, 2009 at 5:35 PM, Greg Smith wrote:
> Laurent Laborde wrote:
>>
>> It is on a separate array which does everything but tablespace (on a
>> separate array) and indexspace (another separate array).
>>
>
> On Linux, the types of writes done to
Hi !
Here is my plan :
- rebuilding a spare with ext3, raid10, without lvm
- switch the slony master to this new node.
We'll see ...
Thx for all the info !!!
--
Ker2x
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www
On Thu, Nov 12, 2009 at 3:21 PM, Laurent Laborde wrote:
> Hi !
>
> Here is my plan :
> - rebuilding a spare with ext3, raid10, without lvm
> - switch the slony master to this new node.
Done 3 days ago : Problem solved ! It totally worked. \o/
--
ker2x
sysadmin & DBA @ http:
hummm Adding pgsql-perf :)
On Mon, Nov 30, 2009 at 5:54 PM, Laurent Laborde wrote:
> Friendly greetings !
> I use postgresql 8.3.6.
>
> here is a few info about the table i'm querying :
> -
> - select
On Wed, Dec 2, 2009 at 1:42 PM, Greg Stark wrote:
> On Wed, Dec 2, 2009 at 11:13 AM, Laurent Laborde wrote:
>>> QUERY PLAN
>>> --
On Wed, Dec 2, 2009 at 1:47 PM, Greg Stark wrote:
> On Wed, Dec 2, 2009 at 11:13 AM, Laurent Laborde wrote:
>>> QUERY PLAN
>>> -
&
On Wed, Dec 2, 2009 at 2:17 PM, Robert Haas wrote:
>
> I'm confused. I think you've only shown us two query plans, so it's
> hard to judge what's going on here in the two cases you haven't shown.
> Also, you haven't shown the EXPLAIN ANALYZE output, so it's a bit
> tricky to judge what is really
* without order by, limit 5 : 70ms
--
explain analyze SELECT *
FROM _article
WHERE (_article.bitfield && getbit(0))
LIMIT 5;
QUERY PLAN :
Limit (cost=0.00..20.03 rows=5 width=1109) (actual
time=70.190..70.265 rows=5 loops=1)
-> Index Scan using idx_article_
On Sat, Nov 28, 2009 at 6:57 PM, Richard Neill wrote:
> Greg Smith wrote:
>>
>> Richard Neill wrote:
>>>
>>> Or am I barking up the wrong tree entirely?
>>
>> If you haven't already tuned checkpoint behavior, it's more likely that's
>> causing a dropout than autovacuum. See the checkpoint_segment
2 kingston V+100 500GB
Soft RAID1 (md)
ioscheduler [noop]
ext3
Linux pro-cdn1 2.6.26-2-amd64 #1 SMP Tue Jan 25 05:59:43 UTC 2011
x86_64 GNU/Linux
FilesystemSize Used Avail Use% Mounted on
/dev/md4 452G 301G 128G 71% /home/ssd
Random 8KB read/write with 1% writ
Sorry, it's not 2x512GB in Raid1 but 4x256GB in raid10
--
Laurent "ker2x" Laborde
Sysadmin & DBA at http://www.over-blog.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On Tue, Apr 19, 2011 at 2:07 PM, Greg Smith wrote:
> On 04/19/2011 05:15 AM, Laurent Laborde wrote:
>>
>> 2 kingston V+100 500GB
4x250GB in Raid10 (see my 2nd post)
> Thanks for the performance report. The V+100 is based on a Toshiba T6UG1XBG
> controller, and it doesn
1 SSD Kingston V+100 250GB, no raid.
/home/pgiosim-0.5/pgiosim -w1 -a1 -v -b 100 /home/ssd/big1
Write Mode: 1%
Stallcheck at 1.00
Verbose
Unknown units of blocks
Arg: 1
Read 100 blocks
Added /home/ssd/big1
3.57%, 35720 read,365 written, 28567.73kB/sec 3570.97 iops
6.14%, 25684 r
On Tue, Apr 19, 2011 at 3:21 PM, Nicholson, Brad (Toronto, ON, CA)
wrote:
>> -Original Message-
>> From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-
>> ow...@postgresql.org] On Behalf Of Laurent Laborde
>> Sent: Tuesday, April 19, 2
On Wed, Apr 20, 2011 at 2:39 PM, Jeff wrote:
>
> The performance here looks like the old jmicron based ssds that had
> absolutely abysmal performance - the intel x25s do not suffer like this. The
> x25's however suffer from the power durability Greg has mentioned. (And
> they will eventually need
On Wed, Apr 20, 2011 at 5:40 PM, Shaun Thomas wrote:
> On 04/20/2011 09:01 AM, Laurent Laborde wrote:
>
>> A review of the V+100 on the excellent anandtech :
>> http://www.anandtech.com/show/4010/kingston-ssdnow-v-plus-100-review
>
> That's horrifying. 4.9MB/s random
31 matches
Mail list logo
