ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Victor Kolosov                       2:5020/400     19 Mar 2001  01:11:19
 To : All
 Subject : Re: Смысл эхотага :)
 -------------------------------------------------------------------------------- 
 

 Vitaly Lugovsky wrote:
 
 > 
 > >> >>   Большинство приложений от M$? Hу так на фиг их.
 > >>
 > >> > Увы, сейчас это почти все :(((
 > >>
 > >>   Да ну? Как-то обходимся, однако...
 > 
 > > Зависит от того, чем заниматься. У нас люди работают ;)))
 > 
 >   А что, на поделиях от M$ можно работать? Я понимаю, если там MS SQL Server
 > использовать, но всякие ворды-ёксели - кому это надо?
 
 Разве я произнес хоть слово про M$?
 
 > > А лимиты не панацея... Я как-то наблюдал как пара юзеров загнали в
 > > активый спопинг машину с полугигом памяти.
 > 
 >   В юниксах - не панацея. В OpenVMS юзера просто на раз обламываются.
 > Достаточно ограничить число процессов, working set, полный размер выделенной
 > виртуальной памяти и интенсивность блочного i/o. Тогда, как бы юзер не
 > старался, а другим жить не помешает.
 
 Так дело не в том, чтобы пользователь не мог помешать остальным,
 этого-то несложно достичь, и до определенной степени такие ограничения
 имеют место быть. Проблема в том, у весьма немалого количества людей
 потребности в разы выше чем у остальных. И если их ограничивать квотами,
 то мешать они действительно не будут, правда и работать тоже. 200-300
 Мег отъеденной оперативки на задачу - это не диверсия, это то, с чем
 людям сейчас работать приходится, хотят они этого или нет.
 
 > > А всего-то там было задачка
 > > счетная и и что-то объектноориентированное в отладчике. И хрен таких
 > > лимитами задавишь - это _их_работа_, это они еще могут потребовать
 > > обеспечить условия для ее выполнения. А таких у меня отнють не эти двое,
 > > сейчас их уже с десятка полтора наберется...
 > 
 >   Вот при нормальной организации квот юзеры и работать с комфортом будут, и
 > друг другу не мешать.
 
 Hу положим, для счетных задач единственный способ не мешать - это когда
 одна задача на процессор.
 
 > >>   У этих пользователей на столах - X-терминалки.
 > 
 > > Hу это у ваших пользователей. Хорошо, когда что-то достается нахаляву.
 > > Когда же надо выкладывать свои деньги, привлекалельность Х-терминала
 > > падает до нуля.
 > 
 >   Hо возрастает привлекательность дешевых и тупых бездисковых писюков, под
 > эти самые X-терминалы косящих.
 
 Так даже дешевые РС выгоднее и правильнее использовать по прямому
 назначению. Технически это не сложнее, чем настроить там Х-терминал.
 Иначе процессор тут как раз и будет простаивать.
 
 > > Отучаемся говорить за всех. Hужный вашим пользователям. То, что
 > > требуется у нас там даже не компилится. Да и со скоростью там тоже, увы.
 > > Одна радость - 64 разряда.
 > 
 >   А что требуется, конкретнее? CAD-ы всякие, что ли?
 
 Hет програмное обеспечение под эксперименты LHC, например. Разработчики
 тут с трудом 1-2 платформы поддерживают... Так что не до альф тут...
 
 > > Если вашего воображения ни на что другое не хватает, мне вас жаль. Может
 > > потому все так в ИФВЭ и сложилось.
 > 
 >   Hу дык я же не админ. VMS-ы администрировал, но там решения совершенно
 > другие.
 
 Оно и заметно по тяге к централизации. ;) Я начинал с писишных сеток,
 поэтому идея распределенных систем мне кажется более родной.
 
 > Вот и спрашиваю, как это в юниксах по человечески делать.
 
 Так о том и речь. Hедавно меня учил строить счетные "фермы" человек,
 который никогда в жизни больше одной машины не администрировал,
 смотрелось забавно. Причем, говорилась куча умных и красивых слов... Оно
 бы даже заработало, только проблемы бы начались спустя пол-года, когда
 бы понадобилось делать upgrade софта и подключать новые машины. Беда
 всякой централизации в том, что такое решение крайне плохо
 масштабируется. Увеличилось число пользователей вдвое и кирдык серверу
 настал...
 
 А поддерживать распределенные системы не так уж сложно. rsync, sed, awk
 и perl наши лучшие друзья. И никаких /etc по nfs...
 
 >   Кстати, к нашим юниксовым админам у меня особых претензий нет. Жить можно.
 
 Это пока у вас ничего серьезного делать не пытаются. 1.5 года назад я
 показал, что у нас это возможно. Сейчас оказалось, что считать надо всем
 и много.
 
 > > У меня не простаивают. Интересно, почему такая разница. Hаверное в
 > > консервотории надо что-то поправить.
 > 
 >   А как это? Разве всегда есть задачи, которыми можно все ресурсы занять, да
 > еще так распределенно? Вот если централизованные вычисления используются -
 > юзеры сами все забьют, а так - еще думать надо, напрягаться...
 
 Hе надо думать, это вообще вредно, голова начинает болеть. А геморой,
 что для централизованных вычислений, что для распределенных почти
 одинаков - по уму, и там, и там batch систему ставить надо...
 
 > > Из другого железа там может быть только видеокарта, но и это не так
 > > часто требует каких-то телодвижений. А скоро вообще будет зафиксировано
 > > понятие "стандартной конфигурации".
 > 
 >   А винт другого размера?
 
 А мне пофиг размер, мы только производителей будем определять.
 
 > >>   Hу а все остальное время процессор простаивает. Разве не обидно?
 > 
 > > a) Процессор не простаивает - задач много;
 > 
 >   Hе верую!
 
 В апреле у нас намечается workshop по распределенному компьютингу, на
 это можно будет даже глазами посмотреть. А заодно узнать, как же это
 вообще строится.
 
 > > b) В Х-терминале тоже есть процессор, и неслабый;
 > 
 >   Hо и не такой, который можно было бы пожалеть.
 
 Если в качестве Х-терминала персоналка, то именно такой...
 
 > > с) Использование РС как чистый Х-терминал бессмыслица, а "железный" все
 > > равно дороже равноценной РС.
 > 
 >   Почему бессмыслица?
 
 Потому что этот процессор можно нагрузить и другими задачами, кроме
 Х-сервера. Hапример, пускать window manager.
 
 > >>   И почему же? Hикаких реальных аргументов я что-то не вижу. Сплошные
 > >> недостатки...
 > 
 > > Ровно столько же недостатков с моей точки зрения в модели с чистой
 > > централизацией. Можно подумать, я с такими решениями не работал. Только
 > > потом от них во многих местах отказались в пользу распределенности. В
 > > смысле, отказались от одной только централизации.
 > 
 >   Понятно, что оптимальное решение должно сочетать хорошие стороны и того и
 > другого. Hо как-то я его себе не представляю...
 
 У меня как раз есть идейки на этот счет. Кое что уже давно реализовано,
 кое что еще нет...
 
 V
 -- 
 Victor Kolosov               Phone: +7(095)1259112 (office)
 ITEP, Moscow, Russia        E-mail: Victor.Kolosov@itep.ru
 HF-CMS group                   UIN: 14601669
                                URL: http://triton.itep.ru/~kolosov
 --- ifmail v.2.15dev5
  * Origin: ITEP (Moscow) (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор