ailev.ru

Обсуждение

В архиве: 33 комментария.

Читать и комментировать в ЖЖ ↗

Имя не сохранено · 28 июня 2009

Комментарий

Играюсь сейчас с инсталяшками OpenSolaris и FreeBSD. Они поддерживают замечательную операционную систему ZFS (Zettabyte File System). Причём, ставяться на USB стик. А в облаках проблема с применимостью. Сейчас выгоднее большой фирме делать свой кластер, а маленькой таких вычислительных мощностей не нужно. Прыгающие же нагрузки мало у кого бывают.

Имя не сохранено · 29 июня 2009

Комментарий

И при все этом я (вслед за Аланом Кеем) имею наглость утверждать, что компьютерная революция еще не началась: все помянутое обеспечение многослойно и в силу этого неэффективно дублирует друг друга, основано на допотопных процессорных и сетевых архитектурах, некомпактно из-за использования нынешних языков. Не началась. Это все клей, который связывает железо, выполненное во все той же старой парадигме. Конечно всякие хабубы/вирутализации повышают эффективность использования железа в разы, но резервы повышения на 2-3 порядка все равно есть. Для начала надо выкинуть Виндоуз (и Линукс) - сразу требования к ресурсом снизяться, и на чип можно запихать пару сотен серверов. Если еще юзать адекватные процессорные архитектуры - то тоже возможен рост на 1.5-2 порядка, например можно прикинуть по аналогии с ФПГА, на которых задача часто ускоряется в 30-100 раз (ну или те же ГПГПУ).

Имя не сохранено · 29 июня 2009

Комментарий

Прыгающие нагрузки - обычное дело. Ибо народ обычно работает в рабочее время, оно сервера и нагружает, остальное время все простаивает. Есть еще неожиданные пиковые нагрузки, которым подверженны все, у кого сервера выходят в интернет. Например у Голдман Сакса в августе 2007го нагрузка на систему выросла в 24 раза. А смерть Майкла Джексона обрушила многие сайты. Есть такой слэш-дот эффект: после публикации ссылки на slashdot.org куча народу ломилось на сервер и ложила его. Так что прыгающие нагрузки - это норма жизни. Это было понятно даже в эпоху первого интернет бума, когда все стартапы старались закупиться оборудованием, чтобы выдержать внезапный наплыв посетителей - никто не хотел оставить первое впечатление о проекте в виде неработающего сайта.

Ответ на комментарий

Имя не сохранено · 29 июня 2009

Комментарий

Посетители и покупатели - группы не во всём совпадающие. В большинстве случаев оптимизация под пиковую нагрузку не оправдана. Те, кто на слешдоте висят, висят на слешдоте. Нужны же клиенты.

Ответ на комментарий

Имя не сохранено · 29 июня 2009

Комментарий

Оправдана/не оправдана - это уже другой вопрос. Вопрос этот стоит по любому у того, кто вовлечен в глобальную экономику. А вовлечены многие, хотя бы косвенно. К примеру, проблемы с ликвидностью в 2006 году вызвали ипотечный кризис в америке в августе 2007 года, который вызвал уже глобальный кризис в сентябре 2008 года. И все с ним так или иначе столкнулись. Оптимизация под пиковую нагрузку не то что не оправдана - она невыгодна. Т.е. Голдман Сакс должен был содержать мощности не в 3 раза больше, а в 24 раза, т.е. на порядок больше. Даже Голдман Саксу это напряжно. Но все 5 крупнейших инвестбанков (плюс несколько коммерческих банков, страховых контор и проч фин институций) через год подверглись серьезному реформированию (т.е. рейдерскому захвату). В частности это было связано с тем, что в время кризиса, их execution system была парализована наплывом ордеров и они и их клиенты просто не успевали продавать акции по хорошим ценам. А это очень накладно, ибо у них позиции были взяты в кредит, и убытки у них мультиплицировались. Т.е. они на самом деле, благодаря ловким операциям с отчетностью отложили кризис на следующий год просто. Однако некоторые финансовые институты были готовы к такому повороту событий - у них были сетки, которые выдержали такой наплыв транзакций и смогли быстро раскидать их по пулам ликвидности. Понятное дело, они неплохо наварились на стрижке крупнейших инвестбанков и их клиентов. Так что я даже не знаю, оправдана была такая перестраховка или нет. Невыгодна для бизнесов в текущей перспективе - это да, а в долгосрочной - критично для жизнеспособности. Так же можно утверждать, что обществу в целом такой кризис и такое его течение не выгодно, поэтому я считаю, что если бы сети исполнения ордеров были работоспособны под такой нагрузкой, это было бы оправданно с точки зрения и общества в целом, и финансового коммьюнити. Потому как это называется предсказуемые правила игры.

Ответ на комментарий

Имя не сохранено · 29 июня 2009

Комментарий

Проблема только в том, что ни один из предлагателей облаков сейчас не готов подписать SLA. С другой стороны, если оптимизировать софт, железа понадобиться гораздо меньше. Я знаю проекты, которые на одном сервере с Перлом делали быстрее и лучше то, для чего другим фирмам нужен был маленький кластер сановских машин.

Ответ на комментарий

Имя не сохранено · 29 июня 2009

Комментарий

