Архив форумов ЦИТФорума

[Kest]

Добрый день, уважаемые!
После месяца использования SMP-системы (2х1.13ГГц Pentium III) под
управлением FreeBSD-4.7-STABLE появился ряд вопросов:
1. Мониторинг
В выводе dmesg есть строчки:
IOAPIC #0 intpin 2 -> irq 0
Programming 16 pins in IOAPIC #1
FreeBSD/SMP: Multiprocessor motherboard
cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000
cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000
io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec00000
io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000
то есть вроде все ок?
Но строка заголовка top'a (CPU states) вроде не изменилась, и никакого
упоминания о втором камне там нет. В колонке STATE переодически
проскакивает CPU0/1.
gkrellm вроде поддерживает вывод статистики для SMP-систем (загрузка для
каждого процессора по отдельности) только для FreeBSD 5.0, по крайней мере
так написано у автора на страничке http://gkrellm.net.
Чем и как можно смотреть загрузку для каждого процессора?
2. Поддержка SMP Linux-приложениями.
То ли я чего-то не понимаю, то ли линуксовое ПО не видит второго процессора.
Используется Oracle 8.1.7 для Linux и Sybase 11.0.3 для Линукс
Oracle не имеет настроек для указания количества процессора, во всяком
случае мне не удалось их найти, но судя по значению cpu count видит только
1. Из опыта работы с виндовым Ораклом он сам настраивается на количество
процессоров, но под FreeBSD этого ИМХО не происходит - что можно сделать?
Для включения поддержки SMP в Sybase нужно проделать ряд телодвижений, после
которых сам сервер БД вроде поднимается в многопроцессорной моде, но
попытка выполнить любой запрос отправляет его в счастливую страну
=(((
Нужно ли как-то конфигурировать эмулятор linuxа под SMP?

Для "чисто фришных" задач ускорение от второго процессора явно видно - та же
пересборка мира проходит чуть ли не в 2 раза быстрее etc.

Заранее благодарен и сорри за (возможно) нелепые/неправильные вопросы

[Dmitry.Karpov http://prof]

Если сравнить два гигагерцовых процессора и один двухгинанерцовый, то в большинстве случаев двухгинанерцовый будет быстрее (исключение - если основную нагрузку создают только две мало общающиеся друг с другом задачи: тогда два процессора выигрывают за счет того, что у них двоих больше кэша, чем у одного). Из этих соображений видно, что один самый мощный на данный момент P'III (не знаю, сколько именно он дает, но вряд ли меньше 1.7 GHz) был бы лучше, чем два по 1.13 GHz. И проблем с ним бы не было, и вопросов бы не возникало.

В принципе, возможна ситуация, когда ядро полноценно поддерживает SMP, а утилиты мониторинга - еще нет. Рекомендую почитать документацию по программе top и всякие другие материалы на сайте FreeBSD на тему SMP.

Дли Linux-программ ситуация неоднозначная. Из общих соображений я могу сказать, что эмулятор Linux может препятствовать использованию SMP приложениями - например, не сообщать приложениям о втором процессоре. Возможно, две разные Linux-программы могут быть разнесены FreeBSD-ядром на разные процессы, но обмен данными между ними может быть затруднет или даже невозможен...
А разве недостаточно того, что Linux-программы будут жить на одном процессоре, а FreeBSD-программы - на другом?

[Kest]

Один 2-х гигагерцовый может и лучше, но это уже P4, P3 вроде на 1.33 остановились.
Из собственного опыта, на больших задачах компиляции (make buildworld etc.), P4 даже с дорогой RIMM-памятью особого преймущества не демонстрирует (сравнивал 1.7 ГГц P4 с 1 ГГц Атлоном). 2х1.13 P3 ГГц/512 Мб SDRAM уверенно делают Athlon 2100+ (реальная тактовая 1733 МГц)/768 Мб DDR SDRAM (дисковая подсистема у машин примерно одинаковая IDE RAID 0+1 и IDE RAID 0). Так что насчет удачности/неудачности - вопрос ИМХО спорный

>>В принципе, возможна ситуация, когда ядро >>полноценно поддерживает SMP, а утилиты >>мониторинга - еще нет. Рекомендую почитать >>документацию по программе top и всякие >>другие материалы на сайте FreeBSD на тему >>SMP.
А что именно читать про top? man top никакой информации про SMP не содержит.
И где именно искать документацию на сайте FreeBSD? Все что удалось найти - утверждение о том, что поддерживается достаточно широкий набор чипсетов а в 5.0 поддержка SMP перейдет на качественно друой уровень

>>
>>Дли Linux-программ ситуация неоднозначная. >>Из общих соображений я могу сказать, что >>эмулятор Linux может препятствовать >>использованию SMP приложениями - например, >>не сообщать приложениям о втором >>процессоре.
очень на то похоже
>>Возможно, две разные Linux-программы могут >>быть разнесены FreeBSD-ядром на разные >>процессы, но обмен данными между ними может >>быть затруднет или даже невозможен...
меня бы на 100% устроило разнесение Оракула и Сайбеза на разные камни. Данными им обмениваться не за чем. Только как это сделать?
>>А разве недостаточно того, что >>Linux-программы будут жить на одном >>процессоре, а FreeBSD-программы - на >>другом?
Достаточно, только как управлять разнесением программ по процессорам?

[Dmitry.Karpov http://prof]

Политика Intel - хаставить всех перейти на P'4; поэтому-то они и не выпускают более быстрых P'III. При этом P'4 работает тормознуто из-за того, что у него очень длинный конвейер, который спотыкается даже на простых безусловных переходах, не говоря уж об условных - ведь обычно флаги условия формирует операция CMP, стоящая непосредственно перед условным переходом (иначе команды между ними испортят флаги). Это немного компенсируется дополнительными конвейерами и предсказанием ветвлений, но и то, и доугое очень сильно усложняет процессор (в плане количества транзисторов), не давая адекватного роста производительности.
Вывод: надо, чтобы сообщество пользователей громко требовало выпуска серверов на процессоре ARM (недавно Samsung выпустил версию Halla на 1.2 GHz - октябрьский Upgrade, стр.6).

К сожалению, у меня практически нет опыта работы с SMP, т.к. мои работодатели очень жадные и не дают денег даже тогда, когда ото должно быстро окупиться (зато тратят деньги на всякую хрень).

Полез на AltaVista, дал ей "+FreeBSD +SMP +top", получил много чего, в т.ч. http://www.freebsddiary.org/smp.php (я дал на_водку - дальше сам ищи).

[Kest]

ну вот, начался флейм
=)))
>> Полез на AltaVista, дал ей "+FreeBSD +SMP
>> +top", получил много чего, в т.ч.
>> http://www.freebsddiary.org/smp.php (я дал >> на_водку - дальше сам ищи).
за на_водку - спасибо!!!
с top'ом разобрался. Задачи сами раскидываются по процессорам оказывается, даже линуксовые.

[Dmitry.Karpov http://prof]

Я читаю в МФТИ курс "Сети и архитектуры ЭВМ". Например, я учу решать задачки типа "Что лучше купить - один свич на 20 портов или три свича по 8 портов?" - готов спорить, что ни один из студентов, не слушавших мой курс, не сможет правильно ответить, на какие особенности сетИ надо обратить внимание при принятии решения.

А флейм для меня - лишний повод задуматься над нетривиальными вопросами, которые я смогу использовать в преподавании.

PS: Я готов найти время и преподавать в любом московском институте, который готов обеспечить помещение, студентов и некоторую зарплату. Разумеется, мой курс не для общего употребления, а для избранных (относится ли конкретный человек к избранным - сначала решает он сам, выбирая, ходить ко мне на занятия или нет; а потом это подтверждается (или не подтверждается) на экзамене).

[Kest]

>>Я читаю в МФТИ курс "Сети и архитектуры ЭВМ". Например, я учу решать задачки типа "Что лучше купить - один свич на 20 портов или три свича по 8 портов?" - готов спорить, что ни один из студентов, не слушавших мой курс, не сможет правильно ответить, на какие особенности сетИ надо обратить внимание при принятии решения.
>>
можно я! можно я!
=)))
А какие задачи в этой сети решаться будут?
А сколько денег можно вложить в сеть?
etc.

