Оптимизация производительности сети Freebsd

Как теперь, имея возможность увидеть, что происходит с сетевой подсистемой FreeBSD, можно повысить ее производительность? При рассмотрении вопроса оптимизации существует простое эмпирическое правило: ничего не предпринимать. Вообще производительность сетевой подсистемы ограничивается только возможностями аппаратных средств. С другой стороны, многие приложения не в состоянии обрабатывать данные с той же скоростью, с какой их поставляет сетевая подсистема. Если у вас появилась мысль о необходимости оптимизации производительности системы, скорее всего вы смотрите не в ту сторону. Прочитайте главу 19, где приводятся рекомендации для тех, кто занимается поиском узких мест.

Вообще говоря, сетевая подсистема нуждается в корректировке только в том случае, если вы испытываете сложности при работе в сети. Это означает, что вы должны иметь результаты работы команд netstat -m и netstat -s, которые явно указывают на нехватку ресурсов, выделяемых ядром. Если ядро начинает отвергать запросы или закрывать соединения из-за нехватки ресурсов, прочитайте рекомендации, которые приводятся в этом разделе. В первую очередь, при появлении проблем или при желании повысить производительность системы обратите внимание на аппаратные средства.

Оптимизация сетевых аппаратных средств

Не все сетевые устройства одинаковы. То, о чем часто слышал любой специалист в области информационных технологий, открытая природа FreeBSD делает очевидным. Например, ниже приводится комментарий, взятый из исходных текстов драйвера сетевой карты rl:

The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is probably the worst PCI ethernet controller ever made, with the possible exception of the FEAST chip made by SMC. The 8139 supports bus-master DMA, but it has a terrible interface that nullifies any performance gains that bus-master DMA usually offers.
(Перевод: Сетевая карта RealTek 8139 PCI по-новому заставляет оценить понятие 'низкокачественный'. Это, пожалуй, самый худший PCI-контроллер Ethernet из когда-либо производившихся, за исключением разве что чипа FEAST, выпускаемого компанией SMC. Карта 8139 поддерживает работу с DMA, но интерфейс карты настолько ужасен, что сводит на нет весь выигрыш в производительности, который обычно способна дать поддержка DMA.)

Этот комментарий может быть перефразирован так: «Эта карта не выдерживает никакой критики. Купите другую карту». Это самый едкий комментарий, который я видел в исходных текстах FreeBSD, впрочем, в наше время эти устройства очень сложно найти. В других драйверах содержатся более корректные комментарии в адрес других сетевых карт. Оптимизировать производительность сетевой подсистемы с помощью низкокачественных устройств — это все равно, что пытаться ставить гоночную трансмиссию на Chevrolet Chevette 1982 года. Скорее поможет замена дешевой карты. Например, Intel выпускает вполне приличные сетевые карты, эта компания предоставляет свой драйвер FreeBSD для своих проводных карт и обеспечивает поддержку сообществу FreeBSD, которая помогает сопровождать этот драйвер. (Беспроводные карты — это уже другая история.) Подобным же образом многие другие компании, выпускающие серверы, считают для себя обязательным использовать высококачественные сетевые карты. Некоторые компании не предоставляют никакой документации к своим устройствам, но поставляют свои драйверы для FreeBSD. Это означает, что драйвер наверняка будет работать, но вы впадаете в зависимость от поставщика при планировании будущих обновлений системы. Устройства от производителей, специализирующихся на выпуске недорогого потребительского сетевого оборудования, — это не самый лучший выбор для установки на высокопроизводительный сервер. В конце концов, обычный средний пользователь понятия не имеет, как выбирать сетевые карты, и в основном руководствуется ценой на изделие. Если у вас возникают сомнения, обращайтесь в архивы почтовых рассылок, где можно найти достаточно свежие рекомендации по выбору сетевых карт.

Точно так же в широких пределах варьируется и качество сетевых коммутаторов. Если в сопроводительной документации утверждается, что коммутатор поддерживает соединения со скоростями 10/100 Mbps, это совершенно не означает, что вы в действительности получите скорость 100 Mbps! У меня есть сетевой концентратор, рассчитанный на скорость 10 Mbps, который обеспечивает скорость всего 0.5 Mbps, и коммутатор на 100 Mbps, который дает всего 15 Mbps. Скорость работы коммутатора можно представить себе как протокол или язык: я могу заявлять, что говорю по-китайски, но через 20 лет после окончания обучения я смогу выговорить не более трех слов в минуту. Опять же, коммутаторы, предназначенные для домашнего пользования, не самый лучший выбор для использования в промышленных условиях.

