Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Unique Resiliency of the Erlang VM, the BEAM and Erlang OTP

86 visualizaciones

Publicado el

Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/2FObxyn.

Irina Guberman demonstrates how unique features of the BEAM in combination with Erlang OTP can take a company's servers to the next level of resiliency and robustness. Filmed at qconlondon.com.

Irina Guberman is Principal Product Architect at Xaptum.

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Unique Resiliency of the Erlang VM, the BEAM and Erlang OTP

  1. 1. KILLER features of the BEAM And what makes the BEAM a unique and powerful tool that really stands out!
  2. 2. InfoQ.com: News & Community Site Watch the video with slide synchronization on InfoQ.com! https://www.infoq.com/presentations/ resilience-beam-erlang-otp/ • Over 1,000,000 software developers, architects and CTOs read the site world- wide every month • 250,000 senior developers subscribe to our weekly newsletter • Published in 4 languages (English, Chinese, Japanese and Brazilian Portuguese) • Post content from our QCon conferences • 2 dedicated podcast channels: The InfoQ Podcast, with a focus on Architecture and The Engineering Culture Podcast, with a focus on building • 96 deep dives on innovative topics packed as downloadable emags and minibooks • Over 40 new content items per week
  3. 3. Purpose of QCon - to empower software development by facilitating the spread of knowledge and innovation Strategy - practitioner-driven conference designed for YOU: influencers of change and innovation in your teams - speakers and topics driving the evolution and innovation - connecting and catalyzing the influencers and innovators Highlights - attended by more than 12,000 delegates since 2007 - held in 9 cities worldwide Presented at QCon London www.qconlondon.com
  4. 4. Actor Model Hundreds, Thousands, Millions of processes… System limit can be between1,024-134,217,727 They share NOTHING Communicate through message passing
  5. 5. Demo 1 A hypothetical server
  6. 6. accept(NumRequests)-> [dispatch(Req, self()) || Req <- lists:seq(1, NumRequests)], collect_responses(0, 0, 0, 0, NumRequests). accept_loop() -> receive %% to get a message in my mailbox Req -> dispatch(Req, self()) %% self() = my process id end, accept_loop(). JUGGLER a simplified DEMO SERVER https://github.com/iguberman/erljuggler_demo lists:seq(1, NumRequests)dispatch(Req, self()) dispatch(Req, AcceptorPid) -> spawn( ?MODULE, %% Module kick_off_request_handler, %% Function [Req, AcceptorPid]). %% Arguments kick_off_request_handler
  7. 7. %%% a kind of a supervisor kick_off_request_handler(Req, AcceptorPid) -> RequestHandlerPid = spawn(?MODULE, handle_request, [Req, self()]), kick_off_request_handler {RequestHandlerPid, Resp} -> Unexpected -> AcceptorPid ! {error, Unexpected} Start = os:system_time(millisecond), receive end. handle_request End = os:system_time(millisecond), Duration = End - Start, io:format("...~p [~b]...", [Req, Duration]), AcceptorPid ! {RequestHandlerPid, Resp, Duration}; JUGGLER a simplified DEMO SERVER https://github.com/iguberman/erljuggler_demo
  8. 8. handle_request JUGGLER a simplified DEMO SERVER https://github.com/iguberman/erljuggler_demo handle_request(Req, ParentPid) when is_integer(Req) -> Resp = count_to_1000_and_do_other_stuff_too(Req, 0), HandlerPid = self(), ParentPid ! {HandlerPid, Resp} end. count_to_1000_and_do_other_stuff_too(_Req, 1000) -> ok; count_to_1000_and_do_other_stuff_too(Req, C) -> case (Req rem 2) of 0 -> binary:copy(<<Req/integer>>,300); 1 -> binary:copy(<<(Req + 1)/integer>>,200) end, count_to_1000_and_do_other_stuff_too(Req, C+1).
  9. 9. Demo 2 server with a bug
  10. 10. JUGGLER a simplified DEMO SERVER https://github.com/iguberman/erljuggler_demo handle_request(Req, ParentPid) when is_integer(Req) -> Resp = count_to_1000_and_do_other_stuff_too(Req, 0), HandlerPid = self(), ParentPid ! {HandlerPid, Resp} end. end. case Req rem 100 of 0 -> io:format("~n**** ~p [INF]*****~n", [Req]), ParentPid ! dont_wait_for_me, handle_with_inf_loop_bug(); _Other -> handle_with_inf_loop_bug()-> infinite_loop(0). infinite_loop(C) -> _A = binary:copy(<<1>>,200), _B = math:sqrt(1235), infinite_loop(C+1).
  11. 11. BEAM Scheduler Preemptive? Cooperative? Cooperative at C level Preemptive at Erlang level (by means of reduction counting) 2000 reductions Reduction ~= function call Word of caution: BIFs and NIFs
  12. 12. Free BEAM Memory model Process PCB Stack HeapMBox GC hipe_bifs:show_heap(Pid). hipe_bifs:show_pcb(Pid). %% Look at heap_sz ! hipe_bifs:show_estack(Pid). Old Heap
  13. 13. JVM (simplified! SORRY! ) Heap Thread Thread ThreadThreadThread Thread Thread Thread Thread Thread Thread Thread Thread Thread Thread Thread Thread Thread Thread Thread Thread Thread Thread Thread Thread Thread Thread
  14. 14. Stop the world. Is that a thing in Erlang? GC
  15. 15. DEMO 3 The KILLER
  16. 16. %%% a kind of a supervisor kick_off_request_handler(Req, AcceptorPid) -> RequestHandlerPid = spawn(?MODULE, handle_request, [Req, self()]), {RequestHandlerPid, Resp} -> Start = os:system_time(millisecond), receive end. End = os:system_time(millisecond), Duration = End - Start, io:format("...~p [~b]...", [Req, Duration]), AcceptorPid ! {RequestHandlerPid, Resp, Duration}; KILLER_JUGGLER a simplified DEMO SERVER https://github.com/iguberman/erljuggler_demo after 5000 -> exit(HandlerPid, timedout), AcceptorPid ! {HandlerPid, killed} Other -> AcceptorPid ! {error, Other}
  17. 17. STACK BASED More Instructions REGISTER BASED Instructions are simple Fewer instructions Instructions have more info 1.POP 20 2.POP 7 3.ADD 20, 7, result 4.PUSH result 1. ADD R1, R2, R3 ; # Add contents of R1 and R2, store result in R3
  18. 18. Performance Survey on Stack-based and Register- based VirtualMachines Ruijie Fang, Siqi Liu, 2016 VM feature comparisons: Scientific comparison of REGISTER (Erlang) vs. STACK (JVM) VM Inertia spends 66.42% less time in instruction dispatch than Conceptum, on average However, Inertia is still slower in the overall fetch time, spending 23.5% more time on average in fetching operands than Conceptum does Based on our test results, stack-based virtual machines typically perform better on benchmarks featuring a high amount of arithmetic operations. In contrast to the stack-based virtual machine’s performance, the register-based virtual machine performed much better on recursions and memory operations. CONCEPTUM (stack-based like JVM) INERTIA (register-based like BEAM)
  19. 19. MBox PCB Stack Heap M-buf Free M-buf M-buf M-buf MBox Intern MBox Inbox Old Heap
  20. 20. DEMO 4 Bring it down by sending messages to the process affected by inf loop!
  21. 21. TYPE SYSTEM Strong typed. So every type has a tag. Dynamically typed. Hot code loading anyone?
  22. 22. TAGGING In the memory representation of an Erlang term a few bits are reserved for a type tag. LEVEL 1 tags: 00 Header (on heap) CP (on stack) 01 List (cons) 10 Boxed 11 Immediate LEVEL 2 tags (Immediate): 00 11 Pid 01 11 Port 10 11 Immediate 2 11 11 Small integer <- pointers to the heap <- fit into one word on the stack LEVEL 3 tags (Immediate 2): 00 10 11 Atom 01 10 11 Catch 10 10 11 [UNUSED] 11 10 11 Nil <- for empty list []
  23. 23. Q. How is cooperative scheduling implemented? A. If there are untagged values — no preempting
  24. 24. https://happi.github.io/theBeamBook https://www.researchgate.net/publication/ 309631798_A_Performance_Survey_on_Stack- based_and_Register-based_Virtual_Machines (pdf available) https://llvm.org/devmtg/2014-04/PDFs/Talks/drejhammar.pdf REFERENCES https://markfaction.wordpress.com/2012/07/15/stack-based-vs-register- based-virtual-machine-architecture-and-the-dalvik-vm/
  25. 25. Watch the video with slide synchronization on InfoQ.com! https://www.infoq.com/presentations/ resilience-beam-erlang-otp/

×