Hei:
We have PostgreSQL 8.3 running on Debian Linux server. We built an applicantion
using PHP programming language and Postgres database. There are appoximatly 150
users using the software constantly. We had some performance degration before
and after some studies we figured out we will need
As for the question in the title, no, if the server starts, shared
buffers should not be the reason for a subsequent crash.
In debian, it is common that the maximum allowed shared memory setting
on your kernel will prevent a server from even starting, but I guess
that's not your problem (because i
Normally under heavy load, a machine could potential stall, even seem to hang,
but not crash.
And judging from your description of the situation your only change was in
shared memory (IPC shm) usage, right?
I would advise to immediately run all sorts of (offline/online) hardware tests
(especiall
Robert Haas wrote:
The server can and does measure hit rates for the PG buffer pool, but to my
knowledge there is no clear-cut way for PG to know whether read() is satisfied
from the OS cache or a drive cache or the platter.
Does the server know which IO it thinks is sequential, and which i
On Fri, Apr 29, 2011 at 1:13 AM, Qiang Wang wrote:
>
> We have 10GB memory and we tuned PostgreSQL as follow:
> - max_connection = 100
> - work_mem = 50MB
You do know that work_mem is PER SORT right? Not per connection or
per user or per database. If all 100 of those connections needs to do
a
On what relations are explicit joins added?
I don't know when to add explicit joins.--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Order-of-tables-tp4346077p4358465.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
--
Sent via pgsql-perform
Hi,
Had a recent conversation with a tech from this company called FUSION-IO.
They sell
io cards designed to replace conventional disks. The cards can be up to 3
TB in size and apparently
are installed in closer proximity to the CPU than the disks are. They claim
performance boosts several times
On 4/29/2011 10:24 AM, Mark Steben wrote:
Hi,
Had a recent conversation with a tech from this company called
FUSION-IO. They sell
io cards designed to replace conventional disks. The cards can be up
to 3 TB in size and apparently
are installed in closer proximity to the CPU than the disks are.
On 29/04/2011 16:24, Mark Steben wrote:
Hi,
Had a recent conversation with a tech from this company called FUSION-IO.
They sell
io cards designed to replace conventional disks. The cards can be up to 3
TB in size and apparently
are installed in closer proximity to the CPU than the disks are.
Fusion SSDs install on PCIe slots, so are limited by slot count. None, so far
as I recall, are bootable (although Fusion has been promising that for more
than a year). If you've a BCNF schema of moderate size, then any SSD as
primary store is a good option; Fusion's are just even faster. If y
On Apr 29, 2011, at 7:24 AM, Mark Steben wrote:
> Hi,
> Had a recent conversation with a tech from this company called FUSION-IO.
> They sell
> io cards designed to replace conventional disks. The cards can be up to 3
> TB in size and apparently
> are installed in closer proximity to the CPU
We use FusionIO products for PGSQL. They work in most linux distributions and
even have beta FreeBSD drivers for those of us who prefer that OS. They cost a
lot, perform really well, and FusionIO has great support for those of us who
prefer not to use Windows or OS X, something that many other
What messages did you get in the Postgresql logs?
What other parameters have changed?
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Qiang Wang
Sent: 29 April 2011 08:13
To: pgsql-performance@postgresql.org
Subject: {Spam} [PERFORM]
Can pgpoolAdmin utility handle(administer) more than one pgpool-II custer?
We have a need of setting up 3 independent postgres clusters. One cluster
handling cadastral maps, one handling raster maps and one handling vector
maps. Each of these clusters must have a load balancer - EG pgpool-II.
Inte
On 04/29/2011 04:54 PM, Ben Chobot wrote:
We have a bunch of their cards, purchased when we were still on 8.1 and
were having difficulty with vacuums. (Duh.) They helped out a bunch for
that. They're fast, no question about it. Each FusionIO device (they
have cards with multiple devices) can do ~
TMS RAMSAN is a DRAM device. TMS built DRAM SSDs going back decades, but have
recently gotten into flash SSDs as well. The DRAM parts are in an order of
magnitude more expensive than others' flash SSDs, gig by gig. Also, about as
fast as off cpu storage gets.
regards,
Robert
Original m
Howdy. We've got a query that takes less than a second unless we add a
"order by" to it, after which it takes 40 seconds. Here's the query:
select page_number, ps_id, ps_page_id from ps_page where ps_page_id in
(select ps_page_id from documents_ps_page where document_id in (select
document_i
James Mansion wrote:
Does the server know which IO it thinks is sequential, and which it
thinks is random? Could it not time the IOs (perhaps optionally) and
at least keep some sort of statistics of the actual observed times?
It makes some assumptions based on what the individual query nodes
Ben Chobot wrote:
Also, while I would say they seem reliable (they have a supercap and
succeeded every power-pull test we did) we just recently we've had
some issues which /appear/ to be fio driver-related that effectively
brought our server down. Fusion thinks its our kernel parameters, but
w
Wayne Conrad wrote:
> select page_number, ps_id, ps_page_id from ps_page where
> ps_page_id in (select ps_page_id from documents_ps_page where
> document_id in (select document_id from temp_doc_ids)) order by
> ps_page_id;
> [estimated rows=34398932; actual rows=5]
> We tried increasing (fro
On 04/29/2011 06:52 PM, gnuo...@rcn.com wrote:
TMS RAMSAN is a DRAM device. TMS built DRAM SSDs going back decades,
but have recently gotten into flash SSDs as well. The DRAM parts are
in an order of magnitude more expensive than others' flash SSDs, gig
by gig. Also, about as fast as off cpu s
Wayne Conrad wrote:
> -> Seq Scan on temp_doc_ids
> (cost=0.00..23.48 rows=1310 width=32)
> (actual time=0.005..0.005 rows=5 loops=1)
Also, make sure that you run ANALYZE against your temp table right
before running your query.
-Kevin
--
Sent via pgsql-performance m
On 4/29/2011 1:55 PM, Greg Smith wrote:
James Mansion wrote:
Does the server know which IO it thinks is sequential, and which it
thinks is random? Could it not time the IOs (perhaps optionally) and
at least keep some sort of statistics of the actual observed times?
It makes some assumptions ba
Greg Smith wrote:
There are also some severe query plan stability issues with this idea
beyond this. The idea that your plan might vary based on execution
latency, that the system load going up can make query plans alter with
it, is terrifying for a production server.
I thought I was clear t
"Kevin Grittner" writes:
> Also, make sure that you run ANALYZE against your temp table right
> before running your query.
Yeah. It's fairly hard to credit that temp_document_ids has any stats
given the way-off estimates for it. Keep in mind that autovacuum
can't help you on temp tables: since
James Mansion wrote:
I thought I was clear that it should present some stats to the DBA,
not that it would try to auto-tune?
You were. But people are bound to make decisions about how to retune
their database based on that information. The situation when doing
manual tuning isn't that much
On Fri, Apr 29, 2011 at 11:37 PM, Greg Smith wrote:
> Anyway, how to collect this data is a separate problem from what should be
> done with it in the optimizer. I don't actually care about the collection
> part very much; there are a bunch of approaches with various trade-offs.
> Deciding how t
On Apr 27, 2011, at 11:11 PM, Joseph Shraibman wrote:
> On 04/27/2011 04:32 PM, Robert Haas wrote:
>> In the first case, PostgreSQL evidently thinks that using the indexes
>> will be slower than just ignoring them. You could find out whether
>> it's right by trying it with enable_seqscan=off.
>
On Apr 29, 2011, at 10:25 AM, James Mansion
wrote:
> Robert Haas wrote:
>> The server can and does measure hit rates for the PG buffer pool, but to my
>> knowledge there is no clear-cut way for PG to know whether read() is
>> satisfied from the OS cache or a drive cache or the platter.
>>
>>
On Apr 27, 2011, at 11:01 PM, Claudio Freire wrote:
> The patch may be simple, the testing not so much. I know that.
>
> What tools do we have to do that testing? There are lots, and all
> imply a lot of work. Is that work worth the trouble? Because if it
> is... why not work?
>
> I would propos
> Can pgpoolAdmin utility handle(administer) more than one pgpool-II custer?
No. pgpoolAdmin only supports one pgpool-II server.
> We have a need of setting up 3 independent postgres clusters. One cluster
> handling cadastral maps, one handling raster maps and one handling vector
> maps. Each of
On 04/30/2011 12:24 AM, Hsien-Wen Chu wrote:
I'm little bit confuse why it is not safe. and my question is following.
for database application, we need to avoid double cache, PostgreSQL
shared_buffer will cache the data, so we do not want to file system to
cache the data right?. so the DIRECT I
32 matches
Mail list logo
