В конфиге однозначно много мусора и как-нибудь я доберусь его почистить. Собственно, я и начал сначала сокращать большинство параметров в сторону "по умолчанию", но в итоге получил значительную деградацию производительности, после чего увеличил количество параметров почти втрое :)
Да, насчет конфигурации ядра. Если вы помните, я в свое время рекламировал congestion control HTCP, действительно классная и хорошо работающая штука, но, поскольку от версий ядер, где были ошибки у cubic, я ушел, то решил все же использовать более распространенное, т.е. сейчас у меня скомпилирован только кубик и разницы с HTCP не видно, повторяю: net.ipv4.tcp_congestion_control = cubic. Вернул просто, чтобы было ближе к умолчательному варианту, но можно и оставить, если не забывать, что оно там есть и когда-то может устареть или работать хуже.
Второй нюанс в конфиге ядра - CONFIG_HZ_250, именно такой он у меня сейчас и установлен. Долгое время был CONFIG_HZ_100, и, хотя видимого изменения быстродействия самого сервера я не замечал, при CONFIG_HZ_250 LA (load average) все время болтается в 3-4, а при CONFIG_HZ_100 - 5-7. Нервировало, хотя, скорее всего, это просто огрехи подсчета LA. Оставил CONFIG_HZ_250.
Парадоксально, но задранные (на мой взгляд) до полумиллиона значения действительно дают эффект. Но, тем не менее, выставлять rmem_default и аналогичные размеры буферов не стоит. Достаточно минимум и максимум. Остальное все считается в автомате и на автомате работает лучше, чем с фиксированно установленными ручными значениями. По крайней мере я это анализировать не умею и натюнил только ухудшение. Выкинул то, что было во многих рекомендациях - стало быстрее.
vm.dirty* на быстродействие сети, понятно, не влияет. Копипастил, пока проблем нет - оставил, хотя это первые претенденты на вынос. В свое время воевал, помню, что были какие-то проблемы. Но это было еще на диске, сейчас SSD.