>>PS: Я готов найти время и преподавать в
я из Питера, и времени у меня нет на учебу, если честно. Хотя наверное не мешало бы пройти какой-нибудь курс "Систематизация того мусора, который накопился втвоей голове за пять, нет семь лет практической работы"
=)))
Такие есть вообще?

[Dmitry.Karpov http://prof]

1. Задачи типичные - совместный доступ в Interent через фирменную выделенную линию или через DialUp; обмен файлами в M$явной сети; может, внутренний сайт и/или SQL-DB.
Кстати, этот аспект наименее актуален, IMHO.

2. Денег - как раз на сетевые карточки и на хабы (считаем, что это уже куплено).

PS: Мой курс изначально предназначался для упорядочивания мусора в головах людей, имеющих практический опыт без теоретической подготовки - это потом я его адаптировал под студентов.

[Kest]

1. Ага, тогда еще вопрос:
Можно ли выделить рабочие группы, различающиеся по порождаемым (и потребляемым) ими потоками данных?
Если да, то каков характер этих потоков (что за ПО их генерирует/обрабатывает)?
исходя из ответа, я буду прикидывать, выстраивать мне древовидную структуру (10/100 хабы+центральный свич), или установить одно очень-много-портовое устройство.
2. Не понял, как уже куплено? А из чего мне выбирать тогда?
поясню - этим летом при апгрейде сети я сразу знал, что могу потратить сумму от $3K до $5K.
исходя из этого с самого начала выбирались свичи, а не хабы ну и так далее....
P.s. А как удалось адаптировать курс? Все-таки между студентом и практиком ИМХО достаточно большая разница? То есть, студенту приходится вдалбливать ту же модель OSI, убеждая его, что это нужно, а практику достаточно сказать "смотри, то о чем ты уже и сам догадывался, действительно существует"
=)))

