если вы так уверенны про шафлы, то посмотрите проект Apache Tez, там точно такой же pipeline задач можно сделать, распределенные hive tmp таблицы сугубо в памяти.
он за последнее время ооочень сильно вырос, пускай и тянет в основном только хортон его.
а уже если действительно хочется драйва, то Apache Flink, там и грамотный pipeline и parallel обработка
Tez и Flink позволяют строить пайплайны намного более удобные для ETL (много ETL'щиков спасибо скажут за такой функционал)
загрузили из source1, transform1, transform2, output (out1, out2, out3)
в спарке после второй трансформации нужно делать материализацию результата, чтобы потом в разные out скормить, если у вас большие объемы, то это гарантированно упадет на диск. у flink в разы более грамотная работа с памятью и тд.
В итоге когда дело касается веры, то я немцам в таких вещах больше верю ;)
spark — сделали прототип, шумиха пошла, докидываем на лету на map-reduce дополнительные модули (хотя к архитектуре вопросов более чем у меня), чисто американский подход
flink — провели исследования, вопросы оптимизации и runtime подстройки задач на основе статистики, начали делать прототипы и продукт, в общем классический немецкий подход
2) ок, hive это mpp dbms, так как там уже даже mvcc прикрутили
3) к тому что это все сделано поверх shuffle примитивов
5) резон один — набрать побольше клиентов на саппорт. и давайте не будем про уровень людей, для этого достаточно открыть репозитории и посмотреть на срач в нем в spark, если вы про «профессоров», то хочу вас расстроить, количество грантов на разработку выданных при развитии хадупа тоже не один десяток ушло в универы и написаны/защищены достаточно работ по оптимизациям.
в общем не вижу смысла продолжать спор, так как мы сейчас в разной плоскости: я — «как сейчас сделано и работает», вы — «как МОЖНО сделать или в будущем возможно сделают». само плохое когда люди начинают вместо реальной ситуации и положении дел в продукте рассказывают об их идеальном видении как это можно сделать.
1) насколько помню даже и не собирались =) в момент выхода второго хадупа, спарк еще был в настолько сырой бете…
может вы перепутали с «Spark on Pivotal Hadoop 2.0» или с HDP 2.0 от hortonworks, но это всего лишь сборки конкретных дистрибутивов с полностью независимой от hadoop нумерацией
2) поддержка нескольких партиций и параллельная их обработка не делает из спарка «массивно-параллельной СУБД», с таким же успехом будет тоже «массивно-параллельной СУБД». реляционной алгебры — update и транзакционность уже прикрутили?
3) «если бы, да кабы»,
на данный момент в случае отсортированности какой либо таблицы, мы к ней делаем join, предварительно сортируя вторую
если отсортированы обе, то в любом случае со второй дергаем репартишинг, так как диапазоны ключей конечно же разные
выполнение repartition выкинет в обязательном порядке все данные на диск (в офф документации я что-то не заметил упоминания этого факта, благо хоть cloudera не молчит: The MapReduce and Spark shuffles use a “pull” model. Every map task writes out data to local disk, and then the reduce tasks make remote requests to fetch that data. А то на слайдах у датабрикса все так красиво)
MergeJoin operator relies on SortBasedShuffle to create partitions that sorted by the join key, так что магии не будет, все расходимся
4) ну за 3 месяца многое поменялось, меньше месяца назад они заявляли про spark sql как основная цель и catalist как движок для запиливания оптимизаций. можно даже пройти на офф сайт http://shark.cs.berkeley.edu/ «Shark has been subsumed by Spark SQL, a new module in Apache Spark. Please see the following blog post for more information: Shark, Spark SQL, Hive on Spark, and the future of SQL on Spark.» ;)
5) читал и использовал.
Ничем accumulators от таких в хадупе не отличаются (локальная работа в пределах партиции и сброс на агрегацию в драйвер. Tasks running on the cluster can then add to it using the add method or the += operator (in Scala and Python). However, they cannot read its value).
Broadcast Variables вообще сугубо read only и неизменяемы, раз разослали и все.
p.s. активно пользовался хадупом, когда он еще 0.18 был, за спарком тоже слежу почти с самого его начала, но пока вижу пиара вокруг него больше, чем он реально может. я согласен с тем, что продукт дальше развивает подход с параллельной обработкой данных, которые пнул гугл и дальше подхватил hadoop, но не согласен с уровнем маркетинга вокруг него.
1) он стал частью Hadoop 2.0.
а можно узнать где и когда? хадуп 2.0 уже давно вышел, 3.0 на подходе, и спарк там никаким боком не светится
2) Spark можно описать одной фразой так — это внутренности движка массивно-параллельной СУБД
не правда, если уж и описывать одной фразой, то это: ленивая обработка вычислений и pipeline map фаз
выполнять параллельно несколько задач он не умеет, в dag последовательно проходят все агрерирующие операции, если нужно действительно параллельность, то или ручками в Tez углубляться и строить DAG, или смотреть проект Apache Flink у них на слайдах это хорошо показано.
3) groupBy
у этого оператора, как и всех операторов использующих ShuffleMapTask есть большая проблема: они ВСЕГДА пишут результат на диск, независимо от того кешируете вы результат в памяти или нет, следующие в списке забирают результат по http. поэтому слова на их слайды про in-memory немного приувеличения =) разница в обмене между map и reduce у них с хадупом почти нулевая.
4) а также AMP LAB (лаборатория, откуда вырос Spark) не собирается отказывать и от проекта Shark — полное замещение Apache HIVE
опять мимо, на шарк уже все забили, amp lab все что полезное вытянули в spark sql, то что осталось отправилось на свалку. что действительно пилят, так это hive on spark, совместные усилия клоудеры и amp lab по реализации еще одного бекенда для hive (на данный момент есть mr и tez), но с полной совместимостью hive sql
5) не только средствами RDD, но и дополнительными примитивами
можно подробней? так как там все построено поверх RDD, это главный примитив в самом спарке, по сути key-value, а уже поверх него строится все остальное
тут несколько нюансов возникает (где-то с год назад смотрел почему так много cpu выедается):
1) шифрование (луковая архитектура заставляет хорошенько погреть воздух, да и памяти кушает порядочно в режиме router именно он)
2) SSU (он же udp, очень часто замечал что выступает в приоритете), так как он любит порождать на по потоку на соединение, а отсюда и context switch вылазит и wait на сокетах. NTCP уже nio и от многих проблем избавлен, но он уже tcp.
в связке этих 2 пункта дают как неплохое потребление памяти (буфера на чтение-запись, шифрование, стек под каждый новый поток-соединение) и cpu (context switch, постоянное шифрование),
так что получаем:
1) режем скорость и количество соединений — работаем шустро
2) даем много ресурсов — проц захлебывается, поедание памяти и то не настолько заметно даже становится
я же не против, пускай будет платная подписка и тд.
просто меня эта шумиха напрягает, типо подсадите команду, посмотрите какие мы клевые, а в момент когда упираешься оказывается, что никаких api чтобы вытянуть переписку нету, в итоге и соскочить с ходу не получается.
туда же: обратите внимание на снимок, в gen2 данных немного, в gen1 еще меньше, основные объемы в gen0 которые только что выделились и их сейчас собирают.
Возникает вопрос: почему сборка проходит недостаточно быстро?
p.s. раз уже затронули тему latency, то сколько примерно времени уходит на сборку хипа в 10GB, так как .net под рукой нету, а мерять в virtualbox это немного не то, то хотелось бы получить данные близкие к первоисточнику.
уточню, время смотрелось по профайлеру, где мы находились в тот момент.
отдельно метрики снимались сколько провели в gc, так как видно что тригерился он очень часто, пускай и на мелкие промежутки в 3-4ms.
один из багов конкатенация строк в цикле (oldString = oldString + suffixN), так как строки immutable, и ближе к концу цикла достигали 80+ мебабайт, то только и делали что ждали копирования.
но даже в этом случае gc пыхтел, но справлялся
>> Во-первых 15 секунд это не время GC, а время, когда приложение работает
в данном случае как раз простейших 30 сесий вызывало тригеринг gc, не зря на большинстве снимков сам автор указал, что система находилась в состоянии сборки мусора.
>> Во вторых gc тут совершенно не при чем.
позволю себе процитировать:
А именно:
* На момент сборки дампов Garbage Collector был запущен (поначалу я не придал этому внимания);
* Очень большой размер кучи;
* Все 4 потока принадлежат Garbage Collector и съедают 100% CPU.
что позволяет сделать вывод, что уже к этому моменту 15с находимся в gc
>> Если в тесный цикл попадет аллокация, то тут инлайнинг уже не поможет, потенциальная сборка мусора перекроет все преимущества инлайнинга.
алокация проходит очень быстро, так как буфер у каждого потока собственный, а значит это просто инкремент счетчика указывающего на вершину области памяти (это одинаково верно и для .net и для jvm)
>> всегда занимался уменьшением аллокаций, это позволяло в разы ускорить приложение
что еще раз указывает, на узкое место в виде gc, n% еще бывыло, но редко когда это число достигало двухзначных цифр, трехзначных не припомню вообще.
>> При таких объемах у ТС вообще не было бы проблем. У него весь объем памяти меньше вашего Gen0.
и как бы это ему помогло? собирать больший объем памяти? расшифруйте пожалуйста.
>> Попробуйте в любом приложении на любом языке в секунду выделять по 500 мб, будет тот же эффект. Даже в языке без GC.
intellij idea, есть пару багов, алокация за минуту 80-120ГБ памяти (размер в секунду свыше гигабайта), за минуту суммарное время в gc 6s, основное время на копирование кусков памяти с одной точки в другу (просадка на memcpy)
20% это не мало, особенно когда инлайн может оказаться вложенным и тд. Но инлайн это лишь один из многих вариантов, где можно подтянуть скорость.
Для высоконагруженных, но не lowlatency, систем между 10% производительности от инлайнинга и увеличением сборки мусора в 2 раза я выберу производительность в случае если эти сборки случаются раз в минуту и длятся 1с, так как на паузе я потеряю лишнюю секунду, но за счет лучшего кода выиграю 6, итого суммарный счет 5с профита. Именно поэтому многие для lowlatency систем на средних размерах хипа в jvm продолжают использовать CMS и не переключаются на G1, так как уровень оптимизации кода и инлайнинг у cms на данный момент выше, так как нету дополнительных барьеров памяти необходимых для гарантии корректности при паралельной сборке регионов.
А данный пост показывает лишь то, что перед выпуском приложения не проводилось какое-либо нагрузочное тестирование, так как 30 сесий способные положить сайт с хипом свыше гига это немного странно. Большие паузы на gc и suspend всех потоков не показывают ничего, кроме того, что сборка мусора в версии .net у автора не умеет работать в фоне, а для сборки стопает все (ниже уже был совет обновить версию рантайма, но текущее поведение вызывает лишь улыбку).
«порог — 80%, продолжительностью — 15 секунд» — извиняюсь, но 15 секунд собирать мусор это МНОГО, что еще раз говорит, о плохом gc, автор статьи же говорит о «не более 1 минуты, но с очень большой частотой». в данном случае конечно ваши слова про алокацию имеют смысл, так как любая сборка это неплохой такой downtime, до этого я считал что даже 10GB heap вы собираете в течении 5-10c, что тоже много, но не так критично.
p.s. почему я говорю много (если говорить в терминах .net): наше приложение с gen0 поколением в 6G суммарно паузы меньше 0.140c раз в 20-30с и gen2 в 20+G (с учетом gen0 и gen1 суммарно 32GB) меньше 1с и вызовом 2 раза в сутки. онлайн 2к+ пользователей и данные паузы нам и то не очень нравятся, но пока это менее критичная проблема чем функционал =) поэтому читая про минуту и не видя удивления у окружающих у меня и возник небольшой диссонанс.
>> так и джависты верят, что встроенные оптимизации сработают лучше, чем ручное уменьшение аллокаций
ну я не говорю, что ручное уменьшение делать не нужно, а лишь к тому, что я сам видел насколько хорошо работают данные методики ;) против лома с кривым кодом алоцирующего гигабайты сильно не попрешь (видел и такие). поэтому что-то руками, но только после того как мы видим, что действительно где-то есть проблемы, а не задумываемся на этапе разработки, где бы нам лучше алоцировать объект. Слишком часто .net алокацию на стеке приводят как панацею и решение всех бед.
>> Девиртуализация вызовов есть, но простейшая
она работает только для sealed классов, так как в .net нет такого понятия как «деоптимизация метода и повторное перепрофилирование», а по поводу «большинство вызовов невиртуальные» я бы поспорил, так как имея на входе в метод интерфейс, на этапе компиляции метода при первом вызове (а именно так jit у .net работает) мы не знаем кто может туда попасть. имея профайл мы можем произвести девиртуализацию и если уже ошиблись, то тогда откатываем её и отправляем на повторное профилирование.
>> в .NET есть профайлинг, но работает не так как в java
это уже не совсем online профайлинг, а больше стандартный c/c++ подход, когда собираем статистику и на следующем запуске пытаемся её использовать. Но с данным подходом есть проблема: например у нас рестарты бывают только с выходом новой версии, в итоге собранный профиль является уже устаревшим.
>> MPGO
в ту же степь, иметь AOT компиляцию это конечно хорошо, но не во всех случаях у нас имеется возможность делать рестарт, только ради того чтобы подхватить этот профиль. AOT хорошо себя зарекомендовал на десктопах, куда его и позиционируют.
>> Multi-core background jit
ну иметь один блокирующий jit поток на многоядерной архитектуре само по себе нонсенс
>> Но основная цель — уменьшение времени загрузки, а не увеличение скорости работы
вот в этом мы и отличаемся =) в java более медленный старт и обусловлен, что главная цель это быстрая работа в долгоживущих серверных приложениях, а не коротких десктопных.
p.s. люблю конструктивные споры, столько линков новых получаешь =)
>> В .NET есть структуры, которые размещаются на стеке и позволяют вообще не создавать мусор без необходимости.
как позже заметили есть EscapeAnalysis который может убрать лишнюю алокацию. но да, гибкости на уровне языка у .net больше, рантайм у jvm больше работы делает, так что паритет в этом плане.
>> У Java даже Integer это ссылочный тип, размещаемый в куче
в общем случае да, но во многих местах тот же EscapeAnalysis и последующий EliminateAutoBox неплохо спасает
>> А в .NET все реализации энумераторов это структуры, и foreach (аналог for\in) не вызывает аллокаций.
энумы во многих местах это просто константы, foreach тоже после EscapeAnalysis удаляет создание итераторов, так что можно считать, что в большинстве случаем не имеем дополнительной алокации
>> С другой стороны в JVM есть HotSpot, который оптимизирует самые медленные куски кода (возможно и за счет размещения объектов на стеке)
HotSpot это всего-лишь одна из реализаций и оптимизация кода не связана с алокацией. В явном виде размещения объекта на стеке невозможно, если дергается new и конструктор, то точно хип, но если EscapeAnalysis уверен, что объект не убегат, то он может произвести взрыв объекта и от него останется лишь набор внутренних полей разбросанных по стеку и регистрам (сказать что у нас получится в конкретном куске кода я не пытаюсь, можно предположить по анализу потребления памяти или посмотрев ассемблерный код для данного метода).
>> В jvm есть jit, но насколько я помню он и в net vm есть)
есть, но в намного более простом варианте, поддерка профайлинга отсутствует, девиртуализация вызовов тоже, в итоге инлайнинг что и есть, то зачастую только некоторых невиртуальных методов (в java все методы виртуальные, поэтому девиртуализация жизненно необходима для хорошей производительности, в дотнете это не так, тут больше похоже на c++). плюсом можно назвать более быстрый прогрев и переход на машинный код, что критично для десктоп приложений.
>> В java 9 обещают некий аналог struct )
обещанные value types на практике не совсем аналог структур, так как они будут immutable, с mutable можно отгребсти пачку веселья. а вот generic на примитивных типах для локальности данных тоже интересны и уже есть частично сделаны, но это уже в 10 стоит как target.
p.s. спасибо за ссылки msdt на gc, хоть и не до конца, но примерно разобрался со сборщиком вашим, так как везде уж в слишком гуманитарном виде это описывается, в msdn хоть timeline присутствует.
p.p.s. я отношусь к тем java разработчикам, которые только рады открытию .net =) так как хоть можно будет посмотреть, как же у вас работает, а не пытаться собирать со слухов крупицы данных.
тогда, не для холивара, а действительно интересно: многие дотнетчики в общении указывают, что сборщик в .net работает в разы лучше чем в java, но в разговоре оказывалось, что все примерно знали как работает в .net и никто не знал как в jvm, может вы сможете базовое сравнение привести?
p.s. да, я знаю легенду о том, что в .net сборщик сразу написали на лиспе, прогнали пачку теорий и эвристики, а уже потом переписали на «правильный» язык. но из того что вижу даже нормальный cms появился только с версии 4.5, хотя лично я считал что он имеется чуть ли не с рождения.
я может и ошибаюсь, но под memory leaks подразумевают утечки памяти, а не избыточную алокацию.
для избыточной алокации в том же jetbrains используют термин «memory traffic», в java я не знаю устоявшегося термина, обычно использую «избыточное выделение».
>> В .net 4.0, когда запускается сборка мусора, всем потокам GC присваивается максимальный приоритет. Это означает, что все ресурсы сервера будут направлены на сборку мусора и, помимо этого, все остальные потоки (обрабатывающие входящие запросы) будут временно приостановлены до момента, пока сборка мусора не закончится.
то есть вроде как и параллельная, но на практике последовательная сборка? тогда не понимаю, почему сборщик в .net так люто все плюсуют, если он не обеспечивает нормальной работы без больших провалов (извиняюсь за вопрос, так как сам на java специализируюсь)
так же не понял про поколения и пример с выделением: примеры, что вы привели с выделением памяти дальше Gen0 не должны были уйти, в крайнем случае Gen1, как же оно доживало до Gen2? там же подняли, посмотрели, дерево можно освободить.
а теперь ближе к теме:
1) В Полоцке сильная школа: преподаватели ПГУ набирают команды для коммерческих проектов уже из третьекурсников и делают с ними софт под заказ для США и Израиля
Угу, впервые слышу, хотя сам заканчивал данный университет в 2008 с дипломом инженер-программист. Да и про школу я бы поспорил, было несколько хороших преподавателей из молодых, многие уже уволились.
2) Работать в EPAM престижно, и один наш знакомый ушел туда из небольшой компании на меньшую зарплату, но более интересные проекты
Может дело и не в престиже, а в том что сидеть без развития это бесперспективно, особенно в IT и уходят в первую очередь ради проектов? Да и можете развернуть подробней историю знакомого, а то часто оказывается, что после перехода очень быстро начинают получать даже больше, чем имели на предыдущем месте.
3) но все при деле, безработных программистов мы не встречали
Что-то я вообще не встречал безработных программистов, неважно это Витебск, Минск или Киев, таковы реалии рынка. Но стоит добавить, что большинство по мере роста и развития уезжают как минимум в Минск, а как максимум за бугор.
4) при этом 3G, как нам кажется, работает быстрее чем в Москве
В Москве уже LTE отключили или это в Витебске его подключили? =) а то вроде в РБ он не сильно наблюдается
5) Здесь стараются не греметь без надобности
Это наш обычный белорусский менталитет, как и везде. Вот только с такими негремящими периодически знакомится налоговая.
6) В общем, Витебск один из крупнейших белорусских центров IT-аутсорсинга
Про относительные цифры думаю спрашивать не стоит?
У меня немного другой вопрос: ожидается ли вынос работы некоторых модулей из AWT-EventQueue?
очень много вещей работают по принципу: создали runnable и скормили в dispatchEvent.
да, я понимаю что так проще, но в итоге подвисание одного runnable на ресурсоемкой операции останавливает отрисовку всего ui, причем нельзя нажать cancel или abort, так как события от клавиш становятся в очередь и поэтому будут обработаны только после завершения текущей задачи.
p.s. несколько примеров:
1) открываем File -> Project Structure. если у нас много Problems, то из-за неаккуратного кодирования (конкатенация строк в цикле через +), строка формируется очень долго, вплоть до подвисания ui (решается только через kill процесса). баг заведен
2) save на большом проекте, ProjectImpl.save() который в конце концов начинает усиленно дергать ReplacePathToMacroMap.substitute() у меня подвешивает совсем не на одну секунду.
p.p.s. и да =) я лучше понаблюдаю нагрузку 1 минуту на все ядра, чем буду ждать 5 минут пока оно на одном ядре перемелет все
EVE Online =) если бы не часовые простои раз в сутки, то умерших за компом было бы в разы больше
он за последнее время ооочень сильно вырос, пускай и тянет в основном только хортон его.
а уже если действительно хочется драйва, то Apache Flink, там и грамотный pipeline и parallel обработка
Tez и Flink позволяют строить пайплайны намного более удобные для ETL (много ETL'щиков спасибо скажут за такой функционал)
загрузили из source1, transform1, transform2, output (out1, out2, out3)
в спарке после второй трансформации нужно делать материализацию результата, чтобы потом в разные out скормить, если у вас большие объемы, то это гарантированно упадет на диск. у flink в разы более грамотная работа с памятью и тд.
В итоге когда дело касается веры, то я немцам в таких вещах больше верю ;)
spark — сделали прототип, шумиха пошла, докидываем на лету на map-reduce дополнительные модули (хотя к архитектуре вопросов более чем у меня), чисто американский подход
flink — провели исследования, вопросы оптимизации и runtime подстройки задач на основе статистики, начали делать прототипы и продукт, в общем классический немецкий подход
кто выживет покажет время
3) к тому что это все сделано поверх shuffle примитивов
5) резон один — набрать побольше клиентов на саппорт. и давайте не будем про уровень людей, для этого достаточно открыть репозитории и посмотреть на срач в нем в spark, если вы про «профессоров», то хочу вас расстроить, количество грантов на разработку выданных при развитии хадупа тоже не один десяток ушло в универы и написаны/защищены достаточно работ по оптимизациям.
в общем не вижу смысла продолжать спор, так как мы сейчас в разной плоскости: я — «как сейчас сделано и работает», вы — «как МОЖНО сделать или в будущем возможно сделают». само плохое когда люди начинают вместо реальной ситуации и положении дел в продукте рассказывают об их идеальном видении как это можно сделать.
может вы перепутали с «Spark on Pivotal Hadoop 2.0» или с HDP 2.0 от hortonworks, но это всего лишь сборки конкретных дистрибутивов с полностью независимой от hadoop нумерацией
2) поддержка нескольких партиций и параллельная их обработка не делает из спарка «массивно-параллельной СУБД», с таким же успехом будет тоже «массивно-параллельной СУБД». реляционной алгебры — update и транзакционность уже прикрутили?
3) «если бы, да кабы»,
на данный момент в случае отсортированности какой либо таблицы, мы к ней делаем join, предварительно сортируя вторую
если отсортированы обе, то в любом случае со второй дергаем репартишинг, так как диапазоны ключей конечно же разные
выполнение repartition выкинет в обязательном порядке все данные на диск (в офф документации я что-то не заметил упоминания этого факта, благо хоть cloudera не молчит: The MapReduce and Spark shuffles use a “pull” model. Every map task writes out data to local disk, and then the reduce tasks make remote requests to fetch that data. А то на слайдах у датабрикса все так красиво)
MergeJoin operator relies on SortBasedShuffle to create partitions that sorted by the join key, так что магии не будет, все расходимся
4) ну за 3 месяца многое поменялось, меньше месяца назад они заявляли про spark sql как основная цель и catalist как движок для запиливания оптимизаций. можно даже пройти на офф сайт http://shark.cs.berkeley.edu/ «Shark has been subsumed by Spark SQL, a new module in Apache Spark. Please see the following blog post for more information: Shark, Spark SQL, Hive on Spark, and the future of SQL on Spark.» ;)
5) читал и использовал.
Ничем accumulators от таких в хадупе не отличаются (локальная работа в пределах партиции и сброс на агрегацию в драйвер. Tasks running on the cluster can then add to it using the add method or the += operator (in Scala and Python). However, they cannot read its value).
Broadcast Variables вообще сугубо read only и неизменяемы, раз разослали и все.
p.s. активно пользовался хадупом, когда он еще 0.18 был, за спарком тоже слежу почти с самого его начала, но пока вижу пиара вокруг него больше, чем он реально может. я согласен с тем, что продукт дальше развивает подход с параллельной обработкой данных, которые пнул гугл и дальше подхватил hadoop, но не согласен с уровнем маркетинга вокруг него.
1) он стал частью Hadoop 2.0.
а можно узнать где и когда? хадуп 2.0 уже давно вышел, 3.0 на подходе, и спарк там никаким боком не светится
2) Spark можно описать одной фразой так — это внутренности движка массивно-параллельной СУБД
не правда, если уж и описывать одной фразой, то это: ленивая обработка вычислений и pipeline map фаз
выполнять параллельно несколько задач он не умеет, в dag последовательно проходят все агрерирующие операции, если нужно действительно параллельность, то или ручками в Tez углубляться и строить DAG, или смотреть проект Apache Flink у них на слайдах это хорошо показано.
3) groupBy
у этого оператора, как и всех операторов использующих ShuffleMapTask есть большая проблема: они ВСЕГДА пишут результат на диск, независимо от того кешируете вы результат в памяти или нет, следующие в списке забирают результат по http. поэтому слова на их слайды про in-memory немного приувеличения =) разница в обмене между map и reduce у них с хадупом почти нулевая.
4) а также AMP LAB (лаборатория, откуда вырос Spark) не собирается отказывать и от проекта Shark — полное замещение Apache HIVE
опять мимо, на шарк уже все забили, amp lab все что полезное вытянули в spark sql, то что осталось отправилось на свалку. что действительно пилят, так это hive on spark, совместные усилия клоудеры и amp lab по реализации еще одного бекенда для hive (на данный момент есть mr и tez), но с полной совместимостью hive sql
5) не только средствами RDD, но и дополнительными примитивами
можно подробней? так как там все построено поверх RDD, это главный примитив в самом спарке, по сути key-value, а уже поверх него строится все остальное
ну как-то так, если совсем кратко =)
1) шифрование (луковая архитектура заставляет хорошенько погреть воздух, да и памяти кушает порядочно в режиме router именно он)
2) SSU (он же udp, очень часто замечал что выступает в приоритете), так как он любит порождать на по потоку на соединение, а отсюда и context switch вылазит и wait на сокетах. NTCP уже nio и от многих проблем избавлен, но он уже tcp.
в связке этих 2 пункта дают как неплохое потребление памяти (буфера на чтение-запись, шифрование, стек под каждый новый поток-соединение) и cpu (context switch, постоянное шифрование),
так что получаем:
1) режем скорость и количество соединений — работаем шустро
2) даем много ресурсов — проц захлебывается, поедание памяти и то не настолько заметно даже становится
просто меня эта шумиха напрягает, типо подсадите команду, посмотрите какие мы клевые, а в момент когда упираешься оказывается, что никаких api чтобы вытянуть переписку нету, в итоге и соскочить с ходу не получается.
не против продукта, но объяснить бухгалтерии зачем за чат платить 7$/месяц/человека уже сложнее.
Возникает вопрос: почему сборка проходит недостаточно быстро?
p.s. раз уже затронули тему latency, то сколько примерно времени уходит на сборку хипа в 10GB, так как .net под рукой нету, а мерять в virtualbox это немного не то, то хотелось бы получить данные близкие к первоисточнику.
отдельно метрики снимались сколько провели в gc, так как видно что тригерился он очень часто, пускай и на мелкие промежутки в 3-4ms.
один из багов конкатенация строк в цикле (oldString = oldString + suffixN), так как строки immutable, и ближе к концу цикла достигали 80+ мебабайт, то только и делали что ждали копирования.
но даже в этом случае gc пыхтел, но справлялся
в данном случае как раз простейших 30 сесий вызывало тригеринг gc, не зря на большинстве снимков сам автор указал, что система находилась в состоянии сборки мусора.
>> Во вторых gc тут совершенно не при чем.
позволю себе процитировать:
что позволяет сделать вывод, что уже к этому моменту 15с находимся в gc
>> Если в тесный цикл попадет аллокация, то тут инлайнинг уже не поможет, потенциальная сборка мусора перекроет все преимущества инлайнинга.
алокация проходит очень быстро, так как буфер у каждого потока собственный, а значит это просто инкремент счетчика указывающего на вершину области памяти (это одинаково верно и для .net и для jvm)
>> всегда занимался уменьшением аллокаций, это позволяло в разы ускорить приложение
что еще раз указывает, на узкое место в виде gc, n% еще бывыло, но редко когда это число достигало двухзначных цифр, трехзначных не припомню вообще.
>> При таких объемах у ТС вообще не было бы проблем. У него весь объем памяти меньше вашего Gen0.
и как бы это ему помогло? собирать больший объем памяти? расшифруйте пожалуйста.
>> Попробуйте в любом приложении на любом языке в секунду выделять по 500 мб, будет тот же эффект. Даже в языке без GC.
intellij idea, есть пару багов, алокация за минуту 80-120ГБ памяти (размер в секунду свыше гигабайта), за минуту суммарное время в gc 6s, основное время на копирование кусков памяти с одной точки в другу (просадка на memcpy)
Для высоконагруженных, но не lowlatency, систем между 10% производительности от инлайнинга и увеличением сборки мусора в 2 раза я выберу производительность в случае если эти сборки случаются раз в минуту и длятся 1с, так как на паузе я потеряю лишнюю секунду, но за счет лучшего кода выиграю 6, итого суммарный счет 5с профита. Именно поэтому многие для lowlatency систем на средних размерах хипа в jvm продолжают использовать CMS и не переключаются на G1, так как уровень оптимизации кода и инлайнинг у cms на данный момент выше, так как нету дополнительных барьеров памяти необходимых для гарантии корректности при паралельной сборке регионов.
А данный пост показывает лишь то, что перед выпуском приложения не проводилось какое-либо нагрузочное тестирование, так как 30 сесий способные положить сайт с хипом свыше гига это немного странно. Большие паузы на gc и suspend всех потоков не показывают ничего, кроме того, что сборка мусора в версии .net у автора не умеет работать в фоне, а для сборки стопает все (ниже уже был совет обновить версию рантайма, но текущее поведение вызывает лишь улыбку).
«порог — 80%, продолжительностью — 15 секунд» — извиняюсь, но 15 секунд собирать мусор это МНОГО, что еще раз говорит, о плохом gc, автор статьи же говорит о «не более 1 минуты, но с очень большой частотой». в данном случае конечно ваши слова про алокацию имеют смысл, так как любая сборка это неплохой такой downtime, до этого я считал что даже 10GB heap вы собираете в течении 5-10c, что тоже много, но не так критично.
p.s. почему я говорю много (если говорить в терминах .net): наше приложение с gen0 поколением в 6G суммарно паузы меньше 0.140c раз в 20-30с и gen2 в 20+G (с учетом gen0 и gen1 суммарно 32GB) меньше 1с и вызовом 2 раза в сутки. онлайн 2к+ пользователей и данные паузы нам и то не очень нравятся, но пока это менее критичная проблема чем функционал =) поэтому читая про минуту и не видя удивления у окружающих у меня и возник небольшой диссонанс.
ну я не говорю, что ручное уменьшение делать не нужно, а лишь к тому, что я сам видел насколько хорошо работают данные методики ;) против лома с кривым кодом алоцирующего гигабайты сильно не попрешь (видел и такие). поэтому что-то руками, но только после того как мы видим, что действительно где-то есть проблемы, а не задумываемся на этапе разработки, где бы нам лучше алоцировать объект. Слишком часто .net алокацию на стеке приводят как панацею и решение всех бед.
>> Девиртуализация вызовов есть, но простейшая
она работает только для sealed классов, так как в .net нет такого понятия как «деоптимизация метода и повторное перепрофилирование», а по поводу «большинство вызовов невиртуальные» я бы поспорил, так как имея на входе в метод интерфейс, на этапе компиляции метода при первом вызове (а именно так jit у .net работает) мы не знаем кто может туда попасть. имея профайл мы можем произвести девиртуализацию и если уже ошиблись, то тогда откатываем её и отправляем на повторное профилирование.
>> в .NET есть профайлинг, но работает не так как в java
это уже не совсем online профайлинг, а больше стандартный c/c++ подход, когда собираем статистику и на следующем запуске пытаемся её использовать. Но с данным подходом есть проблема: например у нас рестарты бывают только с выходом новой версии, в итоге собранный профиль является уже устаревшим.
>> MPGO
в ту же степь, иметь AOT компиляцию это конечно хорошо, но не во всех случаях у нас имеется возможность делать рестарт, только ради того чтобы подхватить этот профиль. AOT хорошо себя зарекомендовал на десктопах, куда его и позиционируют.
>> Multi-core background jit
ну иметь один блокирующий jit поток на многоядерной архитектуре само по себе нонсенс
>> Но основная цель — уменьшение времени загрузки, а не увеличение скорости работы
вот в этом мы и отличаемся =) в java более медленный старт и обусловлен, что главная цель это быстрая работа в долгоживущих серверных приложениях, а не коротких десктопных.
p.s. люблю конструктивные споры, столько линков новых получаешь =)
>> В .NET есть структуры, которые размещаются на стеке и позволяют вообще не создавать мусор без необходимости.
как позже заметили есть EscapeAnalysis который может убрать лишнюю алокацию. но да, гибкости на уровне языка у .net больше, рантайм у jvm больше работы делает, так что паритет в этом плане.
>> У Java даже Integer это ссылочный тип, размещаемый в куче
в общем случае да, но во многих местах тот же EscapeAnalysis и последующий EliminateAutoBox неплохо спасает
>> А в .NET все реализации энумераторов это структуры, и foreach (аналог for\in) не вызывает аллокаций.
энумы во многих местах это просто константы, foreach тоже после EscapeAnalysis удаляет создание итераторов, так что можно считать, что в большинстве случаем не имеем дополнительной алокации
>> С другой стороны в JVM есть HotSpot, который оптимизирует самые медленные куски кода (возможно и за счет размещения объектов на стеке)
HotSpot это всего-лишь одна из реализаций и оптимизация кода не связана с алокацией. В явном виде размещения объекта на стеке невозможно, если дергается new и конструктор, то точно хип, но если EscapeAnalysis уверен, что объект не убегат, то он может произвести взрыв объекта и от него останется лишь набор внутренних полей разбросанных по стеку и регистрам (сказать что у нас получится в конкретном куске кода я не пытаюсь, можно предположить по анализу потребления памяти или посмотрев ассемблерный код для данного метода).
>> В jvm есть jit, но насколько я помню он и в net vm есть)
есть, но в намного более простом варианте, поддерка профайлинга отсутствует, девиртуализация вызовов тоже, в итоге инлайнинг что и есть, то зачастую только некоторых невиртуальных методов (в java все методы виртуальные, поэтому девиртуализация жизненно необходима для хорошей производительности, в дотнете это не так, тут больше похоже на c++). плюсом можно назвать более быстрый прогрев и переход на машинный код, что критично для десктоп приложений.
>> В java 9 обещают некий аналог struct )
обещанные value types на практике не совсем аналог структур, так как они будут immutable, с mutable можно отгребсти пачку веселья. а вот generic на примитивных типах для локальности данных тоже интересны и уже есть частично сделаны, но это уже в 10 стоит как target.
p.s. спасибо за ссылки msdt на gc, хоть и не до конца, но примерно разобрался со сборщиком вашим, так как везде уж в слишком гуманитарном виде это описывается, в msdn хоть timeline присутствует.
p.p.s. я отношусь к тем java разработчикам, которые только рады открытию .net =) так как хоть можно будет посмотреть, как же у вас работает, а не пытаться собирать со слухов крупицы данных.
p.s. да, я знаю легенду о том, что в .net сборщик сразу написали на лиспе, прогнали пачку теорий и эвристики, а уже потом переписали на «правильный» язык. но из того что вижу даже нормальный cms появился только с версии 4.5, хотя лично я считал что он имеется чуть ли не с рождения.
так как если судить по скринам, то в gen1 у автора ничего сильно не висит.
для избыточной алокации в том же jetbrains используют термин «memory traffic», в java я не знаю устоявшегося термина, обычно использую «избыточное выделение».
>> В .net 4.0, когда запускается сборка мусора, всем потокам GC присваивается максимальный приоритет. Это означает, что все ресурсы сервера будут направлены на сборку мусора и, помимо этого, все остальные потоки (обрабатывающие входящие запросы) будут временно приостановлены до момента, пока сборка мусора не закончится.
то есть вроде как и параллельная, но на практике последовательная сборка? тогда не понимаю, почему сборщик в .net так люто все плюсуют, если он не обеспечивает нормальной работы без больших провалов (извиняюсь за вопрос, так как сам на java специализируюсь)
так же не понял про поколения и пример с выделением: примеры, что вы привели с выделением памяти дальше Gen0 не должны были уйти, в крайнем случае Gen1, как же оно доживало до Gen2? там же подняли, посмотрели, дерево можно освободить.
а теперь ближе к теме:
1) В Полоцке сильная школа: преподаватели ПГУ набирают команды для коммерческих проектов уже из третьекурсников и делают с ними софт под заказ для США и Израиля
Угу, впервые слышу, хотя сам заканчивал данный университет в 2008 с дипломом инженер-программист. Да и про школу я бы поспорил, было несколько хороших преподавателей из молодых, многие уже уволились.
2) Работать в EPAM престижно, и один наш знакомый ушел туда из небольшой компании на меньшую зарплату, но более интересные проекты
Может дело и не в престиже, а в том что сидеть без развития это бесперспективно, особенно в IT и уходят в первую очередь ради проектов? Да и можете развернуть подробней историю знакомого, а то часто оказывается, что после перехода очень быстро начинают получать даже больше, чем имели на предыдущем месте.
3) но все при деле, безработных программистов мы не встречали
Что-то я вообще не встречал безработных программистов, неважно это Витебск, Минск или Киев, таковы реалии рынка. Но стоит добавить, что большинство по мере роста и развития уезжают как минимум в Минск, а как максимум за бугор.
4) при этом 3G, как нам кажется, работает быстрее чем в Москве
В Москве уже LTE отключили или это в Витебске его подключили? =) а то вроде в РБ он не сильно наблюдается
5) Здесь стараются не греметь без надобности
Это наш обычный белорусский менталитет, как и везде. Вот только с такими негремящими периодически знакомится налоговая.
6) В общем, Витебск один из крупнейших белорусских центров IT-аутсорсинга
Про относительные цифры думаю спрашивать не стоит?
очень много вещей работают по принципу: создали runnable и скормили в dispatchEvent.
да, я понимаю что так проще, но в итоге подвисание одного runnable на ресурсоемкой операции останавливает отрисовку всего ui, причем нельзя нажать cancel или abort, так как события от клавиш становятся в очередь и поэтому будут обработаны только после завершения текущей задачи.
p.s. несколько примеров:
1) открываем File -> Project Structure. если у нас много Problems, то из-за неаккуратного кодирования (конкатенация строк в цикле через +), строка формируется очень долго, вплоть до подвисания ui (решается только через kill процесса). баг заведен
2) save на большом проекте, ProjectImpl.save() который в конце концов начинает усиленно дергать ReplacePathToMacroMap.substitute() у меня подвешивает совсем не на одну секунду.
p.p.s. и да =) я лучше понаблюдаю нагрузку 1 минуту на все ядра, чем буду ждать 5 минут пока оно на одном ядре перемелет все