Если замена устройств не решила ваших проблем, тогда читайте дальше.

Память

При принятии решения, какой объем памяти выделить для нужд сетевой подсистемы, FreeBSD исходит из общего объема физической памяти. Память, выделяемая для mbufs, не может использоваться для каких-либо других целей, поэтому выделение гигабайтов памяти под mbufs может негативно сказаться на общей производительности системы. Не следует корректировать число mbufs, если команда netstat -m явно не укажет на нехватку пространства под mbufs. Если сетевой подсистеме не хватает памяти, самый действенный способ ликвидировать эту проблему заключается в увеличении общего объема памяти компьютера. Это вынудит FreeBSD пересчитать объем для mbufs во время загрузки и тем самым решит проблему. В противном случае вы лишь переместите проблему в другую часть системы или в другое приложение. Можно было бы выделить больше памяти для сетевой подсистемы и посадить на голодный паек сервер базы данных. Если вы уверены в своих действиях, то можно предпринять следующее.

Распределением памяти для mbufs управляют два параметра sysctl — kern.maxusers и kern.ipc.nmbclusters. Первый из них, kern.maxusers, является настройкой, выполняемой на этапе загрузки. Система автоматически определяет соответствующее значение kern.maxusers во время загрузки, исходя из аппаратной конфигурации. Корректировка этого значения — пожалуй, лучший способ масштабировать систему в целом. В старых версиях FreeBSD значение kern.maxusers отвечало за предварительное выделение памяти для сетевой подсистемы, вследствие чего она становилась недоступной для решения других задач, поэтому чрезмерное увеличение значения kern.maxusers могло приводить к ужасным последствиям для других частей системы. В современных версиях FreeBSD предварительное распределение памяти для сетевой подсистемы не производится, а данное значение обозначает лишь верхний предел, до которого может расти объем памяти сетевой подсистемы. Если значение kern.maxusers слишком мало, в файле протокола /var/log/messages начнут появляться предупреждения (глава 19).

Числом mbufs, выделяемых системой, управляет параметр kern.ipc.nmbclusters. Хотя этот параметр и допускает настройку во время работы системы, тем не менее лучше устанавливать его на ранних этапах загрузки, добавив запись в файл /etc/sysctl.conf (глава 5). Это позволит отобрать память у других задач и передать ее сетевой подсистеме или наоборот. Если это значение выбрать слишком большим, это может привести к нехватке памяти для других задач и даже к аварийному завершению системы.

# sysctl kern.ipc.nmbclusters
kern.ipc.nmbclusters: 25600

Память для mbufs выделяется блоками, которые называются nmbclusters (иногда mbuf clusters). Хотя размер одного блока mbuf может варьироваться, размер одного кластера остается постоянным и составляет порядка 2 Кбайт. С помощью несложных вычислений можно выяснить, сколько памяти выделяется для текущего количества nmbclusters, а затем рассчитать приемлемые значения для системы и приложений. В данном примере имеется 25600 nmbclusters, то есть ядро зарезервировало для нужд сетевой подсистемы порядка 50 Мбайт памяти. Это не так много, учитывая, что речь идет о ноутбуке с объемом памяти 1 Гбайт, но это слишком много для какого-нибудь антикварного Pentium.

Чтобы найти наиболее подходящее количество кластеров mbuf, нужно запустить netstat -m, когда сервер испытывает серьезную нагрузку. Во второй строке результатов вы получите число mbuf, находящихся в использовании, и общее их число. Если в периоды пиковой нагрузки сервер не использует полный объем доступных кластеров mbuf, следовательно, вы идете по ложному пути — прекратите эксперименты с mbufs и замените, наконец, аппаратные устройства.* Например:

В настоящий момент система использует 32 кластера (1), и в кэш были помещены 372 кластера (2), использовавшиеся ранее. При количестве кластеров, равном 404 (3), и общем объеме выделенной памяти 25600 кластеров (4) мы получаем, что используется всего 1,5 процента. Если это реальная нагрузка на систему, то имеет смысл уменьшить число nmbclusters. Однако есть вероятность, что ваш компьютер вообще имеет низкую нагрузку, тогда любая оптимизация не имеет смысла.

Мое личное эмпирическое правил гласит: сервер должен иметь такое количество mbufs, чтобы оно в два раза превосходило потребность при высокой нагрузке. Если сервер потребляет 25 000 кластеров в часы пик, значит общее число кластеров должно составлять 50 000, чтобы иметь возможность противостоять пиковым нагрузкам.

Планирование пропускной способности сетевой подсистемы

Придет день, когда к вам придет ваш шеф и спросит: «Какой нужен сервер, чтобы иметь возможность обслужить одновременно сто тысяч клиентов?» Я не смогу помочь вам в оценке объемов памяти, которая потребуется вашему приложению (ладно, ладно — я смогу это сделать, но это тема уже другой книги), но рассчитать объем памяти, необходимый для сетевой подсистемы, вам вполне по силам. Каждое ТСР-со- единение требует наличия приемного и передающего буфера, тогда как для входящих UDP-соединений требуется только приемный буфер. В ходе сеанса FreeBSD может изменять размеры этих буферов, но изначально они имеют размеры, заданные значениями по умолчанию. Узнать значения по умолчанию можно из параметров sysctl — net.inet.tcp.sendspace, net.inet.tcp.recvspace и net.inet.udp.recvspace.

# sysctl net.inet.tcp.sendspace
net.inet.tcp.sendspace: 32768
# sysctl net.inet.tcp.recvspace
net.inet.tcp.recvspace: 65536
# sysctl net.inet.udp.recvspace
net.inet.udp.recvspace: 41600

Предположим, что у вас имеется веб-сервер, который должен обрабатывать одновременно сто тысяч подключений. Протокол HTTP работает поверх протокола TCP, поэтому для каждого соединения потребуется выделить приемный и передающий буферы. Для каждого соединения потребуется 96 Кбайт памяти (32 768 байт + 65 538 байт = 98 304 байт, или 96 Кбайт). Для одновременного обслуживания ста тысяч пользователей потребуется 9 Гбайт памяти (100 000 х 96 Кбайт = 9 Гбайт)! Кроме того, на этом компьютере должно работать какое-то приложение. Вам потребуется предусмотреть какое-то решение, связанное с распределением нагрузки или кэшированием данных, или готовьтесь писать чертовы объяснительные по поводу единственного компьютера.

Задайте следующий далее вопрос тому, кто попытается предположить, что вам придется одновременно обслуживать сто тысяч пользователей. Если только вы не работаете в Yahoo! или в одной из конкурирующих компаний, вам едва ли придется видеть такие нагрузки. Даже если у вашего веб-приложения и наберется 100 000 зарегистрированных пользователей, то они, скорее всего, никогда не будут работать с ним одновременно. Сколько денег вы готовы потратить, чтобы гарантировать работу в этом крайне редком случае?

«Раз в жизни» и стандартная нагрузка

Когда вступил в действие регистрационный сайт правительства США «do not call» с черным списком телефонов, с которых поступают рекламные звонки, одновременно на этом сайте попытались зарегистрироваться миллионы пользователей. Первый день сайт работал ужасно медленно, но уже через неделю сервер прекрасно справлялся с нагрузкой. Это наглядный результат правильного планирования пропускной способности. Нужно отличать пиковые нагрузки, которые случаются один раз в жизни, от обычных повседневных нагрузок.

Максимальное число входящих соединений

Ядро FreeBSD обеспечивает пропускную способность, необходимую для обработки определенного числа новых входящих ТСР-соединений. Это ограничение не касается уже установленных и обрабатываемых подключений, оно относится к числу новых соединений, которые пытаются установить одновременно. Например, в это число не попадают веб-страницы, которые к настоящему моменту уже были отправлены клиентам, — сюда относятся входящие запросы, которые еще даже не достигли веб-сервера.