[Dmitry.Karpov http://prof]

1. Правильный вопрос. Будем рассматривать оба варианта:
а. единственный сервер, к которому обращаются все;
б. Несколько (три..пять) групп с основным трафиком внутри этих групп;
в. несколько серверов, к которым обращаются все.
Это, правда, не "оба", а три варианта - уже минус за то, что предусмотрел не все.

Второй минул (уже жирный) - за то, что от ПО это не зависит; и NetWare, и M$-сеть, и видеоконференции по сути одно и то же - трафик.

2. Выбирать - между 1*20 и 3*8; цена у них, будем считать, одинакова.

PS: Что касается модели OSI, то для новичков надо объяснять ее устройство; для обоих надо объяснять ее смысл и ее плохую пригодность для реальной жизни: например, т-ф провод, аналоговове т-ф оборудование и модем попадают в первый уровень; а инкапсуляция/туннелирование вообще не укладываются в N-уровневую модель, ибо Ethernet можно гонять пвнутри IP.

[Kest]

>>1. Правильный вопрос. Будем рассматривать оба варианта:
>>а. единственный сервер, к которому обращаются все;
>>б. Несколько (три..пять) групп с основным трафиком внутри этих групп;
>>в. несколько серверов, к которым обращаются все.
>>Это, правда, не "оба", а три варианта - уже минус за то, что предусмотрел не все.
>>
не придирайся
=)))
Если бы мне рассказали про рабочие группы, все три варианта были бы рассмотрены.
Вариант 1. В центр - 1х20
Вариант 2. 3х8, сервера рабочих групп - скорее всего на свичи рабочих групп, что бы замкнуть трафик внутри них.
Вариант 3. А чем он собственно отличается от 1? Все обращаются ко всем => рабочие группы невозможно выделить. Мощный свитч в центр.
>>Второй минул (уже жирный) - за то, что от ПО это не зависит; и NetWare, и M$-сеть, и видеоконференции по сути одно и то же - трафик.
>>
Агащазблин!
=)))
трафик, он конечно и в Африке трафик, тока SQL-сервер и файл сервер порождают сущееественно разные его варианты:
SQL в режиме "анализ данных"- запрос/ответ - копейки по объему, время отклика может быть существенным. Канал сервер/центральное устройство может быть симметричным.
SQL в режиме "закачка большого массива данных" - требуется широкая полоса на сервер с клиента, время отклика сервера - обычно минимально, но это обычно разовые (редкие) работы, выполняемые в момент простоя сети.
Файл-сервер - широкий канал в обе стороны, желательно иметь сервер на более широком канале, чем клиенты (1000 и 100 мбит соответственно).

