Hot answers tagged


Your problem actually lies here: Normal free:29372kB min:32768kB low:40960kB high:49152kB active_anon:0kB inactive_anon:0kB active_file:44kB inactive_file:128kB unevictable:44kB isolated(anon):0kB isolated(file):0kB present:131072kB managed:124196kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:3876kB ...


EDIT: This answer totally misses the problem. See Matthew Ife's post about the crazy high setting on vm.min_free_kbytes The router and tor have been running for a while, correct? I suspect you are being hit by external (memory) fragmentation. If you look in your OOM logs you can see that there are many chunks of available memory, but if none of them are as ...


You have a couple of obvious problems. First: vm.swappiness = 100 You've told the kernel to swap as aggressively as possible, even when it's not strictly necessary to do so. On an embedded device (which usually won't have swap at all) this is completely insane. This should be set to 0 (probably best) or 1. Second: vm.overcommit_memory = 2 Aside from ...


You may go for the Redis recommendation, as the PostgreSQL packages for Ubuntu already implement the approach mentioned in the documentation against an ill-advised OOM kill of the postmaster process. It's just after the section you're refering to in the doc. Excerpt from Linux Memory Overcommit Another approach, which can be used with or without ...


This works for me with Docker 1.5.0: docker run --privileged --net=host --rm ubuntu:latest /bin/sh -c \ 'echo 65535 > /proc/sys/net/core/somaxconn'


The problem probably is that the path is quoted for core_pattern. Try this instead: kernel.core_pattern = /srv/core/%p_%t.core


1. ulimit This is a builtin command of your shell (bash/ash/zsh etc). It temporarily sets process limits for the current shell. This is not OS X specific by the way. 2. sysctl Most unix-like (Linux/*BSD/OS X) systems set global limit/kernel settings via the sysctl command//etc/sysctl.conf config file. But see below for the OS X caveat. 3. launchd Seems ...


The problem is that there usually are several switches in the path in between the two endpoints (i.e., servers). While with rmem you may increase the size of the buffers in the endpoints, it does not affect the buffers in the switches, which are rather limited. So you may lose packets due to overflows in the switches buffers.


I propose this: kernel.sem = 350 358400 64 1024 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 4194304 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_adv_win_scale = 2 net.ipv4.tcp_moderate_rcvbuf = 1 net.ipv4.tcp_rmem = 4096 262144 4194304 net.ipv4.tcp_wmem = 4096 262144 4194304 ...

Only top voted, non community-wiki answers of a minimum length are eligible