Tag Info

Hot answers tagged


You can find the documentation in man 5 proc: 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 weak, leading to ...


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


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.


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.


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 ...


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.


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 ...


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 ...

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