Эта статья описывает несколько простых шагов, которые можно выполнить,
для получения прироста производительности сетевой подсистемы, а также
правильно выбрать железо и настроить программную часть.
Введение
Когда Вы пытаетесь что либо оптимизировать, Вы должны прекрасно
понимать, что можно получить и прямо противоположный результат.
В последнем разделе приводится несколько тестирующих программ.
Внимание: Не забывайте делать резервые копии. Пользуйтесь тестами, для
определения того, действительно ли Вы оптимизировали систему, а не
наоборот.
Оптимизация системы
Общие положения:
Любая система может быть загружена ненужными демонами и процессами. К
примеру, можно сократить число открытых виртуальных консолей в
/etc/ttys.Также, весьма сомнительна польза sendmail на файловом
сервере. Освобождненная амять может использоваться как сетевой буфер и
повысит устойчивость сервера к DoS/DDos атакам.
Настройка sysctl:
Очень много полезной информации можно почерпнуть в man tuning(8), где
есть целый раздел, посвященный sysctl. В этой статье мы сосредоточимся
исключительно на тюнинге сети.
sysctl (8) позвляет администратору устанавливать переменные ядра.
Размещение этих переменных подобно MIB в SNMP. Помните, что если
изменения не будут внесены в sysctl.conf, то после перезагрузки они
будут потеряны.
Чтение и установка параметров может быть сделана следующим образом:
% sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0
# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1
% sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 1
Размеры буфера TCP:
Каждое подключение TCP имеет входящий и исходящий буфер. Большой обьем
буфера часто может улучшить работу сети TCP но также будет потреблять
больше памяти. В процессе работы вызывается системный вызов write(2),
до тех пор, пока все данные не будут посланы и если буфер достаточно
большой, чтобы принять всю посылаемую инфрмацю, процесс бы не
блокировался, пока ядро обрабатывает буфер. В зависимости от Вашей
ситуации Вы можете уменьшить или увеличить net.inet.tcp.sendspace и
net.inet.tcp.recvspace sysctls. 65535 - обычное знаение серверов с
большим обьемом памяти.
Внимание: проконсультируйтесь с net.inet.tcp.rfc1323 sysctl и
tuning(7), если хотите сделать буфер больше, чем 65535.
Размер очереди:
kern.ipc.somaxconn ограничивает размер очереди, принимающей входящие
подключения TCP. Если сервер достаточно мощный, то это значение
следует повысить, для того чтобы входящий запрос был поставлен в
очередь, а не отброшен. Значение по умолчанию 128, но это слишком
мало. Рекомендуемое значение - 1024.
Открытые файлы:
Параметр kern.maxfiles позволят Вам откорректировать число
одновременно открытых дескрипторов файлоы в Вашей системе.
Дополнительные настройки:
Вывести вообще все арамеры sysctl, относящиеся к сети, можно командой:
% sysctl net
Информация о значениях может быть найдена в различных man, например
inet6(4) для дерева net.inet6.
Правильный выбор сетевой карты
Правильный выбор сетевой карты можеть оказать решающее влияние на всю
сетевую подсистему в целом. Современные системы легко забют канал 100
Мб/с, если у вас стоит плохая свая карта. Так как дешевые карты
поддерживают только основной набор функций (подобно картам на чипе
Realtek 8139), то процессор сервера должен будет делать операции,
которые, в случае более дорого решения, может выполнять сама сетевая
карта. Если Вы хотите сделать высокопроизводительный сервер, то трата
нескольких лишних баксов на хорошую сетевуху - правильный выбор. Выбор
Gbit-карты даже в сети FastEthernet, тоже может быть обоснованным, так
как такие карты поддерживают еще больше возможностей.
Разгрузка контрольной суммы:
IP, TCP и UDP пакеты содержат контрольные суммы, которые используются,
чтобы проверить правильность содержания этих пакетов. Контрольная
сумма должна быть рассчитана при посылке и проверена при получении. В
случае, если ваша плата поддерживает разгрузку контрольной суммы, эта
особенность будет включена автоматически.
Уменьшение прерывания:
Каждый полученный пакет вызывает аппаратное прерывание, что означает,
что текущий процесс, выполняющийся на центральном процессоре сохранен,
и подпрограмма программы обработки прерывания загружена на центральный
процессор, чтобы обработать полученный пакет. После обработки пакета
старый процесс загружается на центральный процессор снова. На системах
с большой нагрузкой такое переключение может занимать уже значительное
время. Используя уменьшение запроса на прерывание (также известное как
управление IRQ) можно подавить прерывание, пока сетевая карта не
заполнит свой буфер, а затем, вызвав прерывание, разом его опустошит.
На Intel fxp(4) это выглядит так:
%ifconfig fxp0 | head -1
fxp0: flags=8843 mtu 1500
# ifconfig fxp0 link0
% ifconfig fxp0 | head -1
fxp0: flags=9843 mtu 1500
Обратите внимание:
Когд флаг link0 установлен, вывод dmesg покажет,что карта работает в
режиме управления IRQ. Если ваш fxp (4) плата не поддерживает
уменьшение запроса на прерывание, флажки будут установлены, но Вы не
будете видеть эту строку в dmesg:
fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6
Внимание: Читайте man на свою карту, так как link0 могло выставить
применение другого настроечного параметра.
Совместное использование прерывания:
Совместное использование сетевыми картами прерываний - неочевидный
метод уменьшения времени. затрачиваемого на переключение между
прерываниями.Как только прерывание было вызвано, все устройства на том
прерывании будут проверены на наличие необработанных данных. В случае,
если две карты, сохраняющие пакеты в порядке поступления в буфер
совместно используют одно прерывание, и один из буферов полон, будет
вызвано прерывание.
Polling режим:
Сетевые карты - устройства, управляемые прерываниями, то есть при
получении пакета будет вызвано прерывание,так что драйвер знает, что
есть пакет, который будет обработан. Как уже говорилось ранее, для
загруженой системы, большой трафик, а соответственно и большое
количество прерываний может стать проблемой. В Polling - режиме
сетевая карта никогда не генерирует прерывание, а ждет, когда ОС
опросит карту, накапливая тем временем информацю в буфере и надеясь,
что он не переполнится. Этот Polling - драйвер обычно вызывается между
двумя процессами, таким образом сокращающая время контекстного
переключения.
Хорошие драйвера могли бы переключать между IRQ и pollinfg режимами в
случае если работа по прерываниям обнаруживает несколько раз подряд
пустой буфер, и обратно, если буфер начинает переполняться. Пока что
данная возможность на FreeBSD не реализована.
Scatter/Gather и zero-copy:
Пакеты состоят из заголовка и полезного груза на каждом уровне модели
OSI. Если ваша сетевая карта может собрать заголовок и полезный груз
от двух различных буферов, ядро не должно копировать оба буфера
(нулевая копия) перед передачей, и таким образом эта особенность
значительно улучшает работу. Системный вызов sendfile(2) может
улучшить работу таких сетевых карт, так как это позволяет посылать
данные в сокет без промежуточного хранения.
Jumbo frames:
Jumbo frames - это пакеты Ethernet, которые в шесть раз больше чем
обычные 1500 байтов + заголовок Ethernet (9108 байтов). Фреймы только
немного большие чем 1518 байтов называют baby jumbo frames. При
использовании таких пакетов резко возрастает КПД сети, так как
заголовок Ethernet остается тем же самым,то есть 20-байтовый IP и
20-байтовую TCP, тогда как количество полезного груза увеличивается.
Дополнительно большие пакеты уменьшают потребность во фрагментации,
что снижает нагрузку на процессор. http: // www.uoregon.edu / ~
joe/jumbo-clean-gear.html - содержит информацию по поддержке Jumbo
frames.
Установка максимального блока передачи данных на SysKonnect sk (4):
# ifconfig sk0 mtu 8000 % ifconfig sk0 | head -1 sk0: flags=8843 mtu 8000
Crypto поддержка:
Очень немного плат могут провести IPsec кодирование аппаратно. Ни одна
из них в настоящее время не поддерживается FreeBSD, хотя эти платы
могут использоваться как стандартная сетевая плата, с планами на
будущее.
rl(4) n n n n n y don't expect outstanding performance from this card :)
fxp(4) n y/n n n n y Not all cards support IRQ mitigation.
xl(4) y n n n n y
txp(4) y ? ? n n y currently there is no support for builtin HW ipsec acceleration
sk(4) y ? y 9000 n ?
bge(4) y ? ? 9000 n y
nge(4) y ? ? 9000 n y Jumbo frames >8170 Bytes need checksum offloading to be turned off
ti(4) ? ? y 9000 n y
lge(4) y n ? 9000 n y VLAN support may be buggy
sf(4) y ? ? n n y
em(4) y ? ? 16114 n y Intel does not recommend using Jumbo frames for UDP traffic!
Оптимизация пакетной фильтрации:
Пакетные фильтры защищают сервер от злонамеренного трафика
рассматривая каждый пакет. Оптимизация правил поможет уменьшить время,
необходимое для анализа пакета и определения его дальнейшей судьбы.
ipfilter:
Анализирует список правил сверху донизу. заключение о судьбе пакета
делается по последнему подходящему правилу, или когда применяется
правило quick. Перемещение обычных правил в верх списка и конвертируя
их к правилам quick улучшает работу. При настройки правил на
нескольких интерфейсах, Вы Вы столкнетесь с ситуацией, что большинство
фильтров установлено на внешнем интерфейсе, и внутренний трафик сетей
нуждается только в ограниченном осмотре. По умолчанию ipf будет
пробовать применить все внутренние и внешние правила к каждому пакету,
таким образом нагружая процессор и вводя маленькую задержку при
отправке пакетов во внутренней подсети. Правила фильтрации, основанные
на ipf (5) позволяют создавать наборы равил sub-rulesets, чтобы пакеты
проходили проверку только при пинадлежности к определнной группе, что
позволяет не проверять пакеты внутреннего интерфейса. См. IPF Howto
для более подробной информации.
pf:
pf -акетный фильтр OpenBSD. Он образовался как переписанный ipfilter,
сохраняя совместимость настроек и синтаксиса правил, но быстро
развиваясь предлагает несколько уникальных особенностей. Более
подробную информацию можно найти здесь -
http://pf4freebsd.love2party.net/ pf использует файлы конфигурации,
которые в настоящее время превосходят ipfilter, основа одинакова.
group и head считаются избыточными и более не поддерживаются, так как
pf генерирует оптимизированный набор правил, основаннй на конфигурации
сервера.
Traffic shaping:
Traffic shaping не будет увеличивать количество данных, посланных
через интерфейс, но может изменить соотношение трафика. Напимер SSH
довольно чувствителен к стабильности канала, тогда как скорость
передачи ftp может варьироваться в широких пределах. ipfw (8) имеет
собственный механизм под названием pipes, ipf (5) и pf полагаются на
ALTQ.
Внимание: ALTQ поддерживается ограниченным числом драйверов, таких как
lo(4), fxp(4), xl(4), dc(4), rl(4), gx(4), ep(4), wi(4), и не
поддерживается tun(4).
Приложения
Apache:
Быстродействие веб-сервера зависит в основном от мощности процессора.
Будем считать это проблемой. не касающейся данной статьи и приведем
следующие ссылки:
* Official Apache 2.0 performance notes http://httpd.apache.org/docs/misc/perf-tuning.html
* http://www.pantz.org/webservers/apache/tuningtips.shtml
NFS:
Ресурсы NFS используются для большого количества приложений, mount_nfs (8)
покажет все возможные варианты, которые могли бы повысить
производительность сервера.
Samba:
В локальных сетях. где редки потери пакетов, Nagle алгоритм мог бы
замедлить скорость передачи, так как позволяет находиться в сети
только одному неподтвержденному пакету. Отключаем.
Редактируем smb.conf:
socket options = TCP_NODELAY
дополнительные сведения можно найти в файле speed.txt, идущем вместе
дистрибутивом samba.
FTP:
Серверы ftp можно разделить на несколько классов. Есть
крупномасштабные сайты подобно ftp.freebsd.org, которые должны иметь
дело с высоким количеством параллельных пользователей с разной
скоростью подключения. А есть ftp, которые должны справиться с
небольшим количеством клиентов на быстрых подключениях - например, в
локальной сети. Программное обеспечение для сервера ftp выбирается в
соответствии со стоящими задачами. В любом случае Вы должны выбрать
сервер, который все еще поддерживается, чтобы удостовериться, что
проблемы защиты получают требуемое внимание. В большинстве случаев
больше (бесполезных) особенностей нуждается в большем количестве
памяти и системного времени.
vsftpd (http://vsftpd.beasts.org/) называет себя вероятно самым
безопасным и самым быстрым сервером ftp для UNIX-подобных систем, и
это возможно так.
Эталонное тестирование
При каждом изменении конфигурации необходимо проверить быстродействие
системы. В большинстве случаев простая статистика трафика в реальном
масштабе времени и средства контроля эффективности помогут оценить
производительность системы.
Эта статья лишь поверхностно охватывает средства тестирования системы,
хотя в интернете их великое множество. Советую обратиться к Linux
Benchmark Suite Homepage.
Измерение и контроль пропускной способности:
Пассивный контроль сетевых устройств позволяет администратору
наблюдать текущее состояние или снимок нагузки, тогда как активное
измерение пропускной способности может использоваться, чтобы разыскать
критические параметры и проверить стабильность сервера перед его
"выходом в свет".
systat:
systat -ifstat 1 покажет сетевую статистику всех имеющихся сетевых
интерейсов, systat-tcp 1 покажет соответственно статистику TCP
соединений.
slurm:
slurm - базирурующееся на ncurses приложение, мониторящее загрузку
сети, доступное в системе портов net/slurm или здесь - http://www.raisdorf.net/slurm/.
bing:
bing - двухточечный инструмент измерения пропускной способности. В
отличие от предыдущей версии (доступной на ftp://netsw.org/net/ip/audit/load/bing/)
генерирует флуд пакетов, чтобы определить максимальную возможную сетевую
производительность между двумя данными хостами.
ttcp:
Эта программа следует за подходом решения "в лоб" для определения
пропускной способности. Используются две программы - одна как источник
трафика, вторая используется для приема и измерения пропускной
способности.
% ./ttcp -srv
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp
ttcp-r: socket
В этот момент sink ждет единственного входящего подключения. ttcp -
источник берет адрес IP для данных, которые будут переданы как
параметры:
% ./ttcp -t 10.11.12.13 < /dev/zero
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ->
10.11.12.13
ttcp-t: socket
ttcp-t: connect
%
Отменить предачи данных можно нажав Ctrl+C, время необходимое для
получения сатистических данных - около 30 секунд. Данные появятся на
принимающей стороне.
ttcp-r: accept from 10.11.12.14
ttcp-r: 584466432 bytes in 5.00 real seconds = 114153.60 KB/sec
+++
ttcp-r: 584466432 bytes in 3.33 CPU seconds = 171401.80 KB/cpu sec
ttcp-r: 389722 I/O calls, msec/call = 0.01, calls/sec = 77944.40
ttcp-r: 0.0user 3.2sys 0:05real 66%
ttcp-r: buffer address 0x804c000
%
Определенное значение для подключения между двумя хостами примера -
114153KB/sec, который является полной доступной скоростью Gbit. Это
само значение бесполезно, если Вы не сохранили вывод предыдущего
испытания ttcp. Взгляните не только на пропускную способность но также
и на используемое процессорное время, так как большинство настроек
включает задачи разгрузки центрального процессора и таким образом
должно быть видимо в результатах испытаний.
P.S. Перевод не претендует на безупречность, если что-то поломалось в
ходе опробывания советов из этой статьи - я непричем!
Vova
