Здравствуйте, zinid, Вы писали:
Z>Здравствуйте, Gaperton, Вы писали:
G>>Найн. Не все так радужно. В системе Эрланг (на 32-х разрядной машине) не может крутится более примерно 262ххх. Я бы при дизайне системы ограничил количество одновременно живущих процессов раумным числом в десятки тысяч — до примерно одной сотни тысяч. На практике — это создает не много проблем.
Z>Зачем вы дезинформируете людей? The maximum number of simultaneously alive Erlang processes is by default 32768. This limit can be raised up to at most 268435456 processes at startup (see documentation of the system flag +P in the erl(1) documentation). The maximum limit of 268435456 processes will at least on a 32-bit architecture be impossible to reach due to memory shortage.
Z>На самом деле основная проблема Erlang'а на 32-битной системе — ограничение на размер кучи в 1699221830 байт (OTP-5596).
Это куча, из которой стэки под все процессы выделяются? Не подскажешь, где о таких подробностях почитать?
Здравствуйте, Курилка, Вы писали:
Z>>На самом деле основная проблема Erlang'а на 32-битной системе — ограничение на размер кучи в 1699221830 байт (OTP-5596).
К>Это куча, из которой стэки под все процессы выделяются? Не подскажешь, где о таких подробностях почитать?
Здравствуйте, Cyberax, Вы писали:
>> б) насколько я понимаю, банальный бесконечный цикл, полученный по >> ошибке, приведет в kernel mode к катастрофическим последствиям. C>Нет, к таким же как и в пользовательском — ядерный поток просто C>зависнет. Процессор будет занят на 100%, но при желании поток можно C>будет убить.
Это в каком ядре? Ни штатный linux ни например freebsd не допускают силовой preemption потоками из top half, а только обработчиками прерываний. Если "при желании" включает в себя вмешательство через DDB или аналог через локальную консоль — да. Но сделать например kill зайдя ssh'ем — не получится.
>> Можно обратиться к экспертам по режиму ядра за комментариями. Насколько >> я понял, в настоящее время программирование в этом режиме — это путь >> настоящих самураев. C>Ну это если на чистом С без всего.
А на других средствах ресурсов больше не будет. Меньше диверсий — да, будет. И если изложить код на каком-то промежуточном языке который будет компилироваться в то что нужно и при этом ещё и следить за аккуратным потреблением всех ресурсов — ok. Но это надо специально конструировать именно под кодирование в режим ядра.
>> Если окажется, что Erlang обеспечивает как раз те >> гарантии, которые нужны этому режиму для безопасного исполнения софта, >> то это даст эрлангу огромные преимущества. C>Собственно говоря, Erlang работает на vxWorks с кучей девяток C>стабильности, так что вполне реально.
netch80 wrote: > Это в каком ядре? Ни штатный linux ни например freebsd не допускают > силовой preemption потоками из top half, а только обработчиками > прерываний.
Linux 2.6 с CONFIG_PREEMPT.
> Если "при желании" включает в себя вмешательство через DDB > или аналог через локальную консоль — да. Но сделать например kill зайдя > ssh'ем — не получится.
Ну да, только через ядерные интерфейсы. Можно и kkill, при желании, сделать.
> C>Собственно говоря, Erlang работает на vxWorks с кучей девяток > C>стабильности, так что вполне реально. > так он же не в ядре работает?
Но с кучей девяток. А от системы особо много ему и не надо.
Здравствуйте, zinid, Вы писали:
Z>Здравствуйте, Gaperton, Вы писали:
G>>Найн. Не все так радужно. В системе Эрланг (на 32-х разрядной машине) не может крутится более примерно 262ххх. Я бы при дизайне системы ограничил количество одновременно живущих процессов раумным числом в десятки тысяч — до примерно одной сотни тысяч. На практике — это создает не много проблем.
Z>Зачем вы дезинформируете людей?
Ну забыл несколько ноликов Суть дела это не сильно меняет. Каждый процесс в реальной системе расходует порядка нескольких килобайт памяти. Сколько там написано в документации, про минимум? Так вот, память и возросшие задержки на передачу информации и будут реальным ограничением количества процессов. Современная витруальная машина адекватно держит под сотню тыщ процессов, но 500000 — это уже перебор. А старая машина, на которой работал АХД плохо справлялась и с сотней тысяч, там народ количество процессов поджимал — в мейллисте обсуждали.
Правда, с файберами все еще хуже. Они адресное пространство сожрут быстро, их даже десятки тыщ завести сложно. На 32-х битной машине, конечно.
E>deliver_message( post, recipient )
E>{
E> for(i = 0; i != N; ++i )
E> {
E> result = try_deliver( post, recipient );
E> if( ok != result )
E> {
E> // Если временная проблема доставки, то есть
E> // смысл повторить ее позже.
E> if( can_be_delivered_later( result ) )
E> sleep( (i+1)*TIMEOUT );
E> else
E> // Если SMTP сервера нет или он говорит, что
E> // такого получателя нет, то просто прекращаем
E> // дальнейшие попытки.
E> die( post, recipient, THESE_STUPID_BEES_MAKE_INVALID_HONEY );
E> }
E> else
E> // Сообщение отправлено.
E> die( post, recipient, HAVE_A_NICE_DAY );
E>}
E>
Не верю, что может быть всё так просто и хорошо
Тут где-то подвох! В чём он?
Сразу в глаза бросается, что все входные данные мы копируем. А если там большой массив, я буду должен его 100000 раз раскопировать? Сразу скажу, что про Erlang знаю только по наслышке, поэтому может я какие вопросы задаю неправильные
А если надо ещё после завершения такого потока модифицировать разделяемые данные, то как быть?
remark wrote: > Сразу в глаза бросается, что все входные данные мы копируем. А если там > большой массив, я буду должен его 100000 раз раскопировать? Сразу скажу, > что про Erlang знаю только по наслышке, поэтому может я какие вопросы > задаю неправильные
Можно не копировать массив, а просто передать на него ссылку. Для
Erlang'а это будет одно и то же.
> А если надо ещё после завершения такого потока модифицировать > разделяемые данные, то как быть?
А у тебя НЕТ разделяемых данных Все разделяемые данные пакуются в
свои процессы.
Здравствуйте, Cyberax, Вы писали:
C>remark wrote: >> Сразу в глаза бросается, что все входные данные мы копируем. А если там >> большой массив, я буду должен его 100000 раз раскопировать? Сразу скажу, >> что про Erlang знаю только по наслышке, поэтому может я какие вопросы >> задаю неправильные C>Можно не копировать массив, а просто передать на него ссылку. Для C>Erlang'а это будет одно и то же.
При посылке сообщений это не так. Даже в рамках одной виртуальной машины при передаче сообщений (ведь об этом речь, так?) копируется все, кроме длинных binaries, которые живут в разделяемом процессами хипе, и управляются подсчетом ссылок. Происходит так потому, что у каждого процесса свой собственный хип, который подбирается, кстати, методом stop-and-copy, а не mark-and-sweep, о чем где-то тут рядом писали. Возможно, в будущем, когда в список стабильных фич попадет shared heap — это изменится.
Stop-and-copy — это, в частности, означает, что хип всегда занимает в два раза больше памяти, чем необходимо для хранения данных. А также, это означает тормоза при большом объеме аллокированных данных. Особливо — большого объема короткоживущих данных.
В рамках нескольких виртуальных машин, понятное дело, копируется все и всегда. Через сокет передается.
Все эти вещи (особенности технологии) надо знать, и учитывать при проектировании систем. Пугаться их не надо.
Здравствуйте, Gaperton, Вы писали:
G>А также, это означает тормоза при большом объеме аллокированных данных. Особливо — большого объема короткоживущих данных.
Это почему? Время сборки во многом зависит от объёма живых. Короткоживущие же быстро помрут.
Gaperton wrote: > C>Можно не копировать массив, а просто передать на него ссылку. Для > C>Erlang'а это будет одно и то же. > При посылке сообщений это не так. Даже в рамках одной виртуальной машины > при передаче сообщений (ведь об этом речь, так?) копируется все, кроме > длинных binaries, которые живут в разделяемом процессами хипе, и > управляются подсчетом ссылок. Происходит так потому, что у каждого > процесса свой собственный хип, который подбирается, кстати, методом > stop-and-copy, а не mark-and-sweep, о чем где-то тут рядом писали. > Возможно, в будущем, когда в список стабильных фич попадет shared heap — > это изменится.
Это уже изменилось Я тут кидал ссылку на новый дизайн GC для Эрланга,
там сейчас стало можно использовать общий хип.
Здравствуйте, Cyberax, Вы писали:
>> Возможно, в будущем, когда в список стабильных фич попадет shared heap — >> это изменится. C>Это уже изменилось Я тут кидал ссылку на новый дизайн GC для Эрланга, C>там сейчас стало можно использовать общий хип.
Круто. На самом деле круто. Тока вопрос. Это стабильная фича? Она включена по дефолту в последнем релизе, или ее можно включать "в экспериментальных целях на свой страх и риск?" Ну, типа, как виртуальные модули или там еще какую-нибудь фигню, типа поддержки SMP, которая замедляет наши программы в 10 раз?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Gaperton, Вы писали:
G>>А также, это означает тормоза при большом объеме аллокированных данных. Особливо — большого объема короткоживущих данных.
ANS>Это почему? Время сборки во многом зависит от объёма живых. Короткоживущие же быстро помрут.
Из-за разницы в алгоритмах stop-and-copy и mark-and-sweep. Разница здесь — memorymanagement.org
Суть stop-and-copy в переливании живых из одного хипа в другой, и обратно. Мертвые убиваются одним махом вместе с одним из двух хипов... Мое соображение было основано на том, что в ситуации, когда выделения памяти нет, stop-and-copy все равно занят постоянным копированием из одного хипа в другой. Следовательно, у тебя на ровном месте появляются тормоза, пропорциональные размеру выделенной памяти. Далее. В Эрланге сборщик мусора с двумя поколениями. Понятное дело — долгоживущих и короткоживущих. Следовательно, если у нас будет много часто меняющихся данных в одном процессе — это для нас плохо.
Знаешь, я тут подумал — а все фигня, на самом деле все не так. В худшем случае получим только перерасход памяти, но тормозов получить не должны. Сборщик-то инкрементальный, следовательно он будет просто реже пробегаться по хипу при его росте. Отсюда и потенциальный перерасход. Гхм, а перерасход памяти — это у нас увеличенный свопфайл, и опять тормоза
Gaperton wrote: > C>Это уже изменилось Я тут кидал ссылку на новый дизайн GC для Эрланга, > C>там сейчас стало можно использовать общий хип. > Круто. На самом деле круто. Тока вопрос. Это стабильная фича? Она > включена по дефолту в последнем релизе, или ее можно включать "в > экспериментальных целях на свой страх и риск?" Ну, типа, как виртуальные > модули или там еще какую-нибудь фигню, типа поддержки SMP, которая > замедляет наши программы в 10 раз?
Сейчас лень смотреть. В исходниках эмулятора в R11B-2 уже он есть (см.
файл ggc.c), запускается опцией -shared у интерпретатора erl (он должен
быть построен с --enable-shared-heap).
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Cyberax, Вы писали:
C>>remark wrote: >>> Сразу в глаза бросается, что все входные данные мы копируем. А если там >>> большой массив, я буду должен его 100000 раз раскопировать? Сразу скажу, >>> что про Erlang знаю только по наслышке, поэтому может я какие вопросы >>> задаю неправильные C>>Можно не копировать массив, а просто передать на него ссылку. Для C>>Erlang'а это будет одно и то же.
G>При посылке сообщений это не так. Даже в рамках одной виртуальной машины при передаче сообщений (ведь об этом речь, так?) копируется все, кроме длинных binaries, которые живут в разделяемом процессами хипе, и управляются подсчетом ссылок. Происходит так потому, что у каждого процесса свой собственный хип, который подбирается, кстати, методом stop-and-copy, а не mark-and-sweep, о чем где-то тут рядом писали. Возможно, в будущем, когда в список стабильных фич попадет shared heap — это изменится.
Показания расходятся
Можно на примере: Допустим та же система рассылки почты, о которой писал eao197. Есть некие глобальные настройки программы (типа адрес почтового сервера, там могут содержаться и некие очень большие списки). Эти настройки необходимы для процесса отправки почты как входные данные, и эти же настройки могут одновременно меняться из GUI. И допустим после успешной/неуспешной отправки надо некоторые "разделяемые" данные обновить (типа статистики). Вобщем типичное серверное приложение.
Как это будет выглядеть и что будет копироваться?
G>Все эти вещи (особенности технологии) надо знать, и учитывать при проектировании систем. Пугаться их не надо.
Я не пугаюсь Я хочу понять, это тривиальный размен производительности на удобную модель программирования, или тут что-то глубже и интереснее.
Здравствуйте, remark, Вы писали:
R>Можно на примере: Допустим та же система рассылки почты, о которой писал eao197. Есть некие глобальные настройки программы (типа адрес почтового сервера, там могут содержаться и некие очень большие списки). Эти настройки необходимы для процесса отправки почты как входные данные, и эти же настройки могут одновременно меняться из GUI. И допустим после успешной/неуспешной отправки надо некоторые "разделяемые" данные обновить (типа статистики). Вобщем типичное серверное приложение. R>Как это будет выглядеть и что будет копироваться?
Это слишком простой пример, чтобы словить на нем проблемы производительности. Обрати внимание, что в твоем примере данные меняются в одном месте (один источник) а используются в разных. Соотвественно, процесс, в котором данные изменились (а меняются они редко — через гуи) просто рассылает изменения процессам-потребителям, которые данные используют. И все.
На самом деле, это другая модель программирования. Она не специфична для Эрланга — она называется actor model. Прочитать про нее можно в википедии.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, remark, Вы писали:
R>>Можно на примере: Допустим та же система рассылки почты, о которой писал eao197. Есть некие глобальные настройки программы (типа адрес почтового сервера, там могут содержаться и некие очень большие списки). Эти настройки необходимы для процесса отправки почты как входные данные, и эти же настройки могут одновременно меняться из GUI. И допустим после успешной/неуспешной отправки надо некоторые "разделяемые" данные обновить (типа статистики). Вобщем типичное серверное приложение. R>>Как это будет выглядеть и что будет копироваться?
G>На самом деле, это другая модель программирования. Она не специфична для Эрланга — она называется actor model. Прочитать про нее можно в википедии.
А как бы такая задача решалась на Erlang и в стиле Erlang? Ну так в двух словах.
G>Это слишком простой пример, чтобы словить на нем проблемы производительности. Обрати внимание, что в твоем примере данные меняются в одном месте (один источник) а используются в разных. Соотвественно, процесс, в котором данные изменились (а меняются они редко — через гуи) просто рассылает изменения процессам-потребителям, которые данные используют. И все.
Может я опять с неправильной стороны смотрю. Но.
1. Всё же придётся иметь 100000 копий большой структуры?
2. При том, что она у всех рабочих потоков будет одинаковой?
3. Придётся отсылать и обрабатывать 100000 сообщений? Не верю, что это может быть быстро.
4. Заменить разом большую, сложную иерархическую структуру легко, а вот написать механизм вычленения из неё изменений и применения отдельных изменений в новой структуре... не хотелось бы этим заниматься. И по любому это тоже будет не особо быстро.
Здравствуйте, Cyberax, Вы писали:
C>Gaperton wrote: >> C>Это уже изменилось Я тут кидал ссылку на новый дизайн GC для Эрланга, >> C>там сейчас стало можно использовать общий хип. >> Круто. На самом деле круто. Тока вопрос. Это стабильная фича? Она >> включена по дефолту в последнем релизе, или ее можно включать "в >> экспериментальных целях на свой страх и риск?" Ну, типа, как виртуальные >> модули или там еще какую-нибудь фигню, типа поддержки SMP, которая >> замедляет наши программы в 10 раз? C>Сейчас лень смотреть. В исходниках эмулятора в R11B-2 уже он есть (см. C>файл ggc.c), запускается опцией -shared у интерпретатора erl (он должен C>быть построен с --enable-shared-heap).
Я перед НГ эту тему поднимал в эрлангквесчнз (здесь), разделяемый хип замочили как неэффективный, оставили только гибридный, когда шарятся только пересылаемые данные
Здравствуйте, remark, Вы писали:
R>Может я опять с неправильной стороны смотрю. Но. R>1. Всё же придётся иметь 100000 копий большой структуры? R>2. При том, что она у всех рабочих потоков будет одинаковой?
Если структура большая, то никто ее копий в каждом процессе иметь не будет. Ее сложат в распределенную базу данных mnesia. Об остальном позаботится mnesia.
R>3. Придётся отсылать и обрабатывать 100000 сообщений? Не верю, что это может быть быстро.
Быстро — это сколько?
R>4. Заменить разом большую, сложную иерархическую структуру легко, а вот написать механизм вычленения из неё изменений и применения отдельных изменений в новой структуре... не хотелось бы этим заниматься. И по любому это тоже будет не особо быстро.
Курилка wrote: > C>Сейчас лень смотреть. В исходниках эмулятора в R11B-2 уже он есть (см. > C>файл ggc.c), запускается опцией -shared у интерпретатора erl (он должен > C>быть построен с --enable-shared-heap). > Я перед НГ эту тему поднимал в эрлангквесчнз (здесь > <http://forum.trapexit.org/viewtopic.php?t=7092>), разделяемый хип > замочили как неэффективный, оставили только гибридный, когда шарятся > только пересылаемые данные
Это, кстати, должно быть даже лучше. Shared в исходниках все еще есть —
просто его по умолчанию выключили.
Здравствуйте, Cyberax, Вы писали:
C>Курилка wrote: >> C>Сейчас лень смотреть. В исходниках эмулятора в R11B-2 уже он есть (см. >> C>файл ggc.c), запускается опцией -shared у интерпретатора erl (он должен >> C>быть построен с --enable-shared-heap). >> Я перед НГ эту тему поднимал в эрлангквесчнз (здесь >> <http://forum.trapexit.org/viewtopic.php?t=7092>), разделяемый хип >> замочили как неэффективный, оставили только гибридный, когда шарятся >> только пересылаемые данные C>Это, кстати, должно быть даже лучше.
О том и речь, хотя это определяется приложением, если пересылки сообщений мало, и сообщения мелкие, то традиционный подход может быть лучше. C>Shared в исходниках все еще есть — C>просто его по умолчанию выключили.
Дак и об этом режиме в документации тоже нифига нет, какое-то секретное знание получается
The maximum number of simultaneously alive Erlang processes is by default 32768. This limit can be raised up to at most 268435456 processes at startup (see documentation of the system flag +P in the erl(1) documentation). The maximum limit of 268435456 processes will at least on a 32-bit architecture be impossible to reach due to memory shortage.