Такое вот мое ИМХО.
>>PS: Что касается модели OSI, то для новичков надо объяснять ее устройство; для обоих надо объяснять ее смысл и ее плохую пригодность для реальной жизни:
Дык! Спецу про непригодность объяснять не надо - он и так мыслит категориями "физический уровень - уровень маршрутизации - уровень соединения (TCP) - уровень приложения"

[Dmitry.Karpov http://prof]

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

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

1.в. Вариант с несколькими картами в сервер становится существенно менее привлекательным: и втыкание нескольких карт в КАЖДЫЙ из серверов, и настройка роутинга на одном из серверов - большие проблемы...
И еще: даже если мы в случае 1.а не ставим много сетевых карт в сервер, то мехкоммутаторные соединения не могут быть тормозящим элементом, т.к. каждое из них имеет такую же ширину, как и соединение сервера со свичем. Но при нескольких серверах это уже не так (в смысле - могут быть тормозом).

1.б. Без разницы и то, и другое нормально работает.

На тему трафика: У нас не ADSL - Ethernet дает симметричный канал. Интерес представляет только величина трафика для выбора между 10, 100 и 1000 Mbps (а обычно ставят стандартный 100 Mbps).

Но в задаче есть еще один черезвычайно важный аспект, которого ты не учел. И есть еще один аспект, который кажется важным, но при внимательном рассмотрении оказывается ничтожным (возможно, некоторые люди изначально понимают его ничтожность). Так что думай.

[ilyasov]

В FreeBSD до 5-й версии, кажется, используется только общая очередь процессов для всех процессоров на машине. Если какой-то из рпоцессоров свободен, то он предоставляется ожидающей выполнения задаче. Отсюда мораль -если на машине работает только одна тяжелая задача, то никакого сущесвенного выигрыша по сравнению с однопроцессорной такая система не даст. В Linux вроде бы есть поддержка многонитевости на уровне ядра и разделения нитей по процессорам, в Free

[Kest]

Ага, понял
спасибо

[Kest]

1а. Ну хорошо, вариант с 3х8 лучше, но я бы все равно поставил 1х24х10/100+1х1000 - на сервер
1б. Не понимаю, чем плох вариант, в котором траффик замыкаетс ВНУТРИ рабочей группы?
1в. Все равно лучше 1х24 с достаточной емкостью внутренней матрицы (больше чем 24х100)
Насчет трафика - в приведенных мною примерах он симметричен всю дорогу, но в случае с файл-сервером желательна разная ТОЛЩИНА каналов от сервера и от клиента, что может повлиять как на выбор оборудования, так и на топологию сети.
Насчет неучтенных особенностей - см. сабж
Мне уже упомянутых критериев обычно хватает
=)))

