Mosix 1.0.5

Кто-нибудь пробовал ставить сабж на рабочие серваки? Сильно глючит? Как прирост производительности?

Я ставил, но там много завист от софта который Ты будешь использовать, и какая будет у Тебя загрузка машины. Система сделана так что она перекидывает процессы на другие машины, я к сожалению не смог сильно это протестировать, потому как машину 2х900 1ГБ RAM + RAID трудно загрузить :)) я в ручную перекидывал процессы с одной машины на другую. В общем это все дело хорошо живет на 2-х машинах + Mosix + HeartBeat.

попробуй пароли перебрать desовские например. на 200mmx было 30000 вар/с. интересно сколько будет у тебя ;)
ps. john the ripper

Ты глуп, волосат? Забыл, как john the ripper параллелится? Только подбором функций генерации паролей. Тут от ОС никакой кластеризации даром не надо. Так что не предлагай больше таких дурацких тестов.

А apache+postgre кто-нибудь пытался им распаралеливать? Прирост производительности на глаз заметен?

ты тормоз? считаешь что нельзя расбросать перебор на несколько процесоров? ты навеное большой спец.

Пожуй свой волосат. Разбросать можно, но только ручками. Читай документаловку к рипперу. Там чиста по понятиям базарят, что единственный пока поддерживаемый вариант распараллеливания - выбор N функций генерации паролей, которые давали бы полный набор и не пересекались, и ручной запуск нескольких процессов (можно и на разных машинах) с этими разными функциями. Кому-то одному да повезёт. Никакой кластеризации тут просто даром не надо - нет обмена сообщениями между процессами. Так что обломись, и не смей больше тут давать глупых советов. Ламерьё учиться должно, а не выступать с умным видом.

Ставил я предыдущую версию MOSIX, но с ним были определенные проблемы. На одной из машин стоит dial-up доступ на основе portslave (правда от стандартного плагина для pppd мало что осталось) при запуске с новым ядром набдюдаются след проблемы - w подвисает и ничего не выводит, ps ax выводит все до первого процесса portslave (не включая его) и все... алис... Сам же портслейв тоже не работает (входящие идут, но трубку модемы не берут. При этом mgetty работает нормально, что за проблема - не пойму, сейчас попробую новую версию, но сомневаюсь что получится что нибудь хорошее. Да, ядро не стандартное используется, с моими патчами в serial.c для поддержки мультимодемных плат IDC M, но сомневаюсь что в этом дело, сам mosix в serial.c вносит изменения только на предмет serial console.

Rumb.

a setiathome через него распаралелить можно? :)~

seti наврядли. насколько я понял, принцип состоит в том, что оно мигрирует процессы. тоесть если у тебя запускалось 10 процессов, то 5 из них оно перенесет на другой комп. а если он у тебя 1 - новый оно не породит. И это правильно!

nu,ne znaju,chego tam pravilnogo...vot yesli by ono moglo pasparralelyt' odin process...;(

А для хостинга подойдет Mosix? Ваше мнение?

"Оно" сделано не для распаралеливания единичных процессов, а для
повышения производительности вычислительного центра за счет добавки
отдельных узлов ( Антихрист, поправь, если чего, только без proprietary language, а то не поймут ). Отдельные узлы могут быть
гораздо дешевле чем компоненты в равном vendor-решении.

Т.е: имея комп 1 процессором, который стоит 3000 американских тугриков, можно купить супер-комп с 8-ю процессорами за 80,000 тугриков, а можно докупить еще 7 компов, по 3000 тугриков каждый,
и получить производительность одного порядка.

2Omerm: Ошибаетесь, батенька.
Учитывая перекидки по сетке (даже 1Gbit), обращения к винтам, трату времени на синхронизацию и прочее, в лучшем случае производительность будет повышаться согласно графику y=a*sqrt(x) (где x - количество машин в кластере, a - некий коэффициент погрещности, а y - производительность системы).

Хм... Нечто подобное верно также и для многопроцессорных систем:
НИ ОДНА многопроцессорная железка НЕ ДАЁТ УДВОЕНИЕ ПРОИЗВОДИТЕЛЬНОСТИ ПРИ УДВОЕНИИ ЧИСЛА ПРОЦЕССОРОВ.

Что уж говорить про кластеры... Хотя, я не спорю, есть у них весьма заманчивое качество: ДЕШЕВИЗНА. ;-))) В конце-концов, ничто ведть не мешает купить на 7 писюков, а 14 ;-)))).

Не совсем верно. Прочитайте моё удалённое сообщение (ответ тупому волосату) - как я там сказал, вид кластеризации, подходящий для решения задачи, зависит от следующих свойств задачи:

1) уровень обмена между процессами

2) чувствительность ко времени отклика

