15 grudnia 2020

AWS re:Invent 2020 i redefinicja wysokiej dostępności dla data center

Kiedy zastanawiamy się nad pojęciem wysokiej dostępności (ang. high availability) w systemach informatycznych - o ile w ogóle niektórzy zastanawiają się - to warto nadmienić tutaj o ważnej nowości, którą podzielił się w ostatnich dniach Amazon w ramach konferencji AWS re:Invent 2020. Ten wpis to rozważania nad wysoką dostępnością w skrócie HA, jak możemy ją zdefiniować, jakie miary ją definiują i jakie techniczne zagadki nas czekają, kiedy mówimy, że "chcemy wdrożyć HA".


Wprowadzenie do HA

Wysoką dostępnością określamy stan systemu, kiedy jego funkcjonalności biznesowe, czyli te z punktu widzenia użytkownika końcowego w całości są dostępne do użycia. W języku polskim określa się to nawet skrótem SWN (system wysokiej niezawodności), z którym spotkałem się rzadziej niżeli przyjętym skrótem HA. Zasadniczo nie wszyscy rozumieją, że nie chodzi tutaj o dostępność wszystkich komponentów systemu, bo nie zawsze klikanie np: ikonki Like jest kluczowe dla biznesu. Dla jednego (patrz: Facebook) to core biznes, dla innego np: wirtualnej galerii sztuki to po prostu dodatek. Z tego też banalnego punktu widzenia, posiadanie wysokiej dostępności to sprawa zależna od core biznesu. 

Na pewno nie można dyskutować o płynności HA, w niektórych bardzo specyficznych dziedzinach t.j. medycyna, lotnictwo, obronność, przemysł kosmiczny, sterowanie ruchem, autonomiczne pojazdy, roboty przemysłowe i wiele innych. Jak widać, są zastosowania, gdzie warto nieco przedefiniować podejście do wysokiej dostępności. A może po prostu zastosować HA zgodnie z obowiązującymi normami :-)

Wydaje się niektórym młodszym przedstawicielom IT, że HA to ostatni nabytek branży IT i to tutaj tak dba się o wysoką dostępność. Otóż, założenie to jest obarczone błędem, bo HA również towarzyszyło pierwszym konstruktorom z różnych dziedzin np: w motoryzacji - silników, w przemyśle kosmicznym - napędów rakiet, od którego zależy powodzenie misji załogowej. Widać po tych przykładach, że HA, to nie jest kilka zasad i koniec. Na prawdziwe HA składa się wiele detali -  szkoły inżynierskie, praktyka starszych inżynierów i szkolenie młodych adeptów sztuki, monitoring, audyty, testy chaosu, fuzzing, dzielenie się wiedzą, bezpieczeństwo z podejściami blue/red i stałą eksploracją branży, budowanie standardów i norm, zasady i higiena w miejscu pracy, dyskutowanie o wyzwaniach i dzielenie się wiedzą, posiadanie patentów, poddawanie testom obciążeniowym tego co wytwarzamy i wiele więcej różnych tematów. Tak, na HA składa się dość sporo doświadczenia ludzi z różnych działów, aby w końcu je jakoś zapisać. Warto zapisać, bo do momentu posiadania "wirtualnego SLA", nie wiemy z czym się technicznie mierzymy.

Tak przy okazji, kiedy lecicie samolotem tam też są komputery, których HA jest wyliczone i jest taka mini serwerownia, która zapewnia redundancję, kiedy zawiedzie sekacja A. Nasze życie ratuje wówczas sekcja B oraz dalsze reakcje zgodnie z procedurami pilotów. Jak zaufać autopilotowi w takiej sytuacji ? Otóż, SLA takiego zachowania zostało określone w normach i testy, awarie, incydenty, wypadki wykazały, że pewne rozwiązania działają sprawniej od innych. Tym samym, są znane kroki, które podwyższają HA działania samolotów. Ba, są instytucje, które piszą standardy, abyśmy w powietrzu czuli się zdecydowanie lepiej niżeli w powietrznym PKSie ;-) Nie jest to uwaga do tanich linii lotniczych - polubiłem je kiedyś i nawet dają dreszczyk emocji czasami, gratis.

Jak przedstawić HA w postaci mierzalnej metryki

