Re: [HACKERS] Re: [HACKERS] high io BUT huge amount of free memory

2013-06-03 Thread Merlin Moncure
On Mon, Jun 3, 2013 at 11:08 AM, Миша Тюрин tmih...@bk.ru 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

[HACKERS] Re[2]: [HACKERS] Re: [HACKERS] high io BUT huge amount of free memory

2013-06-03 Thread Миша Тюрин
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

Re: [HACKERS] high io BUT huge amount of free memory

2013-05-27 Thread Craig Ringer
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

Re: [HACKERS] high io BUT huge amount of free memory

2013-05-03 Thread Greg Stark
On Fri, May 3, 2013 at 12:09 AM, Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] high io BUT huge amount of free memory

2013-05-02 Thread Shaun Thomas
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

Re: [HACKERS] high io BUT huge amount of free memory

2013-05-02 Thread Josh Berkus
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 instead,

Re: [HACKERS] high io BUT huge amount of free memory

2013-05-02 Thread Shaun Thomas
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

Re: [HACKERS] high io BUT huge amount of free memory

2013-05-02 Thread Andres Freund
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.

Re: [HACKERS] high io BUT huge amount of free memory

2013-05-01 Thread Bruce Momjian
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, there's just

Re: [HACKERS] high io BUT huge amount of free memory

2013-04-28 Thread Craig Ringer
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 of that

Re: [HACKERS] high io BUT huge amount of free memory

2013-04-24 Thread Robert Haas
On Tue, Apr 23, 2013 at 10:50 AM, Shaun Thomas stho...@optionshouse.com 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

Re: [HACKERS] high io BUT huge amount of free memory

2013-04-24 Thread Shaun Thomas
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

Re: [HACKERS] high io BUT huge amount of free memory

2013-04-24 Thread Andres Freund
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.

Re: [HACKERS] high io BUT huge amount of free memory

2013-04-24 Thread Shaun Thomas
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

Re: [HACKERS] high io BUT huge amount of free memory

2013-04-24 Thread Andres Freund
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 you

[HACKERS] Re[2]: [HACKERS] high io BUT huge amount of free memory

2013-04-24 Thread Миша Тюрин
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

[HACKERS] Re[3]: [HACKERS] high io BUT huge amount of free memory

2013-04-24 Thread Миша Тюрин
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:

[HACKERS] Re: [HACKERS] Re[3]: [HACKERS] high io BUT huge amount of free memory

2013-04-24 Thread Миша Тюрин
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

Re: [HACKERS] high io BUT huge amount of free memory

2013-04-23 Thread Shaun Thomas
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

Re: [HACKERS] high io BUT huge amount of free memory

2013-04-22 Thread Merlin Moncure
On Mon, Apr 22, 2013 at 1:22 PM, Миша Тюрин tmih...@bk.ru 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

Re: [HACKERS] high io BUT huge amount of free memory

2013-04-22 Thread Sergey Konoplev
On Mon, Apr 22, 2013 at 11:22 AM, Миша Тюрин tmih...@bk.ru wrote: free -g total used free sharedbuffers cached Mem: 378250128 0 0229 -/+ buffers/cache: 20357 and ! disks usage 100%