[Dmitry.Karpov http://prof]

Установка нескольких стомегабитных карт в сервер обойдется существенно дешевле, чем организация одного гигабитного линка; чоть и эффект от нескольких карт меньше, но с разницей в цене это несравнимо.

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

А главное преимущество схемы 3*8 в том, что она позволяет накрыть бОльшую территорию и сэкономить кабели, ибо каскадируемость хабов ограничена.


Хорошо, даю другую задачу:
Допустим, к нам пришел программист, который знает языки и только что решил заняться сетевым программированием. Он решил сделать свою программу со своим протоколом обмена сообщениями. Понятно, что полностью свое он писать не будет, т.к. уже есть Ethernet, Arcnet, TokenRing, ATM и модемы; поэтому ему нужно выбрать протокол, поверх которого он будет работать. Вот выбор: ARP, ICMP, IP, IPX, NetBIOS, SPX, TCP, UDP.

[Dmitry.Karpov http://prof]

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

А какие часто используемые программы во FreeBSD используют многопоточность?

[Kest]

а под какую задачу пишется протокол обмена?
поясню - у нас сейчас есть 2 похожие проблемы - 1. обмен данными с клиентом (от него код регистрации нашего ПО, есму после проверок, наш ли это клиент - код активации). В качестве протокола передачи данных выбран http, что бы можно было по максимуму задействовать имеющуюся инфрасктруктуру, да и объемы передачи данных там копеечные;
2. Система доставки неких документов между узлами экстранета. Экстранет большой (и по количеству узлов и территориально - большая часть Сев-Зап региона). Документы маленькие (в большинстве своем) но обладают существенно разным приоритетом. В итоге приходится поверх TCP прикручивать свой уровень, отвечающий за маршрутизацию. Так что от точной постановки задачи все зависит. Во, я понял, в чем проблема! Решение по конкретно сформулированной проблеме я приму скорее всего (близкое к) оптиамльное, и даже смогу объяснить почему именно его, но научить кого-то принимать такие же решения я не смогу, т.к. не могу формализовать процесс его принятия
=)))
И в какой-такой задаче можно применить ARP для обмена данными?
=)))
>> Я понимаю, что именно за счет тех, кто
>> готов кидать деньги на новые дорогие
>> неотлаженные технологии, мы и получаем их >> (технологии) чуть позже, но уже дешево и в >> отлаженном виде. Но меня не привлекает
>> работать локомотивом прогресса за свой
>> счет - пусть это делают другие...
ну, гигабит по меди - не такое уж и дорогое решение, и не такое уж и неотлаженное.
Да и не за мой счет это делается, не получаю я съекономленных денег в виде премий
=)))
или
=(((

>> А главное преимущество схемы 3*8 в том,
>> что она позволяет накрыть бОльшую
про территориальную разнесенность речи не было, ессно, в ситуации > 100 м до свича придется ее выбирать.
>>территорию и сэкономить кабели, ибо >>каскадируемость хабов ограничена.
не понял, а на кабеле то ты что сэкономить хочешь? Летняя модернизация сети в конторе - уложено 1.5 км кабеля (сам не ожидал, что так много уйдет), но это менше чем 10% всех затрат.

[Kest]

А вот что говорят в fido.ru.unix.bsd
>Eugene Grosbein wrote:
>А вот jhb@freebsd.org говорит, что 5.0 будет >медленнее, чем 4.x
>на kernel intensive задачах и пиплу с 4.x >придется выбирать
>между фичами и пиковой производительностью
>из-за недаденности SMPng...
блин, это что получается?
=(((
и так придется ждать 5.1 (если не 5.2) до появления STABLE-ветки
=(((

[ilyasov]

Это касается только тех случаев, когда поток (нить) не реализуется через вызов fork().
В 5-й обещались сделать.

[Dmitry.Karpov http://prof]

-

[Dmitry.Karpov http://prof]

Насколько я понимаю, вызов fork() создает отдельный процесс со своим адресным пространством, т.е. в программе
fork();
x=PID;
sleep(999)
printf("...",x)
каж дая будут напечатаны именно его PID, т.к. переменная x у каждого процесса будет своя (под "PID" я имею в виду PID процесса).

Для потоков, как я понял, переменные общие. А вот разделение временеи - принудительное ии добровольное - я не понял; в W'2k я нашел упоминание о thread с принудительным вытеснением и о fiber с добровольной передачей управления.

PS: А как Squid обслуживает в одном процессе кучу соединений?

[Kest]

я просто сначала прочел документ с названием (что-то типа) "Грабли, на которые вы наступите при переходе на 5.х", из которого следует (ИМХО), что в этом самом 5.х столько проблемм, что когда появится ветка STABLE (как появится - так и перейду =))) - не ясно абсолютно - типа надо ж дать. Ну ладно, подождем, вкусности того стоят. И тут выясняется, что еще и со вкусностями напряг
=(((