> hm, in that case, wouldn't adding 48gb of physical memory have
> approximately the same effect? or is something else going on?
imho, adding 48gb would have no effects.
server already has 376GB memory and still has a lot of unused GB.
let me repeat, we added 80GB for files cache by decreasing b
On Mon, Jun 3, 2013 at 11:08 AM, Миша Тюрин wrote:
> Hi all hackers again!
> Since i had got this topic there many test was done by our team and many
> papers was seen. And then I noticed that os_page_replacement_algorithm with
> CLOCK and others features
>
> might * interfere / overlap * with/o
On 05/03/2013 07:09 AM, Andres Freund wrote:
> We've got that in 9.3 which is absolutely fabulous! But that's not
> related to doing DMA which you cannot (and should not!) do from
> userspace.
You can do zero-copy DMA directly into userspace buffers. It requires
root (or suitable capabilities that
On Fri, May 3, 2013 at 12:09 AM, Andres Freund wrote:
>> But that brings up an interesting question. How hard / feasible would it be
>> to add DIO functionality to PG itself?
>
> I don't think there is too much chance of that - but I also don't really
> see the point in trying to do it. We should
On 2013-05-02 16:13:42 -0500, Shaun Thomas wrote:
> On 05/02/2013 12:04 PM, Josh Berkus wrote:
> Yeah, this is why I want to go to Linux Plumbers this year. The
> Kernel.org engineers are increasingly doing things which makes Linux
> unsuitable for applications which depend on the filesystem.
Uh.
On 05/02/2013 12:04 PM, Josh Berkus wrote:
There is a good, but sad, reason for this: IBM and Oracle and their
partners are the largest employers of people hacking on core Linux
memory/IO functionality, and both of those companies use DirectIO
extensively in their products.
I never thought of
> That's kind of my point. :) That 14GB isn't allocated to cache, buffers,
> any process, or anything else. It's just... free. In the middle of the
> day, where 800 PG threads are pulling 7000TPS on average. Based on that
> scenario, I'd like to think it would cache pretty aggressively, but
> inst
On 05/01/2013 06:37 PM, Bruce Momjian wrote:
Sorry to be dense here, but what is the problem with that output?
That there is a lot of memory marked as "free"? Why would it mark
any memory free?
That's kind of my point. :) That 14GB isn't allocated to cache, buffers,
any process, or anything
On Wed, Apr 24, 2013 at 08:39:09AM -0500, Shaun Thomas wrote:
> On 04/24/2013 08:24 AM, Robert Haas wrote:
>
> >Are you referring to the fact that vm.zone_reclaim_mode = 1 is an
> >idiotic default?
>
> Well... it is. But even on systems where it's not the default or is
> explicitly disabled, ther
On 04/24/2013 09:39 PM, Shaun Thomas wrote:
> On 04/24/2013 08:24 AM, Robert Haas wrote:
>
>> Are you referring to the fact that vm.zone_reclaim_mode = 1 is an
>> idiotic default?
> Servers are getting shafted in a lot of cases, and it's actually
> starting to make me angry.
>
A significant part o
vm state
root@avi-sql09:~# /sbin/sysctl -a|grep vm
vm.overcommit_memory = 0
vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 0
vm.oom_dump_tasks = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.dirty_background_ratio = 10
vm.dirty_background_bytes = 0
vm.dirty_ratio = 20
vm.dirty_bytes = 0
vm.
typo
> if ( user cpu + io wait ) is ~140% then i have ~140GB free.
140% ===>> 1400%
if ~14 cores are busy then ~140GB is free
10GB per process
hmmm...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
thanks a lot for responses
1) just remind my case
Intel 32 core = 2*8 *2threads
Linux 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
PostgreSQL 9.2.2 on x86_64-unknown-linux-gnu, compiled by gcc-4.4.real (Debian
4.4.5-8) 4.4.5, 64-bit
shared_buffers 64GB / constant hit ra
On 2013-04-24 09:06:39 -0500, Shaun Thomas wrote:
> On 04/24/2013 08:49 AM, Andres Freund wrote:
>
> >Uh. Ranting can be rather healthy thing every now and then and it good
> >for the soul and such. But. Did you actually try reporting those issues?
>
> That's actually part of the problem. How do
On 04/24/2013 08:49 AM, Andres Freund wrote:
Uh. Ranting can be rather healthy thing every now and then and it good
for the soul and such. But. Did you actually try reporting those issues?
That's actually part of the problem. How do you report:
Throwing a lot of processes at a high-memory sys
On 2013-04-24 08:39:09 -0500, Shaun Thomas wrote:
> The memory pressure code in Linux is extremely fucked up. I can't find it
> right now, but the memory management algorithm makes some pretty ridiculous
> assumptions once you pass half memory usage, regarding what is in active and
> inactive cache
On 04/24/2013 08:24 AM, Robert Haas wrote:
Are you referring to the fact that vm.zone_reclaim_mode = 1 is an
idiotic default?
Well... it is. But even on systems where it's not the default or is
explicitly disabled, there's just something hideously wrong with NUMA in
general. Take a look at o
On Tue, Apr 23, 2013 at 10:50 AM, Shaun Thomas wrote:
> This is most likely a NUMA issue. There really seems to be some kind of
> horrible flaw in the Linux kernel when it comes to properly handling NUMA on
> large memory systems.
Are you referring to the fact that vm.zone_reclaim_mode = 1 is an
On 04/22/2013 05:12 PM, Merlin Moncure wrote:
free -g
total used free sharedbuffers cached
Mem: 378250128 0 0229
-/+ buffers/cache: 20357
This is most likely a NUMA issue. There really see
On Mon, Apr 22, 2013 at 11:22 AM, Миша Тюрин wrote:
> free -g
> total used free sharedbuffers cached
> Mem: 378250128 0 0229
> -/+ buffers/cache: 20357
>
> and
> ! disks usage 100% (free 128GB
On Mon, Apr 22, 2013 at 1:22 PM, Миша Тюрин wrote:
>
> My first message has been banned for too many latters.
>
>>
> Hi all
> There is something wrong and ugly.
>
> 1)
> Intel 32 core = 2*8 *2threads
>
> Linux avi-sql09 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64
> GNU/Linux
>
> Post
21 matches
Mail list logo
