Scott Carey wrote:
* Change the linux 'readahead' block device parameter to at least 4MB (8192,
see blockdev --setra) -- I don't know if there is a FreeBSD equivalent.
I haven't tested them, but 3ware gives suggestions at
http://www.3ware.com/kb/Article.aspx?id=14852 for tuning their cards
David Rees wrote:
You need to find out what all those Postgres processes are doing. You
might try enabling update_process_title and then using ps to figure
out what each instance is using.
That's what the addition of "-c" to top I suggested does on Linux; it
shows the updated process titles w
For a card level RAID controller, I am a big fan of the LSI , which is
available in a PCIe riser form factor for blade / 1U servers, and comes with
0.5GB of battery backed cache. Full Linux support including mainline kernel
drivers and command line config tools. Was using these with SAS expande
On Apr 6, 2010, at 9:49 AM, Ireneusz Pluta wrote:
> Greg Smith pisze:
>>
>> The MegaRAID SAS 84* cards have worked extremely well for me in terms
>> of performance and features for all the systems I've seen them
>> installed in. I'd consider it a modest upgrade from that 3ware card,
>> speed
On Wed, Apr 7, 2010 at 10:50 PM, David Rees wrote:
> On Wed, Apr 7, 2010 at 7:06 PM, Craig James
> wrote:
>> On 4/7/10 5:47 PM, Robert Haas wrote:
>>> On Wed, Apr 7, 2010 at 6:56 PM, David Rees wrote:
> synchronous_commit = off
You are playing with fire here. You should never tur
On Wed, Apr 7, 2010 at 7:06 PM, Craig James wrote:
> On 4/7/10 5:47 PM, Robert Haas wrote:
>> On Wed, Apr 7, 2010 at 6:56 PM, David Rees wrote:
synchronous_commit = off
>>>
>>> You are playing with fire here. You should never turn this off unless
>>> you do not care if your data becomes irr
On 4/7/10 5:47 PM, Robert Haas wrote:
On Wed, Apr 7, 2010 at 6:56 PM, David Rees wrote:
max_fsm_pages = 1600
max_fsm_relations = 625000
synchronous_commit = off
You are playing with fire here. You should never turn this off unless
you do not care if your data becomes irrecoverably corrup
On Wed, Apr 7, 2010 at 6:56 PM, David Rees wrote:
>> max_fsm_pages = 1600
>> max_fsm_relations = 625000
>> synchronous_commit = off
>
> You are playing with fire here. You should never turn this off unless
> you do not care if your data becomes irrecoverably corrupted.
That is not correct.
Craig James writes:
> On 4/7/10 3:36 PM, Joshua D. Drake wrote:
>> To have your CPUs so flooded that they are the cause of an inability to
>> log in is pretty suspect.
> I thought so too, except that I can't login during the flood. If the CPUs
> were all doing iowaits, logging in should be easy
On Wed, Apr 7, 2010 at 3:57 PM, Craig James wrote:
> On 4/7/10 3:36 PM, Joshua D. Drake wrote:
>> My guess is that it is not CPU, it is IO and your CPU usage is all WAIT
>> on IO.
>>
>> To have your CPUs so flooded that they are the cause of an inability to
>> log in is pretty suspect.
>
> I thoug
...Can you
correlate the spikes with anything like that?
Not that I know of. Just regular web traffic. On the backup server
these events happen occasionally even when there is little or no web
traffic, and nobody logged in doing maintenance.
What, if anything, are you logging in the Postgr
On 4/7/10 2:59 PM, Tom Lane wrote:
Craig James writes:
Most of the time Postgres runs nicely, but two or three times a day we get a
huge spike in the CPU load that lasts just a short time -- it jumps to 10-20
CPU loads. Today it hit 100 CPU loads. Sometimes days go by with no spike
events.
On 4/7/10 3:36 PM, Joshua D. Drake wrote:
On Wed, 2010-04-07 at 14:45 -0700, Craig James wrote:
On 4/7/10 2:40 PM, Joshua D. Drake wrote:
On Wed, 2010-04-07 at 14:37 -0700, Craig James wrote:
Most of the time Postgres runs nicely, but two or three times a day we get a
huge spike in the CPU lo
On Wed, Apr 7, 2010 at 2:37 PM, Craig James wrote:
> Most of the time Postgres runs nicely, but two or three times a day we get a
> huge spike in the CPU load that lasts just a short time -- it jumps to 10-20
> CPU loads. Today it hit 100 CPU loads. Sometimes days go by with no spike
> events.
On Wed, 2010-04-07 at 14:45 -0700, Craig James wrote:
> On 4/7/10 2:40 PM, Joshua D. Drake wrote:
> > On Wed, 2010-04-07 at 14:37 -0700, Craig James wrote:
> >> Most of the time Postgres runs nicely, but two or three times a day we get
> >> a huge spike in the CPU load that lasts just a short time
Craig James writes:
> Most of the time Postgres runs nicely, but two or three times a day we get a
> huge spike in the CPU load that lasts just a short time -- it jumps to 10-20
> CPU loads. Today it hit 100 CPU loads. Sometimes days go by with no spike
> events. During these spikes, the sys
Craig James wrote:
I managed to capture one such event using top(1) with the "batch"
option as a background process. See output below
You should add "-c" to your batch top capture, then you'll be able to
see what the individual postmaster processes are actually doing when
things get stuck.
On 4/7/10 2:40 PM, Joshua D. Drake wrote:
On Wed, 2010-04-07 at 14:37 -0700, Craig James wrote:
Most of the time Postgres runs nicely, but two or three times a day we get a
huge spike in the CPU load that lasts just a short time -- it jumps to 10-20
CPU loads. Today it hit 100 CPU loads. Som
On Wed, 2010-04-07 at 14:37 -0700, Craig James wrote:
> Most of the time Postgres runs nicely, but two or three times a day we get a
> huge spike in the CPU load that lasts just a short time -- it jumps to 10-20
> CPU loads. Today it hit 100 CPU loads. Sometimes days go by with no spike
> even
Most of the time Postgres runs nicely, but two or three times a day we get a
huge spike in the CPU load that lasts just a short time -- it jumps to 10-20
CPU loads. Today it hit 100 CPU loads. Sometimes days go by with no spike
events. During these spikes, the system is completely unresponsi
On Tue, Apr 6, 2010 at 5:37 PM, Samuel Gendler
wrote:
> In part, I'm surprised that the index scan takes as long as it does,
> since I'd think an index would be able to return the set of keys
> relatively quickly. But that's a secondary issue.
We don't actually have a facility built into the ind
On Tue, Apr 6, 2010 at 10:32 PM, Craig Ringer
wrote:
> On 7/04/2010 12:24 AM, Brian Cox wrote:
>>
>> On 04/06/2010 01:18 AM, Craig Ringer [cr...@postnewspapers.com.au] wrote:
>>>
>>> I'm wondering if the issue is with strace rather than Pg. That is to
>>> say, that strace is trying to print:
>>
>>
On Wed, 7 Apr 2010, sherry.ctr@faa.gov wrote:
Please just let me know if Postgres can do this kind of index or not.
create index idx1 on tb1(col1, col2)
Then later we can find it is useful or useless.
Have you tried it?
Grzegorz Jaśkiewicz wrote:
something like this: create index id
Please just let me know if Postgres can do this kind of index or not.
create index idx1 on tb1(col1, col2)
Then later we can find it is useful or useless.
Thanks much!
Xuefeng Zhu (Sherry)
Crown Consulting Inc. -- Oracle DBA
AIM Lab Data Team
(703) 925-3192
Grzegorz Jaśkiewicz
Sent by
2010/4/7
>
> Do you mean one index on two columns?
>
> something like this: create index idx1 on tb1(col1, col2);
>
yup :) It would be quite useless without that feature.
Don't listen to oracle folks, they obviously know not much about products
others than oracle db(s).
--
GJ
Do you mean one index on two columns?
something like this: create index idx1 on tb1(col1, col2);
Thanks much!
Xuefeng Zhu (Sherry)
Crown Consulting Inc. -- Oracle DBA
AIM Lab Data Team
(703) 925-3192
Grzegorz Jaśkiewicz
04/07/2010 08:51 AM
To
Sherry CTR Zhu/AWA/CNTR/f...@faa
cc
Joel Ja
On Wed, Apr 7, 2010 at 1:20 PM, wrote:
>
> Guys,
>
> Thanks for trying and opening your mind.
> If you want to know how Oracle addressed this issue, here it is: index
> on two columns. I remember that they told me in the training postgres has
> no this kind of index, can someone clarify?
>
Guys,
Thanks for trying and opening your mind.
If you want to know how Oracle addressed this issue, here it is: index
on two columns. I remember that they told me in the training postgres has
no this kind of index, can someone clarify?
Thanks much!
Xuefeng Zhu (Sherry)
Crown Consulting
Scott Marlowe wrote:
2010/3/31 Ľubomír Varga :
Hi, stright to my "problem":
If I try to select constant 1 from table with two rows, it will be something
like this:
explain
SELECT * FROM t_route
WHERE t_route.route_type_fk = (SELECT id FROM t_route_type WHERE type =
2)
limit 4;
29 matches
Mail list logo