Zapisanie formalnie jaki jest poziom wysokiej dostępności (ang. HA) w naszym systemem dobrze jeśli będzie odbywał się w sposób pół-automatyczny i bazował na wskaźniku umownym Service Level Agreement (ang. SLA, - pol. umowa o gwarantowanym poziomie świadczenia usług). Tutaj słowo wyjaśnienia, bo SLA dla nas samych może wydawać się żartem, ale nim nie jest. Jest za to prawdziwym przedsięwzięciem, postawieniem na nogi wielu działów w firmie, dzięki czemu każdy w swoim zespole zastanawia się przy okazji: co mógłby zrobić jutro lepiej? na co nie było być może czasu wczoraj. A może był czas, ale zarządzanie nim nie było efektywne? A może klient nie zapłacił za SLA na poziomie wyższym niżeli mamy obecnie? 

Takie i inne ważne pytania warto zadać sobie w zespole, aby powiedzieć np: mamy SLA na poziomie zmierzonym od miesiąca wynoszącym 99,999 % !!! No na pewno nie będzie nikomu wstyd, jeśli takie SLA posiada, bo podana wartość to zmierzona niedostępność systemu 5 minut na rok :-)


Czemu warto walczyć o więcej 9-tek w swoim SLA?

Tak, są firmy, które walczą o więcej dziewiątek w swoim umownym zapisie o dostępności SLA i uwierzcie tysiące ludzi dbają o to, aby po roku rozliczyć się sumiennie z tego. Tak, bo inżynieria a nie amatorka polega na tym, że jeśli zgadzamy się w zespole na SLA i umawiamy, że będzie to grało na poziomie X, to robimy jako inżynierowie wszystko, aby do tego doszło. 

Nie zawsze w zespole są inżynierowie z tytułami, lecz dobrze jeśli znajdzie się taki dla uzupełnienia ekipy ;-). Warto wiedzieć, że obecnie w branży IT są obecni ludzie po technikach, po filozofii i innych szkołach i branża bardzo szanuje każdego, bo brakuje zwyczajnie chętnych osób o otwartych umysłach do stałej nauki nowości IT. Zapewniam Was, że niekiedy nieinżynierowie mają więcej odwagi/energii/zamozaparcia do zrobienia HA na solidnym poziomie, niżeli tzw. "inżynierowie z petrobudowy" jak śpiewał kiedyś Kazik. Ta dygresja wynika z doświadczenia, a nie jest to obraza dla szeroko rozumianej inżynierii. Mam tutaj na myśli fakt, że nie jeden inżynier w karierze zawodowej spotkał młodzika, który robił coś i szybko uczył się, po czym jego poziom realizacji zadań przewyższył poziom oferowany przez inżyniera. To w tych czasach IT może być zgubne, jak szybko ludzie spoza branży są w stanie, przy odpowiedniej motywacji stać się ekspertami. Zapewne jest to kwestia urodzenia obok tabletu :-) albo z wrośniętym 9-tym bitem, hahaa. 

Tutaj znajdziecie kalkulacje dostępności dla SLA. Istnieją w sieci też kalkulatory online dla SLA, gdzie wpisując 9-tki zobaczymy jak bardzo dostępny powinien być system IT wg. określonego SLA. 

Wracając do tematu kolejnych 9-tek w SLA, warto powiedzieć, że niektórym firmom HA zwyczajnie się to opłaca. Np: weźmy pod uwagę Allegro.pl, czyli taki najbardziej namacalny przykład polecanego e-commerce w naszym kraju :-) Doceniam inżynierię, jaką tam mogłem poznać i współtworzyć. To jak Allegro.pl podchodzi o SLA to właśnie przykład powagi i odpowiedzialności, dojrzałości zespołowej, gdzie na końcu Pan Kowalski kupując żyrafkę w pacyfki wnuczce w prezencie, po prostu klika "Kup teraz" i np: mając podpiętą kartę kredytową, nie musi się martwić tym, czy towar dotrze na miejsce. Tak, towar dotrze, bo większa grupa dojrzałych inżynierów jest świadoma tego, jakie ma SLA i to motywuje ich do dostarczania radości klientom :-)

Szukając przykładów bardziej globalnych, które też mają w swoich celach dostarczanie radości klientom, skupię się na SLA firmy Amazon, bo ciekawostka jakiej się dowiedziałem może Was zmotywować do pracy nad własnym HA.