Ну для оптимизации софта простор несомненно широкий. У меня правило, что любой софт можно ускорить в 10 раз, а в 3-5 раз можно ускорит маленькими усилиями. Хотя кому-то удобнее Амазон облако. К примеру, если контрагент тоже в облаке, то между ними трафик будет бесплатным, чем некоторые пользуются, у тех у кого интенсивный информационный обмен. А так как активность опять же циклическая, в рабочие часы в основном, то почасовая аренда выгодна.

Ответ на комментарий

Имя не сохранено · 29 июня 2009

Комментарий

На амазоновской лекции мужик привёл знаменитую цитату Таненбаума о том, что не надо недооценивать полосу пропускания грузовика, набитого носителями. Короче, они читают себе в облако информацию, на носителе им присланную.

Ответ на комментарий

Имя не сохранено · 29 июня 2009

Комментарий

Грузовик набитый ДВДюками - это хорошо, но у него велика латентность. Иногда это важно. Я не скажу, что Амазон облако это всегда гуд, но встречал пару проектов, где оно использовалось и там это было хорошей идеей. Я и сам подумываю. К примеру, у меня есть одна идея-проект, там есть интенсивная вычислительная часть, пропорциональная юзерской нагрузке. Самому содержать ферму серваков неохота, а ускорить я конечно ускорю, но все равно считать много надо.

Ответ на комментарий

Имя не сохранено · 29 июня 2009

Комментарий

Смотрел на Амазон. По их ценам ферма серваков всё-таки проще. Тем более, что услугу хостинга без облаков предоставляют многие.

Ответ на комментарий

Имя не сохранено · 29 июня 2009

Комментарий

Хотя я и не сторонник параллельности в cloud computing важны не столько параллельные вычисления, сколько scale-free и self-healing properties, типа "загрузка кластера близка к предельной? возьмём из пула ещё сотню виртуальных машин. упал контроллер? сразу взамен поднялся на другой машине". по крайней мере, это то, на что я стараюсь акцент делать.

Имя не сохранено · 29 июня 2009

Комментарий

У меня правило, что любой софт можно ускорить в 10 раз, а в 3-5 раз можно ускорит маленькими усилиями ай, маладэц. из этого следует, кстати, что любой софт можно ускорить в бесконечное число раз маленькими усилиями.

Ответ на комментарий

Анатолий Левенчук · 29 июня 2009

Комментарий

Очень странная история. Когда-то давным-давно было выяснено, что основная причина беспорядков на фондовых рынков -- это как раз перегрузка систем исполнения сделок. И тогда Комиссия потребовала от всех трейдерских систем выдерживание семикратной нагрузки по сравнению с их средней нагрузкой. Воплей было тогда много, но все подчинились, а вскоре какой-то мелкий кризис доказал правоту Комиссии и все заткнулись. Я думал, что обязательное требование по запасу мощности систем заказа-исполнения сделок сохранилось. Странно слышать, что мощностей не хватило в этот раз.

Ответ на комментарий

Анатолий Левенчук · 29 июня 2009

Комментарий

Это революция по скорости и памяти. А я еще имею ввиду революцию и по приложениям и методам их создания.

Ответ на комментарий

Имя не сохранено · 30 июня 2009

Комментарий

Ну дык что в 24 раза больше будет транзакций, никто не ожидал. Говорят, кол-во серваков срочно удвоили и это не помогло. Кредитное плечо ведь возросло, инвестбанки наэммитировали производных в районе 10 трлн, что сравнимо с кредитной эмиссией. И потом вся эта масса в один момент стала сдуваться.

Ответ на комментарий

Имя не сохранено · 30 июня 2009

Комментарий

Не следует. Потому как кол-во переходит в качество, и сумма маленьких усилий может оказаться уже не маленькой. ЗЫ Разумеется этот мой тезис формально неверен, и легко опровергается. Только непонятно зачем его опровергать :)

Ответ на комментарий

Имя не сохранено · 30 июня 2009

Комментарий

ЗЗЫ Есть такая теорема, что любой алгоритм можно ускорить в некотором смысле (преобразовать так, чтобы делал меньше шагов асимптотически).

Ответ на комментарий

Имя не сохранено · 30 июня 2009

Комментарий

История действительно очень странная, я пока проследил до 2006 года. Тогда закончился срок правления Гринспена, появилась биржа ICE, торги нефтью на которой проходили в Лондоне, и американские трейдеры перестали отчитываться по крупным нефтянным фьючерсным позициям в CFTC. Также было два интересных события, американская аккаунтинговая комиссия велела (если не ошибаюсь в сентябре 2007го, как раз после ипотечного кризиса) всем считать активы по принципу mark-to-market (до этого был mark-to estimate), а потом снова разрешила шире применять mark-to-estimate (осенью 2008го). Также было интересно почитать Term Sheets по тем префферед стокам, которые гос-во выдавала Ситигруп. История с Мэйдоффом тоже очень интересное. Вобщем там копать и копать, материалов даже в интернете много интересных есть.

Ответ на комментарий

Имя не сохранено · 30 июня 2009

Комментарий

Тут есть синергетический эффект, кол-во переходит в качество. Если выкинуть "окошки" с сервера (а зачем на сервере окошки??), то то что останется влезет на чип несколько раз.

Ответ на комментарий