Параметр kern.ipc.somaxconn определяет максимальное число одновременных попыток установить соединение, которые будут обслужены системой. По умолчанию оно равно 128, что может оказаться недостаточным для веб-сервера, работающего под высокой нагрузкой. Если вы занимаетесь сопровождением высокопроизводительного сервера, который, как ожидается, будет получать более 128 новых запросов одновременно, скорее всего, вам потребуется увеличить этот параметр sysctl. Если от пользователей начинают поступать жалобы, что они не могут подключиться к серверу, причина может крыться в значении этого параметра. Конечно, очень немногие приложения способны принимать такое количество новых подключений, поэтому, прежде чем изменять этот параметр, вам, возможно, следует настроить само приложение.

Опрос

Механизм опроса берет проверенную временем идею прерываний и IRQ и выкидывает ее из окна, заменяя регулярными проверками сетевой активности. В классической модели, управляемой прерываниями, всякий раз, когда пакет поступает в сетевую карту, она требует от центрального процессора уделить ей внимание, генерируя прерывание. Процессор прекращает обычную последовательность операций и приступает к обработке этих данных. Это очень хорошо и даже желательно при условии, что карта не занимается обработкой трафика большого объема. Но как только система начинает иметь дело с огромными объемами данных, сетевая карта начинает генерировать прерывания непрерывно. Более эффективный способ заключается в том, чтобы ядро извлекало данные из сетевой карты через регулярные интервалы времени. Такая регулярная проверка называется опросом (polling). Вообще говоря, использовать механизм опроса полезно только в случае объемного трафика.

К моменту написания этих строк механизм опроса невозможно собрать в виде модуля ядра, так как он требует изменений в драйверах устройств. Также следует иметь в виду, что не все сетевые карты обладают поддержкой механизма опроса, поэтому обязательно ознакомьтесь с полным списком, который приводится в странице руководства polling(4). Чтобы активировать механизм опроса, следует добавить параметр DEVICE_POLLING в конфигурацию ядра. После перезагрузки системы разрешить использование механизма опроса отдельно для каждого из устройств можно с помощью команды ifconfig(8).

# ifconfig re0 polling

Точно так же, с помощью аргумента -polling, можно запретить использование этого механизма. Кроме того, команда ifconfig(8) показывает, был ли активирован механизм опроса для интерфейса.

Так как активация и деактивация механизма опроса возможны прямо в процессе работы системы, попробуйте активировать его в часы высокой нагрузки и проверить, не приведет ли это к повышению производительности.

Изменение размера окна

Для обслуживания входящих соединений система FreeBSD использует три буфера: net.inet.tcp.sendspace, net.inet.tcp.recvspace и net.inet.udp.recvspace. Гуру TCP/IP эти параметры настройки известны как размер окна (window size). При изменении размеров этих буферов изменяется и производительность сетевой подсистемы. Значения по умолчанию были выбраны не просто так: они работают. С увеличением размеров буферов увеличивается объем памяти ядра, которая должна выделяться для каждого соединения. Если одновременно не увеличить количество nmbclusters соответственным образом, может не хватить памяти для работы сетевых служб.

В версии FreeBSD 7.0 размеры этих буферов регулируются автоматически, в зависимости от сетевой нагрузки. В Интернете вам часто будут попадаться ссылки на информацию, описывающую порядок настройки этих параметров sysctl, но это лишь отзвуки многолетнего усовершенствования FreeBSD. В действительности вам не следует выполнять настройку этих параметров вручную.

Прочие способы оптимизации

В системе FreeBSD имеется порядка 150 параметров sysctl, которые имеют отношение к сетевой подсистеме. В ваших руках есть все необходимые инструменты, которые позволят оптимизировать систему до такой степени, что она вообще не будет пропускать трафик. Будьте крайне осторожны, экспериментируя с оптимизацией сетевой подсистемы. Многие параметры позволяют избавиться только от одного набора проблем, тут же принося другие. Некоторые производители программного обеспечения (например, Samba) рекомендуют вносить изменения в отдельные параметры настройки сети. Будьте осторожны с ними, прежде чем принять их как новые значения по умолчанию, обязательно проверяйте на появление побочных эффектов в других программах. TCP/IP очень, очень сложный протокол, и настройки по умолчанию, принятые в системе FreeBSD, отражают многолетний опыт тестирования и страданий системных администраторов.

Источник : freebsdguide.ru/_6/_8/