Jak bardzo AWS zwiększył wysoką dostępność na poziomie centrum danych?

Centrum danych (ang. data center) tzn. serwerownia to zestaw wielu serwerów, na których działają obliczenia oraz przez które przemieszczają się różne dane klientów ew. towarów. Budowanie DC jest to dość nowa dziedzina, która zapewnia zbudowanie centrum obliczeniowego na wymaganym poziomie. Okazuje się, że wymagania z roku na rok rosną. Nie jest prawdą, że serwerownie mają jedno łącze do internetu i radośnie sobie wszystko działa, bo admin Janek czuwa nad stabilnością. Nie te czasy minęły ok. 15 lat temu. Obecnie serwerownie to miejsca ze specjalnymi klimatyzatorami, szynami wielu kanałów zasilających, awaryjnych UPSów, agregatów awaryjnych, które napędzane silnikami diesla pozwalają przetrwać serwerom braki i niestabilności zasilania. Prawdą jest, że kupując miejsce w DC mamy zazwyczaj jasno określone zasady HA np: przez podanie SLA i zasad wspierania HA, albo na różne inne sposoby, które są często tajemnicą wewnętrzną danego centa danych. 

W tym roku Amazon w ramach konferencji podzielił się pewną architekturą, jaką chciałbym przedstawić tutaj i pokazał, jak fajnie przeskalować i uzyskać kolejną 9-tkę wysokiej dostępności, fizyczną architekturą wspierającą ten cel. 

Otóż, kiedy popatrzymy na typowy obraz DC i zapewnienia podtrzymania zasilania, mamy taki ogólny diagram:





Wszystko jest tutaj dość łatwo rozpoznawalne dla wprawnych oczu z infrastruktury :-) Dla pewności omówię: mamy zewnętrznego dostawcę prądu i awaryjny agregat prądotwórczy, do tego logikę przełączników, baterię akumulatorów. Kiedy dostawca prądu powie nie mam fazy, wówczas na chwilę przełączania na agregat działamy z banków energii, jakimi są akumulatory. Tak, agregat rozgrzewa się jak stary zbawiciel diesel :-) Wiadomo, dolewamy paliwa do diesla, to agregat działa, jeśli nie dolewamy, to ma to często kilka do kilkunastu godzin działać, aż naprawią trakcję elektryczną.

Wygląda dość racjonalnie i teraz zobaczcie, co zrobił Amazon:






Jak widać na pierwszy rzut oka 99.99997 % SLA - tak, to nie błąd po przecinku są cztery 9-tki i jedna 7-ka. Co daje niedostępność ich infrastruktury serwerowej na poziomie .....  9 sekund rocznie !!!!
Sprawdźcie sami na kalkulatorze SLA online
Brawo, dla ich zapału, innowacji i inżynierii - to jest mega dobry wskaźnik jakości.

Dodali drugi tor z agregatem prądotwórczym i silą z elektrowni :-) 
To ciekawe, a zapewne drogie rozwiązanie, ale to nie jest koniec. Amazon przede wszystkim uznał, że wszystkie podsystemy po drodze tzn. UPS, logika w sterownikach, agregaty oparte są też o software i jak wiadomo, software ma błędy :-) Idąc dalej tym tropem, uznali, że sami stworzą sobie oprogramowanie a docelowo hardware dla swoich serwerowni. I tutaj pewnie uznacie, że to koniec zabawy, bo zrobienie własnego racka (szafki na serwery) jest bardzo spoko, ale własny UPS, to ambitny produkt. 
Oto, jak prawdopodobnie mogło się to rozegrać w praktyce: inżynierowie teoretyczni spotkali praktyków, mieli wspólne rozmowy, zapewne poleciało kilka nieudanych prób i nagle, po wykonaniu jednego komponentu kompleksowo okazało się, że działa tak jak chcemy i mamy do niego testy. 
Jeśli nasi testerzy wiedzą jak to działa i gwarantują nasze standardy jakości, to zaczyna się nieźle. 

