[EMAIL PROTECTED] wrote:
for example if you have a process that uses 1G of ram (say firefox)
and it needs to start a new process (say acroread to handle a pdf
file), what it does is it forks the firefox process (each of which
have 1G of ram allocated), and then does an exec of the acroread
pro
On Aug 29, 2008, at 4:43 AM, Greg Smith wrote:
On Thu, 21 Aug 2008, Christiaan Willemsen wrote:
Anyway, I'm going to return the controller, because it does not
scale very well with more that 4 disks in raid 10. Bandwidth is
limited to 350MB/sec, and IOPS scale badly with extra disks...
H
On Thu, 28 Aug 2008, Bill Moran wrote:
In linux, it's possible to tell the OOM killer never to consider
certain processes for the axe, using /proc magic. See this page:
http://linux-mm.org/OOM_Killer
Perhaps this should be in the PostgreSQL docs somewhere?
The fact that
http://www.postgresq
On Tue, 26 Aug 2008, Scott Marlowe wrote:
If it is a checkpoint issue then you need more aggresive bgwriter
settings, and possibly more bandwidth on your storage array.
Since this is 8.3.1 the main useful thing to do is increase
checkpoint_segments and checkpoint_completion_target to spread t
On Sun, 24 Aug 2008, Tom Lane wrote:
Mind you, I don't think Apple sells any hardware that would be really
suitable for a big-ass database server.
If you have money to burn, you can get an XServe with up to 8 cores and
32GB of RAM, and get a card to connect it to a Fiber Channel disk array.
On Thu, 28 Aug 2008, Alvaro Herrera wrote:
[EMAIL PROTECTED] escribi?:
On Thu, 28 Aug 2008, Scott Marlowe wrote:
scenario 1: There's a postmaster, it owns all the child processes.
It gets killed. The Postmaster gets restarted. Since there isn't one
when the postmaster gets killed doesn'
[EMAIL PROTECTED] escribió:
> On Thu, 28 Aug 2008, Scott Marlowe wrote:
>> scenario 1: There's a postmaster, it owns all the child processes.
>> It gets killed. The Postmaster gets restarted. Since there isn't one
>
> when the postmaster gets killed doesn't that kill all it's children as
> we
On Thu, 21 Aug 2008, Christiaan Willemsen wrote:
Anyway, I'm going to return the controller, because it
does not scale very well with more that 4 disks in raid 10. Bandwidth is
limited to 350MB/sec, and IOPS scale badly with extra disks...
How did you determine that upper limit? Usually it t
On Thu, 28 Aug 2008, Scott Marlowe wrote:
On Thu, Aug 28, 2008 at 7:53 PM, Matthew Dennis <[EMAIL PROTECTED]> wrote:
On Thu, Aug 28, 2008 at 8:11 PM, Scott Marlowe <[EMAIL PROTECTED]>
wrote:
wait a min here, postgres is supposed to be able to survive a complete
box
failure without corrupting
Scott Marlowe escribió:
> scenario 1: There's a postmaster, it owns all the child processes.
> It gets killed. The Postmaster gets restarted. Since there isn't one
> running, it comes up.
Actually there's an additional step required at this point. There isn't
a postmaster running, but a new o
On Thu, 21 Aug 2008, Andr? Volpato wrote:
So, what is slowing down is the CPU (Intel(R) Pentium(R) Dual CPU E2160
@ 1.80GHz)..In practice, I have noticed that dual 1.8 is worse than
single 3.0. We have another server wich is a Pentium D 3.0 GHz, that
runs faster.
Pentium D models are all dua
I had a similar problem here:
http://archives.postgresql.org/pgsql-bugs/2008-07/msg00026.php
Is the nested loop performing a LEFT join with yours? It's a little
difficult to tell just from the query plan you showed.
A work around for mine was to use a full outer join and eliminate the extra
rows
On Thu, Aug 28, 2008 at 7:53 PM, Matthew Dennis <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 28, 2008 at 8:11 PM, Scott Marlowe <[EMAIL PROTECTED]>
> wrote:
>>
>> > wait a min here, postgres is supposed to be able to survive a complete
>> > box
>> > failure without corrupting the database, if killing a
On Thu, Aug 28, 2008 at 8:11 PM, Scott Marlowe <[EMAIL PROTECTED]>wrote:
> > wait a min here, postgres is supposed to be able to survive a complete
> box
> > failure without corrupting the database, if killing a process can corrupt
> > the database it sounds like a major problem.
>
> Yes it is a m
On Thu, Aug 28, 2008 at 7:16 PM, <[EMAIL PROTECTED]> wrote:
> the ACID guarantees that postgres is making are supposed to mean that even
> if the machine dies, the CPU goes up in smoke, etc, the transactions that
> are completed will not be corrupted.
And if any of those things happens, the machi
On Thu, 28 Aug 2008, Scott Marlowe wrote:
On Thu, Aug 28, 2008 at 5:08 PM, <[EMAIL PROTECTED]> wrote:
On Thu, 28 Aug 2008, Scott Marlowe wrote:
On Thu, Aug 28, 2008 at 2:29 PM, Matthew Wakeling <[EMAIL PROTECTED]>
wrote:
Another point is that from a business perspective, a database that ha
On Thu, Aug 28, 2008 at 5:08 PM, <[EMAIL PROTECTED]> wrote:
> On Thu, 28 Aug 2008, Scott Marlowe wrote:
>
>> On Thu, Aug 28, 2008 at 2:29 PM, Matthew Wakeling <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Another point is that from a business perspective, a database that has
>>> stopped responding is equal
On Aug 28, 2008, at 6:01 PM, David Rowley wrote:
I had a similar problem here:
http://archives.postgresql.org/pgsql-bugs/2008-07/msg00026.php
Is the nested loop performing a LEFT join with yours? It's a little
difficult to tell just from the query plan you showed.
A work around for mine was to
On Thu, 28 Aug 2008, Scott Marlowe wrote:
On Thu, Aug 28, 2008 at 2:29 PM, Matthew Wakeling <[EMAIL PROTECTED]> wrote:
Another point is that from a business perspective, a database that has
stopped responding is equally bad regardless of whether that is because the
OOM killer has appeared or b
Another suggestion is to partition the table by date ranges. If most of the
range queries occur on particular batches of time, this will make all
queries more efficient, and improve locality and efficiency of all indexes
on the table.
This is more work than simply a table CLUSTER, especially in m
I once also had a similar performance problem when looking for all matching
rows between two timestamps. In fact that's why I'm here today. The problem
was with MySQL. I had some tables of around 10 million rows and all my
searching was timestamp based. MySQL didn't do what I wanted. I found that
u
On Thu, Aug 28, 2008 at 2:29 PM, Matthew Wakeling <[EMAIL PROTECTED]> wrote:
> Another point is that from a business perspective, a database that has
> stopped responding is equally bad regardless of whether that is because the
> OOM killer has appeared or because the machine is thrashing. In both
On Thu, Aug 28, 2008 at 3:29 PM, cluster <[EMAIL PROTECTED]> wrote:
> Thanks for all your replies! They are enlightening. I have some additional
> questions:
>
> 1) Would you prefer
> a) 5.4k 2" SATA RAID10 on four disks or
> b) 10k 2" SAS RAID1 on two disks?
> (Remember the lots (!) of random
On Thu, Aug 28, 2008 at 2:04 PM, Fernando Hevia <[EMAIL PROTECTED]> wrote:
>
> I havent had any issues with software raid (mdadm) and hot-swaps. It keeps
> working in degraded mode and as soon as you replace the defective disk it
> can reconstruct the array on the fly. Performance will suffer while
Thanks for all your replies! They are enlightening. I have some
additional questions:
1) Would you prefer
a) 5.4k 2" SATA RAID10 on four disks or
b) 10k 2" SAS RAID1 on two disks?
(Remember the lots (!) of random reads)
2) Should I just make one large partition of my RAID? Does it matter
On 2008-08-28, at 21:31, Emi Lu wrote:
Good morning,
Tried to compare Table1 based on Table2
. update table1.col = false
if table1.pk_cols not in table2.pk_cols
For the following two ways, (2) always performs better than (1) right,
and I need your inputs.
On Thu, 28 Aug 2008, Craig James wrote:
If your processes do use the memory, then your performance goes into the
toilet, and you know it's time to buy more memory or a second server,
but in the mean time your server processes at least keep running while
you kill the rogue processes.
I'd argue
-Mensaje original-
De: [EMAIL PROTECTED]
* I think we will go for hardware-based RAID 1 with a good
battery-backed-up controller. I have read that software RAID
perform surprisingly good, but for a production site where
hotplug replacement of dead disks is required, is software
RAID s
On Thu, 28 Aug 2008, [EMAIL PROTECTED] wrote:
I just asked on the kernel mailing list and Alan Cox responded.
he is saying that you are correct, it only allocates against the total
available, it doesn't actually allocate ram.
That was remarkably graceful of you. Yes, operating systems have wo
> -Mensaje original-
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] En nombre de cluster
>
> I'm about to buy a combined web- and database server. When
> (if) the site gets sufficiently popular, we will split the
> database out to a separate server.
>
> Our budget is limited, s
On Thu, 28 Aug 2008, Jeff Davis wrote:
The problem for the postmaster is that the OOM killer counts the
children's total vmsize -- including *shared* memory -- against the
parent, which is such a bad idea I don't know where to start. If you
have shared_buffers set to 1GB and 25 connections, the p
On Thu, Aug 28, 2008 at 1:22 PM, cluster <[EMAIL PROTECTED]> wrote:
> I'm about to buy a combined web- and database server. When (if) the site
> gets sufficiently popular, we will split the database out to a separate
> server.
>
> Our budget is limited, so how should we prioritize?
Standard priori
Good morning,
Tried to compare Table1 based on Table2
. update table1.col = false
if table1.pk_cols not in table2.pk_cols
For the following two ways, (2) always performs better than (1) right,
and I need your inputs.
(
I'm about to buy a combined web- and database server. When (if) the site
gets sufficiently popular, we will split the database out to a separate
server.
Our budget is limited, so how should we prioritize?
* We think about buying some HP Proliant server with at least 4GB ram
and at least a duo
On Wed, 2008-08-27 at 23:23 -0700, [EMAIL PROTECTED] wrote:
> there are periodic flamefests on the kernel mailing list over the OOM
> killer, if you can propose a better algorithm for it to use than the
> current one that doesn't end up being just as bad for some other workload
> the kernel poli
On Thu, 28 Aug 2008, Craig James wrote:
Matthew Wakeling wrote:
On Thu, 28 Aug 2008, Steve Atkins wrote:
Probably the best solution is to just tell the kernel somehow to never
kill the postmaster.
Or configure adequate swap space?
Oh yes, that's very important. However, that gives the mach
On Thu, 28 Aug 2008, [EMAIL PROTECTED] wrote:
On Thu, 28 Aug 2008, Matthew Wakeling wrote:
On Wed, 27 Aug 2008, [EMAIL PROTECTED] wrote:
if memory overcommit is disabled, the kernel checks to see if you have an
extra 1G of ram available, if you do it allows the process to continue, if
you do
Matthew Wakeling wrote:
On Thu, 28 Aug 2008, Steve Atkins wrote:
Probably the best solution is to just tell the kernel somehow to
never kill the postmaster.
Or configure adequate swap space?
Oh yes, that's very important. However, that gives the machine the
opportunity to thrash.
No, that
On Thu, 2008-08-28 at 00:56 -0400, Tom Lane wrote:
> Actually, the problem with Linux' OOM killer is that it
> *disproportionately targets the PG postmaster*, on the basis not of
> memory that the postmaster is using but of memory its child processes
> are using. This was discussed in the PG archi
On Thu, 28 Aug 2008, Matthew Wakeling wrote:
On Wed, 27 Aug 2008, [EMAIL PROTECTED] wrote:
if memory overcommit is disabled, the kernel checks to see if you have an
extra 1G of ram available, if you do it allows the process to continue, if
you don't it tries to free memory (by throwing away ca
On Thu, 28 Aug 2008, Craig James wrote:
[EMAIL PROTECTED] wrote:
On Wed, 27 Aug 2008, Craig James wrote:
The OOM killer is a terrible idea for any serious database server. I
wrote a detailed technical paper on this almost 15 years ago when Silicon
Graphics had this same feature, and Oracle a
On Thu, 28 Aug 2008, Steve Atkins wrote:
Probably the best solution is to just tell the kernel somehow to never kill
the postmaster.
Or configure adequate swap space?
Oh yes, that's very important. However, that gives the machine the
opportunity to thrash.
Matthew
--
The early bird gets t
[EMAIL PROTECTED] wrote:
On Wed, 27 Aug 2008, Craig James wrote:
The OOM killer is a terrible idea for any serious database server. I
wrote a detailed technical paper on this almost 15 years ago when
Silicon Graphics had this same feature, and Oracle and other critical
server processes couldn
Another approach we used successfully for a similar problem -- (we had lots
of free high memory but were running out of low memory; oom killer wiped out
MQ a couple times and postmaster a couple times) -- was to change the
settings for how aggressively the virtual memory system protected low memory
On Aug 28, 2008, at 6:26 AM, Matthew Wakeling wrote:
On Wed, 27 Aug 2008, [EMAIL PROTECTED] wrote:
if memory overcommit is disabled, the kernel checks to see if you
have an extra 1G of ram available, if you do it allows the process
to continue, if you don't it tries to free memory (by throw
>>> Bill Moran <[EMAIL PROTECTED]> wrote:
> In response to Matthew Wakeling <[EMAIL PROTECTED]>:
>>
>> Probably the best solution is to just tell the kernel somehow to
never
>> kill the postmaster.
>
> This thread interested me enough to research this a bit.
>
> In linux, it's possible to tell
In response to Matthew Wakeling <[EMAIL PROTECTED]>:
>
> Probably the best solution is to just tell the kernel somehow to never
> kill the postmaster.
This thread interested me enough to research this a bit.
In linux, it's possible to tell the OOM killer never to consider
certain processes for
On Wed, 27 Aug 2008, [EMAIL PROTECTED] wrote:
if memory overcommit is disabled, the kernel checks to see if you have an
extra 1G of ram available, if you do it allows the process to continue, if
you don't it tries to free memory (by throwing away cache, swapping to disk,
etc), and if it can't f
On Wed, Aug 27, 2008 at 03:22:09PM -0700, [EMAIL PROTECTED] wrote:
>
> I disagree with you. I think goof Postgres operation is so highly dependant
> on caching as much data as possible that disabling overcommit (and throwing
> away a lot of memory that could be used for cache) is a solution that'
Rainer Mager wrote:
I'm looking for some help in speeding up searches. My table is pretty simple
(see below), but somewhat large, and continuously growing. Currently it has
about 50 million rows.
Regarding your use of LIKE:
(1)If you are able to specify the beginning character(s) of the
st
I'm looking for some help in speeding up searches. My table is pretty simple
(see below), but somewhat large, and continuously growing. Currently it has
about 50 million rows.
The table is (I know I have excessive indexes, I'm trying to get the
appropriate ones and drop the extras):
51 matches
Mail list logo
