Tag Info

Hot answers tagged

15

You can find the documentation in man 5 proc (or at kernel.org): This file contains the kernel virtual memory accounting mode. Values are: 0: heuristic overcommit (this is the default) 1: always overcommit, never check 2: always check, never overcommit In mode 0, calls of mmap(2) with MAP_NORESERVE are not checked, and the default check is very ...


4

This particular setting falls under the influence of the network namespace that docker runs in. As a general rule /proc does alter settings that are relevent systemwide, technically speaking however you are altering settings in /proc/net which returns results on a per network namespace basis. Note that /proc/net is actually a symlink to /proc/self/net as ...


3

I believe you created an orphan socket by killing the connection on the .137 server. So, the kernel parameter in use would be tcp_orphan_retries - which has a generic linux default of 7. You can get a description of both the condition you created and the results here: http://www.linuxinsight.com/proc_sys_net_ipv4_tcp_orphan_retries.html


3

I found the answer. This server is a VPS and it is running in a OpenVZ container and I'm not allowed to modify any kernel parameter of that container.


1

You can also try udev rules depending on what you want to set. For example, on my system I set my SSDs to use the deadline scheduler via /etc/udev/rules.d/60-ssd-scheduler.rules containing: # set deadline scheduler for non-rotating disks ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline" You should be ...


1

Actually, you haven't necessarily increased the buffers; merely the maximum possible size of the queues. When you open a socket, the queues are set to the value of: net.core.rmem_default = 212992 net.core.wmem_default = 212992 So increasing the maxima will do nothing unless the application is calling setsockopt() to increase the queue size (and failing, if ...


1

What kind of network timeouts do you have? TCP keep alive will not help if the server is to busy to respond in time. It will only help to detect when the TCP connection is no longer alive because the peer crashed or some packet filter in between closed states because of inactivity of the connection.


1

so tcp keepalive is different then something like nginx/apache keepalive. tcp keepalive keeps the connection open in case an error has happened. Like the client didn't get the request so it can re-try it over the same connection. Now that rarely happens and general rule of thumb is you want to keep a high tcp keepalive on a NAT server so it doesn't lose the ...


1

50 seconds for a response is very unusual. I suggest that you remove all of the TCP sysctrl tunings, and restore all of the settings to default for your OS. Once you have the basic configuration working, then tune one parameter at a time, and benchmark.


1

The privileged container is still using its own process namespace for /proc. What you can do is to mount the real /proc inside the container: docker run --rm --privileged -v /proc:/host-proc ubuntu:latest \ 'echo 65535 > /host-proc/sys/net/core/somaxconn'



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