Suma podwyższonych standardów jakości działów w Amazon, spowodowała, że te mniejsze SLA na poziomie poszczególnych zespołów wytworzyły wartość globalną jaką jest podwyższenie HA w produkcie AWS. Tak, przerabiali też hardware, ale jak widać, inaczej się nie da - tzn. nikt nie podzielił się taką wiedzą, jak to realnie zrobić inaczej. 
Coś, co widać i warto wspomnieć: Amazon uzyskał redundancję w DC, rozdzielając podsystem podtrzymania zasilania dla dwóch torów zasilania, które są w ich szafach z serwerami. Bo wiedzą, że przełączanie zasilania to też ryzyko i tym samym wypadki na tej linii mają z głowy. Okazuje się, że to dość wrażliwa sprawa :-) i wiem też z praktyki, że bardzo newralgiczna dla ludzi z utrzymania infrastruktury z wysokim HA.

Uznaję tą prezentację "Infrastructure Keynote" za lekcję, że jeśli zespół otrzymuje ambitne i czasami niemożliwe wyzwanie, wówczas odpowiednia ilość PoC, burzy mózgów, wiedzy, radości jako pozytywny miks, dają wartość biznesową innym. Tak, znam to uczucie - fajnie jest uczestniczyć w takim procesie twórczym ;-)

Wprowadzenie HA często niweluje tzw. jeden punkt awarii (ang. Single Point of Failure), pozwala zapewnić większą redundancję (ang. redundancy), czyli odporność na wymieniony SPoF. Z tym wiąże się często obserwacja i monitorowanie (ang. abservability and monitoring). Tak się składa, że świetnie się to wpisuje w filozofię DevOps, którą opisuję tutaj. Stosuję ją na co dzień w pracy i widzę, że bywa przekonująca dla wielu inżynierów :-) Bardzo pożądaną konsekwencją podwyższonego SLA jest też spadek zgłoszeń technicznych do działu kontaktu z klientami. Same plusy - tak, ale wiemy, że to inwestycja, która przenosi poziom organizacji na wyższy status. Nie wszystkich stać, ale Ci, którzy wdrożyli liczą pozytywne efekty dość szybko.

Jeśli macie jakieś przemyślenia związane z budowaniem większej dostępności w IT, napiszcie w komentarzach. Chętnie poznam Wasze punkty widzenia.


 




1 listopada 2020

Teachable Machine - Machine Learning to takie proste !

 Teachable Machine to projekt tworzony m.in. przez Google, który ułatwia wejście w podstawy uczenia maszynowego (ang. Machine Learning) poprzez praktykę. Tak wiele kroków należy uczynić, aby zrozumieć w praktyce Machine Learning, podstawy matematyczne, typowe algorytmy, algorytmy pozwalające na uzyskanie wysokiej skuteczności per różne dziedziny, frameowrki i programowanie, trenowanie modeli, dopieszczanie modeli, zapewnienie wlaściwych zbiorów danych do trenowania, itd. Jak widać z potoku pojęć, jest kilka tematów, które warto poznać, aby zrozumieć ML :-) 

Jednak poznanie Machine Learning nie musi być wcale takie trudne, kiedy mamy odpowiednie oparte o interfejs wizualny narzędzia. Oto docieramy do projektu Teachable Machine, dzięki któremu wytrenujemy rozpoznawanie różnych stanów/przedmiotów/obiektów w kilka minut. Sprawdźcie sami, bo tak banalny interfejs pokazuje, że problemy klasyfikacji nie są wcale trudne do zrozumienia w podstawach ML

To co zobaczmy - po kliknięciu w link - to przyjazny interfejs, który pozwala na podłączenie się z przeglądarki do kamerki lub upload obrazków dla poszczególnych klas służących do klasyfikacji.

 

Dzięki takiej sprytnej koncepcji możemy zrobić modele, wytrenować w locie nasz model i oglądać rezultaty w czasie rzeczywistym np: z podłączonej do laptopa kamerki.


Projekt nie ogranicza nas za bardzo, jeśli chcemy użyć wyobraźni to jest jak zawsze dozwolone ;-) W związku z tym wyjściem może być mowa lub dźwięk zależnie od ścieżki klasyfikacji.

Zachęcam do pokazania tego narzędzia dzieciom, bo jest to jak mi się wydaje najbardziej praktyczny sposób na odpowiedź dziecku na podstawowe pytanie: "co to jest machine learning?". Zapewniam Was, że nie zawsze odpowiedź na to pytanie udaje się znaleźć łatwo, stąd dzielę się tym znaleziskiem, być może wzmocnicie pojęcie ML u przyszłych pokoleń wynalazców ;-).

