![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
nuclightТри недели назад Андрей Шетухин, руководитель отдела почты Rambler, сообщил о начале миграции своего почтового кластера (порядка 500 серверов) с FreeBSD на Linux (Debian/Ubuntu), поскольку FreeBSD перестала его устраивать. Дискуссия в комментах, которых уже более полутысячи, разгорелась нешуточная. В комментах также стало известно, что аналогичный переход планирует Яндекс на своем поисковом кластере, который в данный момент работает целиком на FreeBSD, а это примерно 25000-30000 серверов, и порядка 60% мощностей Яндекса. Такая потеря — это для FreeBSD уже серьезно. С такими тенденциями система, к радости ликующих подонков, станет таки умирать.
Очевидно, что подобные решения не принимаются на ровном месте, и существуют определенные причины, проблемы, которые мы, FreeBSD, можем начать исправлять, пока не стало слишком уж поздно. BSD-сообщество привыкло закрывать глаза на многие проблемы, считая их несущественными. Более так поступать нельзя — легко списать всё на тараканы в голове менеджмента и ничего не делать, вот только постоянное повторение такого образа действий приведет к тому, что лет через 5 работу BSD-администратора будет уже не найти (Вы такую перспективу себе хотите? Я лично — нет). Однако, с другой стороны, тот же Шетухин 3 месяца назад писал "Вывод простой: миграция на Linux нецелесообразна, так как затраты на нее не окупятся" о том, что разницы в производительности FreeBSD и Linux для их целей не выявлено. То бишь, следует отделить зерна от плевел и решать те проблемы, которые действительно есть.
Таким образом, имеется два утверждения (которые будут более подробно рассмотрены далее), причем оба истинные и друг другу не противоречат:
I. Конкретно в случае Рампочты уход с FreeBSD затеян из-за неадеквата руководства, внутри у них полный бардак (по словам инсайдеров).
II. У FreeBSD действительно есть серьезные проблемы, нам необходимо их решать, иначе нам каюк.
По второму вопросу — в следующем посте предполагается анализ, каковы еще проблемы FreeBSD и как их можно решить, с опросом мнения читателей. Но сначала — о том, почему держателям акций Рамблера стоит продавать их, пока курс еще хороший.
Часть I. Конкретно в случае Рампочты уход с FreeBSD затеян из-за неадеквата руководства, внутри у них полный бардак (по словам инсайдеров).
Что выяснилось в процессе обсуждений как в комментах к посту, так и в других местах? Например, то, что проблемы и претензии Рампочты к FreeBSD были вызваны во многом их собственной спецификой. А именно, это закрытый отдел, и они не используют наработки остальной части Рамблера. В условиях больших систем нормально организовывать работу ведь следует как? Делается собственная сборка системы, часть машин выделяется под компиляцию (сборку пакетов), часть под тестирование. Этот процесс требуется всегда, какой бы там дистрибутив не стоял — даже с самым бинарным будет сделан свой локальный репозиторий, в котором собираются пакеты под задачи фирмы. И распространяются пакеты аналогично. Может быть видоизменен инсталлятор для автоматизации разливки на новые машины кластера, и т.д.
Но у них, в отделе почты, свой инсталлятор, они не пользуются, например, тем, что сделано у работающего в соседнем отделе Глеба Смирнова, коммитера FreeBSD. Из высказанных претензий складывается впечатление, что администраторам Рамблер-почты неизвестно ни про freebsd-update(8) — средство бинарного апгрейда базовой системы, имеющееся в ней уже 5 лет (обновляет в две простые команды, "скачать" и "поставить"). Ни про portmaster, написанная на чистом /bin/sh утилита обновления пакетов, альтернатива portupgrade — претензия к которому была, что он тянет за собой язык Ruby.
Аргументов было много, внятный перечень (я тут свёл воедино из нескольких разных комментов) был таким:
Серьезные ли это причины? Серьезные, хотя разбираться мы с ними будем позже. Но, однако в другом месте встречаем признание: "Собственно, все пертензии к деплойменту — невозможность в автомате с учетом всех требуемых зависимостей поднять версию системы и/или переустановить те пакеты, которые требуются. Это — прямое следствие использования pkg_*."
Решаема такая проблема с FreeBSD? В принципе, решаема, но требует скриптования. Вполне понятно и желание не заниматься рутинной работой, которую уже сделали другие. Другое дело, что максимально её сложить с себя можно только, если кто-то это будет делать на оплачиваемой основе. Вполне резонно следующее мнение: "Удивительно, что Rambler, ища стабильность и уверенность + иметь возможность своих админов отпускать вечерами домой к семье выбрали опять черти что, а не коммерческий RedHAT, где они получат любую консультацию почему у них что-то не работает. А ведь для такой конторы как Рамблер стабильность должна быть на первом плане, а они ищут халявки. позор."
Тут-то уже закрадываются подозрения, что не во FreeBSD дело — ведь, как резонно отмечали, даже конкретно Debian не уменьшит работу админов до нуля как по волшебству. Подозрения закрадываются в том, что текущие админы Рампочты попросту не в состоянии адекватно управляться с FreeBSD. Так ли это?![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
slonik_v_domene пишет по этому поводу:
Далее находится (в IRC) сам этот ровно один человек, это былospf_ripe, и комментирует заявление "FreeBSD сложно майнтейнить" так:
Аналогичной точки зрения придерживаются и другие сотрудники Рамблера. В частности, известно, что оттуда в свое время уволился и Максим Дунин (mdounin). Сам slonik_v_domene от комментариев насчет него отказался, а Глеб Смирнов высказался по этому поводу так:
[UPDATE:glebius@ поправляет, что это был неmdounin, а maxim@freebsd.org]
По непроверенным слухам,slonik_v_domene работал ранее в компании СУП (которой принадлежит ЖЖ) и был оттуда уволен за примерно такие же действия — взять и устроить революцию работающей системы без оснований.
Прямых подтверждений тому у нас нет, зато косвенных — валом. Например, мной был задан вопрос, чего не хватает FreeBSD, как нам можно её улучшить. Ответом был приведенный выше перечень, что именно стоило бы сделать. Однако последовавшее за этим обсуждение показало странные вещи. Глава Рампочты никак не хочет признаваться, в какие же именно затраты рабочего времени администраторов (то есть в конечном счете финансовые затраты) выливается та или иная проблема FreeBSD. Например, еще более-менее понятно, чем плох BIND в базовой системе, хотя даже по этому вопросу конкретику с цифрами я почему-то получил от другого человека. А вот чем администратору мешает наличие в базовой системе какой-нибудь мелкой утилиты, скажем, make — уму непостижимо. Если она не используется — она вообще не требует внимания админа, лежит себе да лежит. Если её требует кто-то по зависимостям — она всё равно будет поставлена по зависимостям, что во фре, что в дебиане. Если всё ставить вручную — наоборот, требуется время админа на расстановку галок в инсталляторе (или его эквиваленте), никакого выигрыша...
Такой отказ в назывании конкретики говорит о том, что причины не технические. А тут еще выясняется что? Что из Рамблера по-тихому, 3 месяца назад, ушел Игорь Сысоев, автор известного web-сервера nginx. Итого, из Рамблера ушло уже трое. Между тем, внимания заслуживает еще такая цитата:
Изменятся ли подходы от смены систем? Ни разу, "внезапная революция в мосгах, бывает ли такое". Подходы зависят от людей. Заблуждение о том, что есть "серебряная пуля", инструмент, с которым все проблемы сразу решатся, к сожалению, популярно... В другом треде в обсужденииslonik_v_domene также заявлял о том, что предпочтительны системы, с которыми справится и новичок. Он считает, что "первопричина — это не люди, а системы. А люди — следствие". В действительности же — именно люди, ключевым является именно персонал, а не инструменты. Нет смысла останавливаться на этом подробно и переубеждать того, кто до понимания положения "кадры решают всё" еще не дорос. Я просто процитирую по этому вопросу классика:
В Рамблере же всё происходит с точностью до наоборот. Кроме того, Андрей Богородский прокомментировал, что штатная сетка рампочты привела его в тихий ступор — с точки зрения риск менеджемента два человека администраторов недостаточно даже для текущего саппорта, что уж говорить о развитии (чтобы от болезней/свадеб/отпусков не зависеть, по КЗОТу для обеспечения круглосуточной работы должно быть минимум 5 человек на клетку).
[UPDATE: Эта ситуация относилась к 2008 году. Как сообщает А. Шетухин, сейчас сисадминов хватает для покрытия всех суток.]
В довершение ко всему, глава Рампочты еще и относится наплевательски к сообществу и исповедует паразитизм, считая, что его должны носить на руках уже за сам факт использования системы. Этика между тем проста: ему дали систему забесплатно, он ничем разработчикам не обязан, но и не имеет права требовать от них ничего, а уж тем более вставать в позу и оскорблять кого-то. Вот если бы помог хоть чем-то (тот же Яндекс, скажем, помогал)... но он хамски требует. И, не получив, уходя, он предпочитает обосрать всех и вся. Может быть, и специалисты из Рамблера сбегают из-за такого отношения руководства?..
Как бы там ни было, потеря уже невелика. "С таким подходом через 3-5 лет Рамблером не будет пользоваться никто, кроме маргиналов". Прощай, Рамблер! А мы пойдем дальше разбираться со своими проблемами сами.
Часть II. У FreeBSD действительно есть серьезные проблемы, или мы их решаем, или нам каюк.
опубликована отдельным следующим постом
Очевидно, что подобные решения не принимаются на ровном месте, и существуют определенные причины, проблемы, которые мы, FreeBSD, можем начать исправлять, пока не стало слишком уж поздно. BSD-сообщество привыкло закрывать глаза на многие проблемы, считая их несущественными. Более так поступать нельзя — легко списать всё на тараканы в голове менеджмента и ничего не делать, вот только постоянное повторение такого образа действий приведет к тому, что лет через 5 работу BSD-администратора будет уже не найти (Вы такую перспективу себе хотите? Я лично — нет). Однако, с другой стороны, тот же Шетухин 3 месяца назад писал "Вывод простой: миграция на Linux нецелесообразна, так как затраты на нее не окупятся" о том, что разницы в производительности FreeBSD и Linux для их целей не выявлено. То бишь, следует отделить зерна от плевел и решать те проблемы, которые действительно есть.
Таким образом, имеется два утверждения (которые будут более подробно рассмотрены далее), причем оба истинные и друг другу не противоречат:
I. Конкретно в случае Рампочты уход с FreeBSD затеян из-за неадеквата руководства, внутри у них полный бардак (по словам инсайдеров).
II. У FreeBSD действительно есть серьезные проблемы, нам необходимо их решать, иначе нам каюк.
По второму вопросу — в следующем посте предполагается анализ, каковы еще проблемы FreeBSD и как их можно решить, с опросом мнения читателей. Но сначала — о том, почему держателям акций Рамблера стоит продавать их, пока курс еще хороший.
Часть I. Конкретно в случае Рампочты уход с FreeBSD затеян из-за неадеквата руководства, внутри у них полный бардак (по словам инсайдеров).
Что выяснилось в процессе обсуждений как в комментах к посту, так и в других местах? Например, то, что проблемы и претензии Рампочты к FreeBSD были вызваны во многом их собственной спецификой. А именно, это закрытый отдел, и они не используют наработки остальной части Рамблера. В условиях больших систем нормально организовывать работу ведь следует как? Делается собственная сборка системы, часть машин выделяется под компиляцию (сборку пакетов), часть под тестирование. Этот процесс требуется всегда, какой бы там дистрибутив не стоял — даже с самым бинарным будет сделан свой локальный репозиторий, в котором собираются пакеты под задачи фирмы. И распространяются пакеты аналогично. Может быть видоизменен инсталлятор для автоматизации разливки на новые машины кластера, и т.д.
Но у них, в отделе почты, свой инсталлятор, они не пользуются, например, тем, что сделано у работающего в соседнем отделе Глеба Смирнова, коммитера FreeBSD. Из высказанных претензий складывается впечатление, что администраторам Рамблер-почты неизвестно ни про freebsd-update(8) — средство бинарного апгрейда базовой системы, имеющееся в ней уже 5 лет (обновляет в две простые команды, "скачать" и "поставить"). Ни про portmaster, написанная на чистом /bin/sh утилита обновления пакетов, альтернатива portupgrade — претензия к которому была, что он тянет за собой язык Ruby.
Аргументов было много, внятный перечень (я тут свёл воедино из нескольких разных комментов) был таким:
Ок. Давайте осилим тиндербокс. Давайте осилим бинарные обновления базовой системы и пакетов. Давайте подтянем версию FreeBSD к текущей. Давайте забьем на тупизну ipfw и убогость pf по сравнению с iptables. Давайте все собирать древним как говно мамонта компилятором. Давайте жить на ufs2. Давайте сделаем еще миллион прекрасных в своей глупости вещей, лишь бы не уходить с труъ-системы на негодный Линукс.
Все это прекрасно, но моим админам не платят за название операционки. Им платят за то, чтобы все работало. Сделать так, чтобы все работало на Линуксе, объективно проще, чем на FreeBSD. Пройдет еще 3-5 лет, и фря станет системой исключительно для маргиналов.
1. Убить такое понятие как монолитная base sysem, сделать набор пакетов для base system и для ports.
Компилировать и патчить мир в 2011 году — уебанство. Кроме того, куча вещеий из base system не нужны большинству юзеров. Значит, их и ставить не надо. Тот же bind, который не запускается на 99.5% серверов. Хрена он там делает в base system?
2. Отказаться от сборки пакетов как от основного способа установки ПО.
Пакеты должны ставиться из репозитория, и только. Нужно что-то свое — делайте набор ПО чтобы подключить локальный репозиторий на машине.
3. Сделать -STABLE репозиторий с пакетами, регулярно обновляемыми патчами.
Да, это напрягает — искать патч к X.Y.Z версии одного пакета только потому, что другой пакет хочет только ее.
4. Разработать систему автообновлений, позволяющую с минимумом головной боли содержать up-to-date систему. Ключевое слово: АВТОобновлений.
5. Самое важное: все это должно быть "из коробки", без доустановки и чтения инструкций.
Я ничего против портов не имею, это наоборот, очень удобно и классно. А вот к менеджеру пакетов претензии есть.
Серьезные ли это причины? Серьезные, хотя разбираться мы с ними будем позже. Но, однако в другом месте встречаем признание: "Собственно, все пертензии к деплойменту — невозможность в автомате с учетом всех требуемых зависимостей поднять версию системы и/или переустановить те пакеты, которые требуются. Это — прямое следствие использования pkg_*."
Решаема такая проблема с FreeBSD? В принципе, решаема, но требует скриптования. Вполне понятно и желание не заниматься рутинной работой, которую уже сделали другие. Другое дело, что максимально её сложить с себя можно только, если кто-то это будет делать на оплачиваемой основе. Вполне резонно следующее мнение: "Удивительно, что Rambler, ища стабильность и уверенность + иметь возможность своих админов отпускать вечерами домой к семье выбрали опять черти что, а не коммерческий RedHAT, где они получат любую консультацию почему у них что-то не работает. А ведь для такой конторы как Рамблер стабильность должна быть на первом плане, а они ищут халявки. позор."
Тут-то уже закрадываются подозрения, что не во FreeBSD дело — ведь, как резонно отмечали, даже конкретно Debian не уменьшит работу админов до нуля как по волшебству. Подозрения закрадываются в том, что текущие админы Рампочты попросту не в состоянии адекватно управляться с FreeBSD. Так ли это?
slonik_v_domene пишет по этому поводу:Из админов ушел ровно один человек, было это в конце весны 2009 года. Причины, по которым мы расстались очень просты и печальны: мы не смогли работать друг с другом. Тем не менее, расставание прошло без ругани и взаимных истерик. И несмотря ни на что, к этому человеку я испытываю уважение за профессионализм и умение твердо отстаивать свои принципы, даже ценой рабочего места.
Далее находится (в IRC) сам этот ровно один человек, это был
ospf_ripe, и комментирует заявление "FreeBSD сложно майнтейнить" так:Wed 22:46:44 <@citrin> nuclight: не очень понятно что там маинтейнить, а миграция будет очень сложно и трудозатратной (до прихода slonik-v-domene я работал в Рампочте и представляю что там есть внутри)
Wed 22:52:18 <@citrin> обсуждать не хочется и смысла не вижу. собственно я и ушел оттуда из за того, что с Шетухиным сложно вести конструктивный диалог. Он любит все решения принимать сам, ни с кем не советуясь и не аргументируя свою точку зрения.
Аналогичной точки зрения придерживаются и другие сотрудники Рамблера. В частности, известно, что оттуда в свое время уволился и Максим Дунин (
mdounin). Сам slonik_v_domene от комментариев насчет него отказался, а Глеб Смирнов высказался по этому поводу так:Tue 16:17:37 <@glebius> ну, если бы Максим был здесь, то я думаю слоник бы не начал этого манёвра
Tue 16:17:56 <@glebius> потому как начальству будет видно, что это просто перестановка мебели
Tue 16:18:11 <@glebius> а сейчас понимающего начальства нет, так что можно попереставлять
[UPDATE:glebius@ поправляет, что это был не
mdounin, а maxim@freebsd.org]По непроверенным слухам,
slonik_v_domene работал ранее в компании СУП (которой принадлежит ЖЖ) и был оттуда уволен за примерно такие же действия — взять и устроить революцию работающей системы без оснований.Прямых подтверждений тому у нас нет, зато косвенных — валом. Например, мной был задан вопрос, чего не хватает FreeBSD, как нам можно её улучшить. Ответом был приведенный выше перечень, что именно стоило бы сделать. Однако последовавшее за этим обсуждение показало странные вещи. Глава Рампочты никак не хочет признаваться, в какие же именно затраты рабочего времени администраторов (то есть в конечном счете финансовые затраты) выливается та или иная проблема FreeBSD. Например, еще более-менее понятно, чем плох BIND в базовой системе, хотя даже по этому вопросу конкретику с цифрами я почему-то получил от другого человека. А вот чем администратору мешает наличие в базовой системе какой-нибудь мелкой утилиты, скажем, make — уму непостижимо. Если она не используется — она вообще не требует внимания админа, лежит себе да лежит. Если её требует кто-то по зависимостям — она всё равно будет поставлена по зависимостям, что во фре, что в дебиане. Если всё ставить вручную — наоборот, требуется время админа на расстановку галок в инсталляторе (или его эквиваленте), никакого выигрыша...
Такой отказ в назывании конкретики говорит о том, что причины не технические. А тут еще выясняется что? Что из Рамблера по-тихому, 3 месяца назад, ушел Игорь Сысоев, автор известного web-сервера nginx. Итого, из Рамблера ушло уже трое. Между тем, внимания заслуживает еще такая цитата:
> что подходы рампочты к администрированию конкретно fbsd, мягко говоря, плохие.
Ну, плохие и плохие. Будет Линукс вместо FreeBSD, будут хорошие подходы. Что-то возразить по существу описанных с портами проблем есть?
Изменятся ли подходы от смены систем? Ни разу, "внезапная революция в мосгах, бывает ли такое". Подходы зависят от людей. Заблуждение о том, что есть "серебряная пуля", инструмент, с которым все проблемы сразу решатся, к сожалению, популярно... В другом треде в обсуждении
slonik_v_domene также заявлял о том, что предпочтительны системы, с которыми справится и новичок. Он считает, что "первопричина — это не люди, а системы. А люди — следствие". В действительности же — именно люди, ключевым является именно персонал, а не инструменты. Нет смысла останавливаться на этом подробно и переубеждать того, кто до понимания положения "кадры решают всё" еще не дорос. Я просто процитирую по этому вопросу классика:Выдающиеся проектировщики. Главная проблема совершенствования искусства программирования заключена, как всегда, в людях. [...] Выбор правильного метода проектирования определяет различия между плохим и хорошим концептуальным проектом, но не между хорошим и выдающимся. Выдающиеся проекты создаются выдающимися проектировщиками. Создание программ является творческим процессом. Крепкая методология может придать силу и освободить творческий ум, но она не может воспламенить или вдохновить того, кто занят нудной работой.
И разница немалая — это как Сальери и Моцарт. Одно исследование за другим показывают, что лучшие проектировщики создают структуры, которые быстрее, меньше по размеру, проще, понятнее и разработаны меньшими усилиями. Различия между выдающимся и средним достигают порядка величины.
[...]
Как растить выдающихся проектировщиков? Место не позволяет обсуждать это пространно, но вот некоторые очевидные шаги:
- Систематически и как можно раньше выявлять первоклассных проектировщиков. Лучшие — не всегда самые опытные.
- Назначить наставника, ответственного за рост перспективного проектировщика и тщательно следить за его карьерой.
- Разработать и осуществлять план служебного роста для каждого перспективного проектировщика, включающий тщательно продуманное обучение у передовых проектировщиков, периоды дополнительного формального обучения, краткосрочные курсы, перемежающиеся с самостоятельным проектированием и назначением на руководящие технические должности.
- Обеспечить возможности для взаимодействия и взаимного стимулирования растущих проектировщиков.
(с) Фредерик П. Брукс. "Мифический человеко-месяц или как создатся программные системы".
В Рамблере же всё происходит с точностью до наоборот. Кроме того, Андрей Богородский прокомментировал, что штатная сетка рампочты привела его в тихий ступор — с точки зрения риск менеджемента два человека администраторов недостаточно даже для текущего саппорта, что уж говорить о развитии (чтобы от болезней/свадеб/отпусков не зависеть, по КЗОТу для обеспечения круглосуточной работы должно быть минимум 5 человек на клетку).
[UPDATE: Эта ситуация относилась к 2008 году. Как сообщает А. Шетухин, сейчас сисадминов хватает для покрытия всех суток.]
В довершение ко всему, глава Рампочты еще и относится наплевательски к сообществу и исповедует паразитизм, считая, что его должны носить на руках уже за сам факт использования системы. Этика между тем проста: ему дали систему забесплатно, он ничем разработчикам не обязан, но и не имеет права требовать от них ничего, а уж тем более вставать в позу и оскорблять кого-то. Вот если бы помог хоть чем-то (тот же Яндекс, скажем, помогал)... но он хамски требует. И, не получив, уходя, он предпочитает обосрать всех и вся. Может быть, и специалисты из Рамблера сбегают из-за такого отношения руководства?..
Как бы там ни было, потеря уже невелика. "С таким подходом через 3-5 лет Рамблером не будет пользоваться никто, кроме маргиналов". Прощай, Рамблер! А мы пойдем дальше разбираться со своими проблемами сами.
Часть II. У FreeBSD действительно есть серьезные проблемы, или мы их решаем, или нам каюк.
опубликована отдельным следующим постом
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-08-03 12:42 pm (UTC)в отрезанной мной квоте.
там сказанно, что pf MPSAFE. по цитате можешь найти переписку.
ps, top?
no subject
Date: 2011-08-03 01:08 pm (UTC)MPSAFE не означает, что он использует несколько cpu.
>>и да, как в pf узнать на каком cpu выполняется правило?
>ps, top?
1)ps & top вам это не расскажут
2)вопрос был про правила firewall.
полезно для раскидывания нагрузки при наличии нескольких hw queues в nic.
no subject
Date: 2011-08-03 01:16 pm (UTC)он может исполняться на нескольких CPU.
паралельную обработку одного пакета на нескольких CPU кажется вообще никто не делает. и смысла так вот сходу мне в этом не видно
1) скажут.
2) не понимаю. правила файрвола исполняются в контексте ip_input, которая в контексте драйвера. вот драйвер тебе и надо смотреть.
как следствие именно при наличии нескольких hw queues в nic ты это и будешь видеть.
no subject
Date: 2011-08-03 06:08 pm (UTC)речь по параллельную обработку множества пакетов на разных cpu.
>1) скажут.
и как же?
>2) не понимаю. правила файрвола исполняются в контексте ip_input, которая в контексте драйвера. вот драйвер тебе и надо смотреть.
вопрос был "как изнутри pf узнать что сейчас мы выполняемся на cpu0?"
no subject
Date: 2011-08-03 06:17 pm (UTC)для этого достаточно быть MPSAFE.
по крайне мере во freebsd.
номером CPU у кернельного треда
вот, например top
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
2 root 1 -8 - 0K 16K - 1 3:19 0.00% g_event
у меня ни трафика тут ни файрвола, так что именно обработку ip-пакетов я не смогу показать
э, а нахрена?
no subject
Date: 2011-08-03 09:45 pm (UTC)ну ок, через пару часов проверю. как раз под рукой есть
CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2394.28-MHz K8-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s) x 2 SMT threads
igb0:
ну ок, через пару часов проверю. как раз под рукой есть
CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2394.28-MHz K8-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s) x 2 SMT threads
igb0: <Intel(R) PRO/1000 Network Connection version - 1.9.5> port 0x1020-0x103f mem 0xb1920000-0xb193ffff,0xb1944000-0xb1947fff irq 40 at device 0.0 on pci1
igb0: Using MSIX interrupts with 5 vectors
>>вопрос был "как изнутри pf узнать что сейчас мы выполняемся на cpu0?"
>э, а нахрена?
Ответ комплексный.
1)http://alouche.net/blog/2010/08/24/rps-and-rfs-kernel-network-stack/
2)http://kerneltrap.org/mailarchive/linux-netdev/2010/7/22/6281568
"Some legacy applications being not SMP friendly, one way to scale a
server is to run multiple copies of them.
Instead of randomly choosing an instance, we can use the cpu number as a
key so that softirq handler for a whole instance is running on a single
cpu, maximizing cache effects in TCP/UDP stacks."
Как пример таких приложений - node.js, python-gevent, bind.
no subject
Date: 2011-08-04 04:58 am (UTC)Например: http://dadv.livejournal.com/139366.html
no subject
Date: 2011-08-04 06:56 am (UTC)не вижу ответа.
это дело шедулера знать и учитывать.
зачем это изнутри pf знать?
no subject
Date: 2011-08-05 12:00 am (UTC)>не вижу ответа.
>это дело шедулера знать и учитывать.
>зачем это изнутри pf знать?
node.js не параллелится на несколько cpu.
параллелят запуская несколько экземпляров по количеству cpu и cpuset'ом фиксируют за каждым ядром. Запросы раскидывают либо внешним балансировщиком, либо силами firewall на хосте. Когда у вас карточка с несколькими очередями, очереди "прибивают" к конкретным cpu.
Теперь ситуация: к нам приехал пакет и нам надо решить на какой из экземпляров node.js его отправить. Что будет с производительностью, если мы его из очереди на cpu0 будем отправлять его приложению на cpu5(особенно если то NUMA и cpu5 - это "соседний" сокет) объяснять не надо.
no subject
Date: 2011-08-05 03:22 am (UTC)надо. цифрами с конкретного бенчмарка.