Увеличиваем максимальный размер памяти отводимой для TCP буферов:
(16Мб на порядок больше, чем нужно, следует экспериментальным путем подобрать
оптимальные значения, понеменогу увеличивая параметры заданные по умолчанию)

   sysctl -w net.core.rmem_max = 16777216
   sysctl -w net.core.wmem_max = 16777216

Увеличиваем лимиты автотюнинга (min, default, max bytes)

   sysctl -w net.ipv4.tcp_rmem = "4096 87380 16777216"
   sysctl -w net.ipv4.tcp_wmem = "4096 65536 16777216"

Увеличиваем размер очереди пакетов на сетевом интерфейсе, особенно полезно для Gigabit Ethernet:

   ifconfig eth0 txqueuelen 1000

Особенности Linux ядра 2.4.x:
Для предотвращения особенности при уменьшении размера окна, из-за повторов передеачи пакетов, для одного соединения, уменьшать на 10 минут размер окна для всех остальных соединений к тому же хосту:

   sysctl -w net.ipv4.route.flush=1

Особенности Linux ядра 2.6.x:

Запрещаем кеширование статуса ssthresh (были ретрансмиты) для других соединений

   sysctl -w net.ipv4.tcp_no_metrics_save = 1

Рекомендуется увеличить размер backlog до 1000 или выше
(для 10Gb линка можно поставить 30000):  

   sysctl -w  net.core.netdev_max_backlog = 2500

Начиная с ядра 2.6.13 можно менять алгоритм обработки ситуации перегрузки:

   sysctl -w net.ipv4.tcp_congestion_control=htcp
     reno: традиционный TCP
     bic: BIC-TCP (для высокоскоростных сетей, быстрое восстановление после потери)
     highspeed: HighSpeed TCP: Sally Floyd's suggested algorithm
     htcp: Hamilton TCP (для высокоскоростных сетей)
     hybla: для спутниковых линков
     scalable: Scalable TCP
     vegas: TCP Vegas
     westwood: для сетей с большой потерей пакетов
Когда стандартный reno не устраивает рекомендуется попробовать bic или htcp.

Значения параметров тюнинга подробно описаны в документе ip-sysctl.txt в комплекте ядра:
   http://www-didc.lbl.gov/TCP-tuning/ip-sysctl-2.6.txt

URL: http://www-didc.lbl.gov/TCP-tuning/linux.html
Обсуждается: http://www.opennet.me/tips/info/1417.shtml

• Тюнинг TCP стека в Linux,SnoWLight, 10:36 , 30-Май-07
  • Тюнинг TCP стека в Linux,Аноним, 12:52 , 30-Май-07
• Тюнинг TCP стека в Linux,arruah, 20:37 , 02-Июн-07
  • Тюнинг TCP стека в Linux,Mike, 10:49 , 06-Июн-07
    • Тюнинг TCP стека в Linux,мя, 23:30 , 08-Июл-07
      • Тюнинг TCP стека в Linux,igoree, 10:43 , 20-Июл-07
  • Тюнинг TCP стека в Linux,onorua, 12:03 , 07-Июл-07
• Тюнинг TCP стека в Linux,birdie, 12:18 , 09-Авг-07

Похоже что статья перевод вот этой http://dsd.lbl.gov/TCP-tuning/linux.html
здесь тоже кое что есть http://www-iepm.slac.stanford.edu/bw/tcp-eval/

>Похоже что статья перевод вот этой http://dsd.lbl.gov/TCP-tuning/linux.html

Об этом указано в поле "Источник", dsd.lbl.gov и www-didc.lbl.gov один и тотже сайт.

А как посмотреть нужно ли это делать вообще ? :)

+1

это конечно не нужно, а то что нужно - не сказали - по умолчанию so.maxconn равен 128 соединений  - на сервере надо естественно раз в 100 больше

net.core.somaxconn ? раз в 100 - это слишком :)

cat /proc/net/netstat

Нельзя было написать "Тонкая настройка"? Русофобы, *ля.