search for: overcommit_memori

Hello, In general I am in the habit of turning off memory overcommit because I believe it's a bad thing in a multi-user environment. This was never a problem on rhel5 systems, but on rhel6, I am having issues. When I try to set overcommit_memory=2, my system locks up. It basically behaves as if the memory is all used up... I see the same behavior on centos6 or rhel6. Following is

Sysctl Values ------------------------------------------- net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.tcp_window_scaling = 1 # vm.max-readahead = ? # vm.min-readahead = ? # HW Controler Off # max-readahead = 1024 # min-readahead = 256 # Memory over-commit # vm.overcommit_memory=2 # Memory to

Hi All, I've been tuning a server recently and just today this has started to appear in my top/htop output. [root at db1 ~]# ps -aux | grep kernel root 1011 0.0 0.0 212048 4532 ? Ss 13:34 0:00 /usr/bin/abrt-watch-log -F BUG: WARNING: at WARNING: CPU: INFO: possible recursive locking detected ernel BUG at list_del corruption list_add corruption do_IRQ: stack overflow: ear stack overflow

On 02/17/2016 07:08 AM, Michael H wrote: > On 17/02/16 13:01, Johnny Hughes wrote: >> I normally just let the daily announce post to this list show what >> is available for updates, but there is a CVE (CVE-2015-7547) that >> needs a bit more attention which will be on today's announce list >> of updates. >> >> We released a new glibc yesterday for

On 02/17/2016 08:10 AM, Michael H wrote: >> The easy answer is yes .. glibc requires so many things to be restarted, >> that is the best bet. Or certainly the easiest. >> >> Note: in CentOS 7, there is also a kernel update which is rated as >> Important .. so you should boot to that anyway: >>

> The easy answer is yes .. glibc requires so many things to be restarted, > that is the best bet. Or certainly the easiest. > > Note: in CentOS 7, there is also a kernel update which is rated as > Important .. so you should boot to that anyway: > https://lists.centos.org/pipermail/centos-announce/2016-February/021705.html > > Here is a good link to figure out what to

BUGS By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. This is a really bad bug. In case it turns out that the system is out of memory, one or more processes will be killed by the infamous OOM killer. In case Linux is employed under

Hi - Running into the error below when copying over large files via ssh. This occurs even when I have vm.overcommit_memory=2 set in /etc/sysctl.conf. The research I've done indicates that this is a bio-uses-GFP_DMA bug with EM64T. I'm running CentOS 4.4 with the 2.6.9-42.0.3.ELsmp x86_64 kernel on the following hardware: 2 x Intel Xeon CPU 5148 @ 2.33GHz Supermicro X7DB8 motherboard

I have continous oom&panic situation unresolved. I am not sure system fills up all the ram (36GB). Why this system triggered this oom situation? Is it about some other memory? highmem? lowmem? stack size? Best Regards, Kernel 3.10.24 Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0 Dec 27 09:19:05 2013 kernel: :

Hi, re-posting this with a more appropriate subject for my reply; > The easy answer is yes .. glibc requires so many things to be restarted, > that is the best bet. Or certainly the easiest. > > Note: in CentOS 7, there is also a kernel update which is rated as > Important .. so you should boot to that anyway: >

Hey guys and gals, Yesterday I had one of my scientists kill one of my servers when his program ran amok and gobbled up all the memory, or forked too many processes, or I'm just not exactly sure what to be honest. Is there something I can run manually in cron to look for rampant programs and kill them? I know that may be hard to discern but I could also include a list if "known

On 02/17/2016 08:39 AM, Johnny Hughes wrote: > On 02/17/2016 08:10 AM, Michael H wrote: >>> The easy answer is yes .. glibc requires so many things to be restarted, >>> that is the best bet. Or certainly the easiest. >>> >>> Note: in CentOS 7, there is also a kernel update which is rated as >>> Important .. so you should boot to that anyway:

On 17/02/16 14:32, Michael H wrote: > Hi, re-posting this with a more appropriate subject for my reply; > >> The easy answer is yes .. glibc requires so many things to be restarted, >> that is the best bet. Or certainly the easiest. >> >> Note: in CentOS 7, there is also a kernel update which is rated as >> Important .. so you should boot to that anyway:

Hi, Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek: > On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote: >> On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote: >>> Hello, >>> >>> I'm using Dovecot 2.3 and sometimes i get this: >>> >>> --- snip --- >>> Jan 23 14:23:13 mail dovecot:

On 17/02/16 14:44, Johnny Hughes wrote: > On 02/17/2016 08:39 AM, Johnny Hughes wrote: >> On 02/17/2016 08:10 AM, Michael H wrote: >>>> The easy answer is yes .. glibc requires so many things to be restarted, >>>> that is the best bet. Or certainly the easiest. >>>> >>>> Note: in CentOS 7, there is also a kernel update which is rated as

Hi all, today we've encountered quite strange issues with memory allocation on one of our VPS running CentOS 6.2. So far I've been unable to determine what's causing it - hopefully someone here will know what's up. The VPS is a "small" machine - just 512MB of RAM, 1 CPU, running 6.2. with current kernel (2.6.32-220.4.2.el6.x86_64, but I've tried the

Tetsuo Handa wrote: > 20171016-deflate.log.xz continued printing "puff" messages without any OOM > killer messages, for fill_balloon() always inflates faster than leak_balloon() > deflates. > > Since the OOM killer cannot be invoked unless leak_balloon() completely > deflates faster than fill_balloon() inflates, the guest remained unusable > (e.g. unable to login

Tetsuo Handa wrote: > 20171016-deflate.log.xz continued printing "puff" messages without any OOM > killer messages, for fill_balloon() always inflates faster than leak_balloon() > deflates. > > Since the OOM killer cannot be invoked unless leak_balloon() completely > deflates faster than fill_balloon() inflates, the guest remained unusable > (e.g. unable to login

On Wed, Oct 18, 2017 at 07:59:23PM +0900, Tetsuo Handa wrote: > Tetsuo Handa wrote: > > 20171016-deflate.log.xz continued printing "puff" messages without any OOM > > killer messages, for fill_balloon() always inflates faster than leak_balloon() > > deflates. > > > > Since the OOM killer cannot be invoked unless leak_balloon() completely > >

I'm very sorry about posting HTML. I know better then that and should have double checked my defaults. I'm reposting this hoping someone Is there a known bug that samba has on older machines in low memory environments? I have set up a 486 with 24Mb of memory with RedHat 7.1. I set it up to run dhcpd, xinetd, and samba. Samba was not run through xinetd. The samba server had a tendency