3) равномерность распределения нагрузки на процессы (e.g. могут быть контроллирующие процессы, которые почти не жрут CPU, но через них идёт большой поток сообщений)

Соответственно, исходя из этих критериев, Mosix можно применять в системах, где процессы практически не связаны (обмена нет, шаренной памяти тем более нет), но при этом невозможно ручное или примитивное автоматическое распределение процессов по узлам (иначе же вместо Mosix потребовалось использовать batch pool). То есть, в качестве примера можно привести ба-альшой терминальный сервер, обслуживающий, к примеру, толпу студентов, которые не шибко активно что-то считают, а просто сидят в редакторе, компилят, дебаггят, и т.д. Собственно, все случаи применения Mosix в реальной жизни, о которых я слышал, к этому и сводились. Лично мне Mosix никак не поможет - мои задачи ложатся либо на SMP - если очень много завязанно на шаренную память, либо на модель message passing (e.g. PVM3 или MPI). Кластеризацию a la Mosix я применял только в вышеозначенном случае - три VAX-а под OpenVMS объеденяются в кластер и обслуживают толпу злобных студентов. И то, я быстро понял, что если им привелегии урезать, то можно всех на одну машину усадить, а остальные под свои задачи забрать... ;)

2ROOT: ну, с тем что N-way кластер не даст увеличения производительности в N раз, никто и не спорит. И конечно же сетка
будет тормозить поболее локальной шины. Однако и локальная шина не
даст увеличения производительности в N раз.

Насчет формулы y = A * sqrt( x ): По моему конкретная формула
сильно зависит от задачи.

2Antichrist: с терминальных серверов Мозикс и начинался. Но сейчас
вроде у них и своя дистрибутная фс есть, т.е. для хостинга она тоже
вроде бы как подходит.

Кластер иногда может дать увеличение производительности в N раз на N узлах. При минимальном уровне обмена между узлами. Классический пример - помянутый тут уже SETI@HOME.

Насколько я знаю MOSIX не сможет распараллелить Apache и PostgreSQL т.к. последние используют shared memory. Если я ошибаюсь подправьте.

2Antichrist: А ты считай время не с того момента, как хост получил пакетик, а с того, как ему пакетик только начали ГЕНЕРИТЬ. И, о чудо, получится, что прирост в производительности окажется весьма и весьма низким (однако, разумеется, не настолько, чтобы им пренебречь ;-) ).

2Omerm: Разумеется, это упрощенная формула, НО: для каждой задачи можно подобрать довольно точное значение коэффициента а, при котором формула станет почти верна. ;-)))

Ну, в таком случае, прирост производительности в общем случае равен
Зю, при точно подбранном значении Зю для каждого конкретного случая.

Вопрос не в существовании Зю, а в эмпирической формуле для нахождения
Зю в конкретных случаях.

Чуть-чуть математики "для бедных"

Tm = Tl + A * ( Tp / N ), где:

Tm - время выполнения задачи на кластере
Tl - сигма времени выполнения всех не-парралелизируемых частей
A - некий коеффициент, зависящий в основном от реализации кластера
и соотношения производительностуи инфраструктуры ( сети ) к
производительности ядра ( процессора, например )
Tp - сигма времени выполнения всех параллелизируемых частей
N - количество узлов кластера.

Таким образом, прирост производительности для Mosix-style кластера
будет выглядеть так:

Tl + Tp
Coeff = ------------
Tl + A *( Tp / N )


Как отсуда следует O( sqrt( N ) ) не совсем ясно, но видно что
производительность кластера напрямую зависит от соотношения
Tl/Tp

> Насколько я знаю MOSIX не сможет распараллелить Apache и PostgreSQL

Apache и без Mosix очень хорошо параллелится, равно как и апач с php/jserv. PostgreSQL в чистом виде не распараллелится, поскольку активно использует SysV IPC для блокировок и обмена между backend'ами и postmaster'ом. Если второе явно лечится, то первое - не факт.

Вернёмся к SETI@HOME: там пакетик посылается, ну, допустим, в течении 10 минут. Данные все давно готовы, их только отослать надо всем клиентам, порезав на кусочки. Всё равно эти 10 минут - пренебрежимо мало по сравнению с часами, затраченными клиентом на обсчёт пакетика. Так что не гони, а просто посчитай. И учти, у меня масса таких задач, где прирост производительности линейный.

Хм... Если прирост - линейный, то на кой фиг тратить ресурсы на кластеризацию??? Разбей задачу для каждой машины ОТДЕЛЬНО.

А это тоже называется кластеризацией. Ибо должна быть какая-то подложка, вроде PVM3-серверов, дабы обеспечить message passing, балансировку нагрузки и централизованное управление процессами. Даже batch pool, и тот требует некоторой программной подложки, которая в принципе могла бы быть реализована и на уровне ОС.