Więcej przykładów i sugestii do nauki Machine Learning z Teachable Machine przez zabawę możecie też wyszukać na YT, np:  


Jeśli udało Wam się ułożyć jakąś ciekawą klasyfikację, dajcie znać w komentarzach.

19 października 2020

Valgrind - pomaga wyszukać wycieki pamięci w programach

Chwilę pomyślałem sobie dzisiaj o problemach jakie mogą mieć urządzenia wbudowane z oprogramowaniem i przyszła mi taka myśl: 

Ciekawe, czy zależnie od języka programowania w standardzie możemy dostawać wycieki pamięci lub nie?

Z punktu widzenia różnych znanych mi systemów w urządzeniach mobilnych zastanawia mnie słabe rozwiązanie tego problemu - tzn. klikanie zwolnij zaalokowaną pamięć telefonu na żądanie. Inny wariant, to dedykowane programy z klasy "odśmiecacze pamięci", czyli dedykowane oprogramowanie, którego celem jest przegląd wszelkich niezwolnionych bloków i za zgodą usera próba zwolnienia. Brzmi znajomo, może Twój telefon z Androidem też przymula po otwarciu kilku aplikacji (nie koniecznie gier) ... i dopiero restart naprawia sprawę. Cóż, może mamy tam do czynienia z tzw. wyciekiem pamięci operacyjnej. Koncept nieskomplikowany do sprawdzenia na prostym przykładzie. 


Wprowadzenie do wycieków pamięci

Wyciek pamięci (ang. memory leak) to zaalokowanie pamięci w systemie operacyjnym przez program, który nie zwalania pamięci po zakończeniu swojego działania. 

Wszystko fajnie, kiedy bawimy się telefonem i po np: tygodniu działania zaczyna zamulać, robimy restart i działa dalej. Inaczej sprawa się ma na rynku np: serwerów, czy sprzętu ratującego życie, medycznego, diagnostycznego, kalibracyjnego. Są branże, gdzie wycieki pamięci to nie jest norma a poważny błąd. Każdy bajt wykradziony z puli w takich systemach wbudowanych, to proszenie się o zawieszenie systemu / programu / procesu, czyli o niestandardową awarię.

Nie jest tylko tak, że wycieki pamięci generują programiści danego softu. Mogą istnieć ukryte wycieki pamięci, które generują zewnętrzne bibioteki lub biblioteki współdzielone lub systemowe. Ta klasa błędów posiada dość szeroki zasięg ze względu na magię używania dwóch podstawowych instrukcji niższego poziomu w jężyka programowania t.j. C dobrze znanych. Są to:

 - alloc / malloc / calloc / tallloc i pochodne - rezerwują pamięć w programie dla zmiennej

- free i pochodne - zwalniają przydzieloną pamięć (po podaniu zmiennej z przydziału pamięci jako argumentu) 

Właściwie to chodzi tutaj o fakt, że nie wywołuje się FREE tam gdzie zachodzi *ALLOC. Niby takie proste w opisie a do osiągnięcia nirvany jest sporo kombinacji i pracy ;-)


Valgrind - ratunek na wycieki pamięci w oprogramowaniu

Na szczęście w fazie tworzenia oprogramowania, debugowania i testowania, jesteśmy w stanie sprawdzić jak zachowuje się oprogramowanie i dokonać rozpoznania wycieków pamięci. Narzędziem najpopularniejszym na rynku otwartego oprogramowania jest Valgrind 




Narzędzie to doczekało się dojrzałej wersji i bardzo bogatego portfolio, jeśli chodzi o wspierane architektury.

Valgrind obejmuje obecnie siedem narzędzi o jakości produkcyjnej: 
- detektor błędów pamięci 
- dwa detektory błędów wątków 
- pamięć podręczną i profiler predykcji rozgałęzień 
- wykres wywołań generujący pamięć podręczną 
- profiler przewidywania rozgałęzień 
- dwa różne profilery sterty. 
Zawiera również eksperymentalny generator podstawowych wektorów blokowych SimPoint. 
Działa na następujących platformach: X86 / Linux, AMD64 / Linux, ARM / Linux, ARM64 / Linux, PPC32 / Linux, PPC64 / Linux, PPC64LE / Linux, S390X / Linux, MIPS32 / Linux, MIPS64 / Linux, X86 / Solaris , AMD64 / Solaris, ARM / Android (2.3.x i nowsze), ARM64 / Android, X86 / Android (4.0 i nowsze), MIPS32 / Android, X86 / Darwin i AMD64 / Darwin (Mac OS X 10.12).

