Scott Carey wrote:
the OS can either quickly allocate to the process or
the page cache from the free buffers, or more slowly take from the page
cache, or even more slowly page out a process page.
Aha, now it all makes sense.
I like to use the '5 second rule'. dirty_background_ratio should
On 6/30/09 2:39 PM, "Mike Ivanov" wrote:
> Scott Carey wrote:
>>> 222 / 8 cores = ridiculous 27 processes per core, while the OP has 239
>> That's not rediculous at all. Modern OS's handle thousands of idle
>> processes just fine.
>>
>>
> I meant that 27 was a ridiculously small number.
>
>
Scott Carey wrote:
222 / 8 cores = ridiculous 27 processes per core, while the OP has 239
That's not rediculous at all. Modern OS's handle thousands of idle
processes just fine.
I meant that 27 was a ridiculously small number.
Or you can control the behavior with the following kenrnel pa
On 6/30/09 1:08 PM, "Scott Carey" wrote:
>
> A larger shared_buffers size can help if sequential scans are infrequent and
> kick out pages from the OS page cache.
> Postgres does not let sequential scans kick out index pages or pages
> accessed randomly from its buffer cache, but the OS (Linux
On 6/30/09 12:06 PM, "Jean-David Beyer" wrote:
> Alan Hodgson wrote:
>> On Tuesday 30 June 2009, Mike Ivanov wrote:
>>> Hi Scott,
>>>
Well, we can't be sure OP's only got one core.
>>> In fact, we can, Sean posted what top -b -n 1 says. There was only one
>>> CPU line.
>>>
>>
>> Recent
Well, this is going to be a bit redundant but:
On 6/30/09 11:22 AM, "Mike Ivanov" wrote:
> Hi Scott,
>
>> Well, we can't be sure OP's only got one core.
>
> In fact, we can, Sean posted what top -b -n 1 says. There was only one
> CPU line.
I do not believe that setting means what you think i
Scott Marlowe wrote:
Close, but it'll use that memory for cache. Large buffers are not
typical in linux, large kernel caches are.
OK, we're talking about different things. You're right.
If that tutorial says that, then that tutorial is wrong. I'm guessing
what that tutorial is talking abou
Alan Hodgson wrote:
On Tuesday 30 June 2009, Mike Ivanov wrote:
Hi Scott,
Well, we can't be sure OP's only got one core.
In fact, we can, Sean posted what top -b -n 1 says. There was only one
CPU line.
Recent versions of top on Linux (on RedHat 5 anyway) may show only one
combined CPU li
Scott Marlowe wrote:
Also think about it, the OP has 8G of swap and 30Gig cached. How /
why would you be caching 30Gigs worth of data when there's only 8G to
cache anyway?
You're right, I have misread it again :-)
Cheers,
Mike
--
Sent via pgsql-performance mailing list (pgsql-performan
On Tuesday 30 June 2009, Mike Ivanov wrote:
> Hi Scott,
>
> > Well, we can't be sure OP's only got one core.
>
> In fact, we can, Sean posted what top -b -n 1 says. There was only one
> CPU line.
>
Recent versions of top on Linux (on RedHat 5 anyway) may show only one
combined CPU line unless yo
On Tue, Jun 30, 2009 at 12:22 PM, Mike Ivanov wrote:
>> > 3G of cached swap
>> and it's not swap that's cached, it's
>> the kernel using extra memory to cache data to / from the hard drives.
>>
>
> Oh please.. it *is*:
> http://www.linux-tutorial.info/modules.php?name=MContent&pageid=314
Also thin
On Tue, Jun 30, 2009 at 12:22 PM, Mike Ivanov wrote:
> Hi Scott,
>
>> Well, we can't be sure OP's only got one core.
>
> In fact, we can, Sean posted what top -b -n 1 says. There was only one CPU
> line.
Missed that.
>
>> the number of cores, it's the IO subsystem is too slow for the load.
>> Mor
Hi Scott,
Well, we can't be sure OP's only got one core.
In fact, we can, Sean posted what top -b -n 1 says. There was only one
CPU line.
the number of cores, it's the IO subsystem is too slow for the load.
More cores wouldn't fix that.
While I agree on the IO, more cores would defin
On Tue, Jun 30, 2009 at 12:01 PM, Mike Ivanov wrote:
> Scott Marlowe wrote:
>>>
>>> The postgres shared cache is at 4G, is that too big?
>>>
>>
>> Not for a machine with 32Gig of ram.
>>
>>
>
> He could even add some more.
Definitely. Really depends on how big his data set is, and how well
pgsql
Scott Marlowe wrote:
The postgres shared cache is at 4G, is that too big?
Not for a machine with 32Gig of ram.
He could even add some more.
Mike
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgres
Sean,
Yes, besides another mysql server running on
the same server,
Which is a really bad idea :-)
The postgres shared cache is at 4G, is that too big?
OK, I have misread the total memory amount which was 32G, and I thought
it was 3G. Thanks to Scott Marlow who pointed that out. In this
On Tue, Jun 30, 2009 at 11:49 AM, Sean Ma wrote:
> Hi Mike,
>
> Thanks for the details. Yes, besides another mysql server running on
> the same server, there is also an homegrown application that frequent
> read/write the file system.
>
> The postgres shared cache is at 4G, is that too big?
Not fo
Hi Mike,
Thanks for the details. Yes, besides another mysql server running on
the same server, there is also an homegrown application that frequent
read/write the file system.
The postgres shared cache is at 4G, is that too big?
Thanks
Sean
On Tue, Jun 30, 2009 at 1:23 PM, Mike Ivanov wrote:
>
On Tue, Jun 30, 2009 at 11:23 AM, Mike Ivanov wrote:
> Hi Sean,
>
> Well, the overall impression is your machine is badly overloaded. Look:
>
>> top - 10:18:58 up 224 days, 15:10, 2 users, load average: 6.27, 7.33, 6
>>
>
> The load average of 6.5 means there are six and a half processes competin
Hi Sean,
Well, the overall impression is your machine is badly overloaded. Look:
top - 10:18:58 up 224 days, 15:10, 2 users, load average: 6.27, 7.33, 6
The load average of 6.5 means there are six and a half processes
competing for the same CPU (and this system apparently has only one).
top - 10:18:58 up 224 days, 15:10, 2 users, load average: 6.27, 7.33, 6
Tasks: 239 total, 1 running, 238 sleeping, 0 stopped, 0 zombie
Cpu(s): 5.0%us, 0.7%sy, 0.0%ni, 61.5%id, 32.7%wa, 0.0%hi, 0.1%si, 0
Mem: 32962804k total, 32802612k used, 160192k free, 325360k buffers
Swap: 81
Hi Sean,
Sean Ma wrote:
One months ago, this type of slow query happened about a few time per
day. But recently, the slow query happens more frequent at the rate of
once every 10 minutes or less. There seesm not relation to th
What is your hardware (memory, CPU type and such)?
This seems like
Sean Ma wrote:
> I have a table about 50 million rows. There are a few writers to
> pump data into the table at the rate of 4 row/hours. Most the
> time, the SELECT is less than 100 ms. However sometime it is very
> slow, from 30 seconds to 500 seconds. The database is vacuum analyze
> regula
On 06/29/2009 03:33 PM, Sean Ma wrote:
I have a table about 50 million rows. There are a few writers to pump
data into the table at the rate of 4 row/hours. Most the time, the
SELECT is less than 100 ms. However sometime it is very slow, from 30
seconds to 500 seconds. The database is vacuum
I have a table about 50 million rows. There are a few writers to pump
data into the table at the rate of 4 row/hours. Most the time, the
SELECT is less than 100 ms. However sometime it is very slow, from 30
seconds to 500 seconds. The database is vacuum analyze regularly.
One months ago, this
25 matches
Mail list logo
