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
> I take it then that the char time and the nurse time are not the same
> duration. Does the nurse time always have to be the same portion of
> the chair time (say, at the beginning?), or is their some more
> complicated definition of how the nurse time overlays on top the chair
> time during the
On Tue, Jun 30, 2009 at 8:30 AM, Hartman,
Matthew wrote:
> I have tried to wrap my brain around different approaches but I'm still
> stuck with this one so far. Your approach is interesting but the problem
> is more complicated than that. Let me break it down a bit more.
>
> The chemotherapy treatm
I have tried to wrap my brain around different approaches but I'm still
stuck with this one so far. Your approach is interesting but the problem
is more complicated than that. Let me break it down a bit more.
The chemotherapy treatment room is divided into groupings of chairs,
called pods. Pod 1 c
Greg,
Thanks for the mental prod! Yes, the original data is more closely sorted by
the timestamptz column, since they represent events coming into the collection
system in real time. As for the distribution of data values, it goes without
saying the timestamptz value is monotonically increas
On Jun 26, 9:30 pm, goofyheadedp...@gmail.com (Brian Troutwine) wrote:
> Hello, all.
>
> CREATE OR REPLACE FUNCTION item_data_insert(
> iasin TEXT, iauthor TEXT, ibinding TEXT, icurrency_code TEXT,
> iisbn TEXT, iheight INTEGER, iwidth INTEGER, ilength INTEGER,
> iweight INTEGER,
>
26 matches
Mail list logo
