D
D
Daniel Newman2012-09-24 16:30:57
System administration
Daniel Newman, 2012-09-24 16:30:57

Netdev_max_backlog detect and other sysctl. How not to get into a stupid situation?

It is considered good manners in a professional environment to spit in the direction of howtoforge. More precisely, in the "masters of mindless use" of other people's thoughts at the expense of fine (and thick) server settings. Let's say there are thousands of quick tutorials on how to set up nginx, install proxmox, etc. That's why I have my self-installed proxmox, with sysctl "out of the box" debian, with parameters on the host virtualization machine like this:
net.core.netdev_max_backlog = 1000
And a bunch of guest machines with their parameters:
net.core.netdev_max_backlog = 100500
I feel in my heart, it looks like a dude with a throat the width of a watermelon and a mouth - into the mouse sphincter. At the same time, go look for the correct net.core.netdev_max_backlog on the Internet - you will find advice to set this parameter to 30000. OK, only in the original of that replicated recommendation a machine with a 10Gb uplink and a HiEnd class piece of iron was considered (but what do we care).
And a little bit of grumbling on this topic:
Okay, it seems like you can guess, but what I’m completely afraid of not guessing and passionately want to pull is the view parameters:

kernel.*
vm.*
fs.*
debug.*
dev.*
ubc.*
net.* (с этого и начну)
abi.*
crypto.*
sunrpc.*

Or maybe in the default which parameters are missing completely? Maybe there is some kind of meticulous guide “for those who think” with examples from 2011/12?
Man - this is not quite the option, to dive into the core sorts - there will not be enough brains. What to do? Stupidly roll away from the core for a year or two?
For starters, there were only a couple of articles on Habré on protecting against spoofing without any warning that the
included * .rp_filter will put you sideways if you have a “smeared” hardware cluster (there is money for a cluster - buy admin services).
What is *.accept_source_route fraught with? Accept_source_route itself is mentioned in Google (over the past year) only 3 thousand times. This, as it were, hints at a lack of knowledge on this topic (“boobs” were discussed 3.4 million times this year - this is 1150 times more often).

Answer the question

In order to leave comments, you need to log in

1 answer(s)
E
egorinsk, 2012-09-25
@egorinsk

To get an answer to the question “what values ​​​​to set on my machine”, there are 2 options - show the car to someone who understands everything, or sit with diagnostic tools yourself, count the percentage of lost packets, response time and other things, find the causes of problems and fix.
Have you tried reading the docs at www.kernel.org/doc/Documentation/sysctl/ and www.kernel.org/doc/Documentation/networking/ ?
The backlog_detect you mentioned, for example, is more than clearly described in the doc:
> Maximum number of packets, queued on the INPUT side, when the interface receives packets faster than the kernel can process them.
Naturally, the optimal value depends on the performance of the machine and the speed of the network interface.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question