W Ubuntu możemy zainstalować narzędzie valgrind z takiego onelinera:

$ snap install valgrind  --classic



Test dwóch znanych języków programowania - Python i Golang - na wycieki pamięci w najprostszym programie

Wracam tutaj do założenia mojego wpisu. Mamy dwa bardzo popularne dzisiaj języki programowania: Python i Golang, którymi posługuję się biegle na codzień. Pomyślałem, spróbuję napisać jednolinijkowca i zobaczymy, czy valgrind coś wykryje :-) Poniżej zrzut z testu i rezultaty:


Program w Python + valgrind


$ cat memleaks_test.py 
print("a" * 255)

$ python3 memleaks_test.py 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Ok, odpalmy teraz z badaniem wycieków pamięci i co widzimy:

....
==19177== Invalid read of size 4
==19177==    at 0x5139AE: PyGrammar_RemoveAccelerators (in /usr/bin/python3.8)
==19177==    by 0x67EE59: Py_FinalizeEx (in /usr/bin/python3.8)
==19177==    by 0x6B614C: Py_RunMain (in /usr/bin/python3.8)
==19177==    by 0x6B63BC: Py_BytesMain (in /usr/bin/python3.8)
==19177==    by 0x4C890B2: (below main) (libc-start.c:308)
==19177==  Address 0x51f0020 is 384 bytes inside a block of size 732 free'd
==19177==    at 0x4A39078: free (vg_replace_malloc.c:538)
==19177==    by 0x51ACB8: PyGrammar_AddAccelerators (in /usr/bin/python3.8)
==19177==    by 0x5FD6C4: PyParser_New (in /usr/bin/python3.8)
==19177==    by 0x517293: ??? (in /usr/bin/python3.8)
==19177==    by 0x67BA7A: PyParser_ASTFromStringObject (in /usr/bin/python3.8)
==19177==    by 0x67BEFD: PyRun_StringFlags (in /usr/bin/python3.8)
==19177==    by 0x600581: ??? (in /usr/bin/python3.8)
==19177==    by 0x5C4D7F: ??? (in /usr/bin/python3.8)
==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)
==19177==    by 0x5F7145: _PyFunction_Vectorcall (in /usr/bin/python3.8)
==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)
==19177==    by 0x569559: _PyEval_EvalCodeWithName (in /usr/bin/python3.8)
==19177==  Block was alloc'd at
==19177==    at 0x4A37ECB: malloc (vg_replace_malloc.c:307)
==19177==    by 0x51ACCF: PyGrammar_AddAccelerators (in /usr/bin/python3.8)
==19177==    by 0x5FD6C4: PyParser_New (in /usr/bin/python3.8)
==19177==    by 0x517293: ??? (in /usr/bin/python3.8)
==19177==    by 0x67BA7A: PyParser_ASTFromStringObject (in /usr/bin/python3.8)
==19177==    by 0x67BEFD: PyRun_StringFlags (in /usr/bin/python3.8)
==19177==    by 0x600581: ??? (in /usr/bin/python3.8)
==19177==    by 0x5C4D7F: ??? (in /usr/bin/python3.8)
==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)
==19177==    by 0x5F7145: _PyFunction_Vectorcall (in /usr/bin/python3.8)
==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)
==19177==    by 0x569559: _PyEval_EvalCodeWithName (in /usr/bin/python3.8)
==19177== 
==19177== 
==19177== HEAP SUMMARY:
==19177==     in use at exit: 301,190 bytes in 135 blocks
==19177==   total heap usage: 2,186 allocs, 2,051 frees, 3,158,779 bytes allocated
==19177== 
==19177== LEAK SUMMARY:
==19177==    definitely lost: 0 bytes in 0 blocks
==19177==    indirectly lost: 0 bytes in 0 blocks
==19177==      possibly lost: 1,632 bytes in 3 blocks
==19177==    still reachable: 299,558 bytes in 132 blocks
==19177==         suppressed: 0 bytes in 0 blocks
==19177== Rerun with --leak-check=full to see details of leaked memory
==19177== 
==19177== Use --track-origins=yes to see where uninitialised values come from
==19177== For lists of detected and suppressed errors, rerun with: -s
==19177== ERROR SUMMARY: 1106 errors from 128 contexts (suppressed: 0 from 0)

Kilkaset bajtów program pożarł ;-) a to nowina dla wszystkich milionów użytkowników języka Pytohn :-) Polecam prztestować bardziej skomplikowane programy oraz serwery aplikacji.



Program w Golang + valgrind


$ cat main.go 
package main

import "fmt"
import "strings"

func main() {
fmt.Println(strings.Repeat("a", 255))
}


$ go build main.go 
$ ./main 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa


Program w GOlangu robi dosłownie to samo i badamy go przy pomocy valgrind:


==19372== Conditional jump or move depends on uninitialised value(s)
==19372==    at 0x40C4FD: runtime.mallocgc (/snap/go/6633/src/runtime/malloc.go:1152)
==19372== 
==19372== Conditional jump or move depends on uninitialised value(s)
==19372==    at 0x40C4B1: runtime.mallocgc (/snap/go/6633/src/runtime/malloc.go:1136)
==19372==    by 0x4474A8: runtime.growslice (/snap/go/6633/src/runtime/slice.go:230)
==19372==    by 0x43593E: runtime.allgadd (/snap/go/6633/src/runtime/proc.go:473)
==19372==    by 0x43D1F8: runtime.newproc1 (/snap/go/6633/src/runtime/proc.go:3572)
==19372==    by 0x45DBD2: runtime.newproc.func1 (/snap/go/6633/src/runtime/proc.go:3528)
==19372==    by 0x461605: runtime.systemstack (/snap/go/6633/src/runtime/asm_amd64.s:370)
==19372==    by 0x43745F: ??? (<autogenerated>:1)
==19372== 
==19372== Conditional jump or move depends on uninitialised value(s)
==19372==    at 0x40C4FD: runtime.mallocgc (/snap/go/6633/src/runtime/malloc.go:1152)
==19372==    by 0x4474A8: runtime.growslice (/snap/go/6633/src/runtime/slice.go:230)
==19372==    by 0x43593E: runtime.allgadd (/snap/go/6633/src/runtime/proc.go:473)
==19372==    by 0x43D1F8: runtime.newproc1 (/snap/go/6633/src/runtime/proc.go:3572)
==19372==    by 0x45DBD2: runtime.newproc.func1 (/snap/go/6633/src/runtime/proc.go:3528)
==19372==    by 0x461605: runtime.systemstack (/snap/go/6633/src/runtime/asm_amd64.s:370)
==19372==    by 0x43745F: ??? (<autogenerated>:1)
==19372== 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
==19372== 
==19372== HEAP SUMMARY:
==19372==     in use at exit: 0 bytes in 0 blocks
==19372==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==19372== 
==19372== All heap blocks were freed -- no leaks are possible
==19372== 
==19372== Use --track-origins=yes to see where uninitialised values come from
==19372== For lists of detected and suppressed errors, rerun with: -s
==19372== ERROR SUMMARY: 3447 errors from 761 contexts (suppressed: 0 from 0)

... i ku naszemu zdziwieniu jednak GOlang nie ma wycieków pamięci na takim samym banalnym programie.



Podsumowanie

Bardzo ciekawa obserwacja pomyślałem sobie, jak łatwo przy pomocy valgrind znajdziemy wycieki pamięci. Szczególnie kiedy chciałbym coś napisać na urządzenie wbudowane, którego wielkość pamięci RAM to nie są GB a MB, przemyślę jednak w jakim języku napisać kod. 
Nie chciałbym wpaść w totalne błędne wnioski, że nie można tego robić w Pythonie i tylko w GOlang, gdyż może to być błąd mojej wersji i w kolejnej zostanie naprawiony. Oczywiście, tak błachy błąd dla jednych programistów jest powodem do kolejnych eksperymentów dla innych. 

W związku z tym zapraszam do wypowiedzi, jakie macie doświadczenia z valgrind? Z jakich ciekawych sytuacji wyratował Was ten tool w pracy zawodowej?