Udostępnij za pośrednictwem

Użycie pamięci w aplikacjach wysokiego poziomu

  • Artykuł

Ważne

Jest to dokumentacja usługi Azure Sphere (starsza wersja). Usługa Azure Sphere (starsza wersja) zostanie wycofana 27 września 2027 r., a użytkownicy muszą przeprowadzić migrację do usługi Azure Sphere (zintegrowanej) do tej pory. Użyj selektora wersji znajdującego się powyżej spisu treści, aby wyświetlić dokumentację usługi Azure Sphere (zintegrowaną).

Ten temat zawiera szczegółowe informacje o użyciu pamięci w aplikacjach wysokiego poziomu. Zobacz Zagadnienia dotyczące zarządzania pamięcią i opóźnieniami , aby uzyskać informacje o pamięci dostępnej dla aplikacji obsługujących czas rzeczywistym (RTApps).

Aplikacje wysokiego poziomu mają dostęp do następującej pamięci i magazynu:

  • 256 Pamięć RAM KiB na rdzeniu wysokiego poziomu, zarezerwowane wyłącznie do użycia aplikacji wysokiego poziomu. Do 1 KiB tego miejsca można przydzielić dla każdego udostępnionego kanału buforu, za pośrednictwem którego komunikują się aplikacje wysokiego poziomu i aplikacje RTApps.
  • 1 Pamięć flash tylko do odczytu MiB, która jest współdzielona między rdzeniami wysokiego poziomu i czasu rzeczywistego.
  • Magazyn do odczytu/zapisu (modyfikowalny), który będzie się powtarzać po ponownym uruchomieniu urządzenia. Aby uzyskać informacje na temat magazynu modyfikowalnego, zobacz Używanie magazynu w usłudze Azure Sphere.

Uwaga

Wielokrotnie aktualizując błysk ostatecznie go zużywa i sprawia, że jest on nieprawidłowy. W związku z tym należy zaprojektować kod, aby uniknąć niepotrzebnych aktualizacji flash. Jeśli na przykład chcesz zapisać stan aplikacji przed zamknięciem, aby można było odzyskać zapisany stan po ponownym uruchomieniu, rozważ zapisanie stanu aplikacji na flash tylko wtedy, gdy stan uległ zmianie.

Określanie użycia pamięci flash

Aby określić użycie pamięci flash, rozważ tylko rozmiar pliku pakietu obrazu, który zawiera metadane obrazu, manifest aplikacji i obraz wykonywalny. Nie musisz uwzględniać magazynu wymaganego przez składniki dostarczane przez firmę Microsoft, takie jak system operacyjny usługi Azure Sphere, usługi uruchomieniowe i udostępnione biblioteki kontrolujące urządzenia peryferyjne i umożliwiające nawiązywanie połączenia z usługą Azure IoT Hub. Podobnie nie musisz uwzględniać rozmiaru pełnej kopii zapasowej aplikacji lub składników, które umożliwiają przejście w tryb failover lub wycofanie w przypadku uszkodzenia lub problemów z aktualizacjami za pośrednictwem powietrza.

Jednak podczas programowania i debugowania rozmiar debugera jest liczone względem limitu. Debuger jest automatycznie dodawany przez moduł azsphere device enable-development i usuwany przez polecenie azsphere device enable-cloud-test. Rozmiar debugera używanego przez zestaw SDK można znaleźć, wyszukując plik gdbserver.imagepackage w folderze DebugTools katalogu instalacyjnego zestawu SDK usługi Microsoft Azure Sphere.

Polecenie azsphere device sideload zwraca błąd, jeśli pakiet obrazu aplikacji i debuger (jeśli istnieje) przekroczy limit całkowity 1 MiB. Polecenie azsphere image add --image , które przekazuje nowy obraz do dzierżawy usługi Azure Sphere, zwraca również błąd, jeśli pakiet obrazu przekracza 1 MiB.

Limit 256 pamięci RAM KiB dotyczy samej aplikacji; Nie musisz zezwalać na pamięć RAM używaną przez debuger. Dodatkowa pamięć jest zarezerwowana dla alokacji jądra.

Dostępna pamięć flash i pamięć RAM mogą wzrosnąć (ale nigdy nie spadnie) dla aplikacji napisanych dla bieżącego mikroukładu usługi Azure Sphere (MT3620). Przyszłe mikroukłady usługi Azure Sphere mogą mieć różne limity.

Warunki braku pamięci

Jeśli aplikacja używa zbyt dużej ilości pamięci RAM, system operacyjny usługi Azure Sphere kończy ją sygnałem SIGKILL. Na przykład w debugerze zobaczysz następujące elementy:

Child terminated with signal = 0x9 (SIGKILL)

Sygnał SIGKILL występuje również w przypadku niepowodzenia zakończenia działania aplikacji wysokiego poziomu po odebraniu żądania SIGTERM. Aby uzyskać szczegółowe informacje, zobacz Cykl życia aplikacji .

Aby uniknąć awarii w aplikacji z powodu braku pamięci, zobacz najlepsze rozwiązania dotyczące zarządzania użyciem pamięci RAM w aplikacjach wysokiego poziomu.

Określanie użycia pamięci RAM aplikacji w czasie wykonywania

Usługa Azure Sphere udostępnia kilka funkcji umożliwiających uzyskiwanie informacji o użyciu pamięci w czasie wykonywania. Można ich użyć do monitorowania użycia pamięci aplikacji wysokiego poziomu, co umożliwia bezpieczne ponowne uruchomienie aplikacji, jeśli użycie pamięci przekroczy próg określony w limicie 256 KiB. Dostępne funkcje to:

  • Applications_GetTotalMemoryUsageInKB: pobierz łączne użycie pamięci w kibibajtach. Jest to całkowite użycie pamięci fizycznej aplikacji w systemie, w tym alokacje jądra (takie jak gniazd) w imieniu aplikacji lub serwera debugowania, zwrócone jako wartość nieprzetworzona (w kiB).
  • Applications_GetUserModeMemoryUsageInKB: pobieranie użycia pamięci w trybie użytkownika w kibibajtach. Jest to ilość pamięci fizycznej używanej bezpośrednio przez aplikację, pamięci używanej przez wszystkie biblioteki w jego imieniu (nazywanej również alokacjami anon ) i pamięci używanej przez serwer debugowania, zwracanej jako wartość nieprzetworzona (w kiB).
  • Applications_GetPeakUserModeMemoryUsageInKB: pobieranie szczytowego użycia pamięci w trybie użytkownika w kibibajtach. Jest to maksymalna ilość pamięci użytkownika używanej w bieżącej sesji. Podczas testowania użycia pamięci aplikacji należy upewnić się, że ta wartość nigdy nie przekracza 256 KiB. Ta wartość jest resetowana przy każdym ponownym uruchomieniu aplikacji lub ponownym uruchomieniu. Użyj tej funkcji, aby uzyskać przybliżony wgląd w to, jak blisko aplikacji zbliża się do zalecanego limitu 256 KiB.

Aby użyć tych funkcji w aplikacji wysokiego poziomu, dołącz plik nagłówka applications.h. Te funkcje można używać podczas programowania, aby zrozumieć ogólne użycie pamięci aplikacji, ale można ich również używać razem z rejestrowaniem w celu przechwytywania informacji z urządzeń w terenie. Fragment kodu Wykrywania i oczyszczania pamięci pokazuje, jak wykrywać i bezpiecznie obsługiwać nieoczekiwane użycie pamięci.

Uwaga

Te funkcje zwracają użycie pamięci, jak widać w systemie operacyjnym. Obecnie zwalnianie pamięci przez aplikację do alokacji na stercie użytkownika nie jest zgłaszane przez te funkcje. Pamięć zostanie zwrócona do biblioteki malloc do użytku w przyszłości, ale statystyki zgłaszane przez system operacyjny pozostają niezmienione, chyba że pamięć została przydzielona i zwolniona przez sam system operacyjny. Przykładem może być przydzielanie pamięci dla gniazda. W związku z tym te funkcje są przydatne do zrozumienia scenariuszy najgorszego przypadku, aby pomóc aplikacji działać konserwatywnie w celu zapewnienia maksymalnej niezawodności. Wartości są przybliżone i mogą się różnić w różnych wersjach systemu operacyjnego.

Dodawanie śledzenia alokacji pamięci sterty

Dodatkowe informacje o użyciu pamięci można uzyskać, dodając śledzenie alokacji pamięci sterty, co pokazuje, jakie alokacje użytkowników i jądra są wykonywane przez biblioteki statyczne i dynamicznie połączone. Zapewnia to pełniejszy obraz miejsca, w którym pamięć jest używana przez aplikację, aby pomóc w najbardziej efektywnym użyciu. Ta funkcja, dostępna w systemie operacyjnym Azure Sphere w wersji 21.07 lub nowszej i wersji środowiska uruchomieniowego aplikacji (ARV) 10 lub nowszej, działa tylko na urządzeniu obsługującym programowanie i tylko wtedy, gdy aplikacja nie jest uruchomiona w debugerze.

Uwaga

Aby śledzenie alokacji pamięci sterty działało prawidłowo, należy wykonać oba zadania konfiguracji opisane w tej sekcji. Jeśli tego nie zrobisz, podczas kompilacji zostanie zgłoszone ostrzeżenie, a informacje o pamięci sterta nie będą wyświetlane.

Aby włączyć śledzenie alokacji pamięci sterty, należy wykonać dwie czynności:

  • Dodaj funkcję HeapMemStats do pliku app-manifest.json aplikacji:

      "Capabilities": {
    "HeapMemStats": true
  },

  • Dodaj bibliotekę libmalloc do pakietu obrazów, dodając DEBUG_LIB "libmalloc" polecenie azsphere_target_add_image w pliku CMakeLists.txt aplikacji:

    azsphere_target_add_image_package(${PROJECT_NAME} DEBUG_LIB "libmalloc")

Ważne

Ze względu na to, że śledzenie alokacji pamięci sterty działa tylko na urządzeniach z obsługą programowania, należy wykonać następujące czynności, aby usunąć je z aplikacji przed utworzeniem pakietów obrazów do wdrożenia:

  • Usuń wiersz "HeapMemStats": true" z pliku app-manifest.json aplikacji.
  • Usuń DEBUG_LIB "libmalloc" z azsphere_target_add_image_package(${PROJECT_NAME} DEBUG_LIB "libmalloc" polecenia w pliku CMakeLists.txt aplikacji.

Korzystanie z profilera wydajności programu Visual Studio

Jeśli używasz programu Visual Studio, możesz użyć jej funkcji profilera wydajności, aby uzyskać informacje o użyciu pamięci aplikacji. Aby zapoznać się z samouczkiem korzystającym z tego profilera, zobacz Tutorials/MemoryUsage .

Wymagania wstępne

Uruchamianie profilera użycia pamięci

  1. Wybierz pozycję Debugowanie>profilera wydajności lub naciśnij Alt+F2, aby otworzyć okno uruchamiania profilera wydajności.

    Okno profilera wydajności programu Visual Studio

  2. W obszarze Cel analizy, jeśli profiler urządzeń usługi Azure Sphere nie jest widoczny, wybierz pozycję Wybierz element docelowy i wybierz pozycję Profiler urządzeń usługi Azure Sphere.

  3. W obszarze Dostępne narzędzia upewnij się, że jest zaznaczone pole wyboru Użycie pamięci usługi Azure Sphere, a następnie wybierz pozycję Rozpocznij , aby otworzyć okno profilowania użycia pamięci i uruchomić profiler pamięci.

  4. Jeśli musisz wdrożyć lub ponownie uruchomić aplikację, wybierz pozycję Debuguj>bez debugowania lub naciśnij Ctrl+F5, aby wdrożyć aplikację na urządzeniu.

    Ważne

    Aby uzyskać dokładne informacje o użyciu pamięci RAM dla aplikacji, ważne jest, aby [uruchomić aplikację bez debugowania](buid-hl-app.md#build-and-deploy-the-application-in- visual-studio-without-debug). Uruchomienie aplikacji w debugerze spowoduje zawyżone użycie pamięci RAM, ponieważ pamięć zużywana przez serwer debugowania zostanie uwzględniona w zgłoszonych statystykach użycia pamięci RAM.

Interpretowanie danych profilera użycia pamięci

W oknie profilowania użycia pamięci zostanie wyświetlony widok podobny do następującego:

Okno profilera użycia pamięci programu Visual Studio

W środku widoku wykres pamięci fizycznej urządzenia usługi Azure Sphere przedstawia trzy różne statystyki użycia pamięci RAM (pokazane najbliżej kiB) jako trzy różne wiersze podczas działania aplikacji:

  • Suma: całkowite użycie pamięci fizycznej aplikacji w systemie, w tym alokacje jądra (takie jak gniazd) w imieniu aplikacji lub serwera debugowania.
  • Użytkownik: ilość pamięci fizycznej używanej bezpośrednio przez aplikację, pamięć używana przez wszystkie biblioteki w jego imieniu (nazywana również alokacjami anon ) i pamięć używana przez serwer debugowania.
  • Szczytowy użytkownik: maksymalna ilość pamięci użytkownika używanej w bieżącej sesji. Podczas testowania użycia pamięci aplikacji należy upewnić się, że ta wartość nigdy nie przekracza 256 KiB. Dodatkowa pamięć jest zarezerwowana dla alokacji jądra. Ta wartość jest resetowana przy każdym ponownym uruchomieniu aplikacji lub ponownym uruchomieniu.

Wykres przedstawia również wystąpienia zdarzenia New Peak (reprezentowane przez trójkąt). To zdarzenie występuje zawsze, gdy istnieje nowa maksymalna wartość dla szczytowego użycia pamięci użytkownika. Zdarzenie jest włączone dla ułatwień dostępu czytnika zawartości ekranu.

Jeśli włączono śledzenie alokacji pamięci sterty i aplikacja nie działa w debugerze, zostanie wyświetlony dodatkowy wykres przedstawiający statystyki pamięci sterty:

  • Łączna sterta: łączna ilość pamięci stert przydzielonej przez aplikację lub w jej imieniu, w tym z bibliotek statycznych i dynamicznych.
  • Sterta bibliotek udostępnionych: alokacje z dynamicznie połączonych bibliotek udostępnianych przez system operacyjny usługi Azure Sphere.

Użycie pamięci stertowej programu Visual Studio

Nad wykresami widok osi czasu wyświetla czas wykonywania aplikacji, skorelowany z danymi na wykresie poniżej. Użyj powiększenia i pomniejszania , aby skupić się na określonych okresach czasu.

Poniżej wykresów widok tabeli wyświetla te same statystyki i zdarzenia pamięci.

Napiwek

Aby skopiować dane z tabeli do schowka, naciśnij Ctrl+A , aby zaznaczyć wszystkie wiersze, a następnie naciśnij Ctrl+C.

Pierwsze dwa wykresy pokazane w tej sekcji zostały wykonane podczas uruchamiania etapu 1 samouczka Użycie pamięci, który zawiera przeciek pamięci. Użycie pamięci wspina się monotonicznie w każdym grafie, zapewniając wizualne dowody na wyciek. Gdy wyciek zostanie naprawiony, podobnie jak w etapie 2 samouczka Użycie pamięci, wykres rośnie i spada w miarę przydzielania i cofania przydziału pamięci.

Użycie pamięci stertowej programu Visual Studio bez przecieku pamięci

Wyświetlanie statystyk dotyczących całkowitego użycia pamięci

Polecenie azsphere device app show-memory-stats zwraca statystyki użycia pamięci dotyczące całkowitego użycia pamięci, użycia trybu użytkownika i szczytowego użycia trybu użytkownika dla aplikacji uruchomionych na dołączonym urządzeniu. Urządzenie musi mieć funkcję appDevelopment urządzenia skonfigurowaną do uruchamiania tego polecenia.

Statystyki użycia pamięci RAM wyświetlane podczas działania aplikacji to:

  • Total (Kernel + User Mode): Łączne użycie pamięci fizycznej aplikacji w systemie, w tym alokacje jądra (takie jak dla gniazd) w imieniu aplikacji lub serwera debugowania.
  • Tryb użytkownika: ilość pamięci fizycznej używanej bezpośrednio przez aplikację, pamięć używana przez wszystkie biblioteki w jego imieniu (nazywana również alokacjami anon ) i pamięć używana przez serwer debugowania.
  • Tryb szczytowego użytkownika: maksymalna ilość pamięci użytkownika używanej w bieżącej sesji. Podczas testowania użycia pamięci aplikacji należy upewnić się, że ta wartość nigdy nie przekracza 256 KiB. Dodatkowa pamięć jest zarezerwowana dla alokacji jądra. Ta wartość jest resetowana przy każdym ponownym uruchomieniu aplikacji lub ponownym uruchomieniu.

Jeśli włączono śledzenie alokacji pamięci sterty i aplikacja nie działa w debugerze, zobaczysz dodatkowe wiersze statystyk pamięci sterty:

  • Sterta: Aplikacje i biblioteki statyczne: jądro i alokacja użytkownika z kodu i wszystkich bibliotek statycznie połączonych z nim.
  • Sterta: <alokacje biblioteki dynamicznej: alokacje> z poszczególnych dynamicznie połączonych bibliotek udostępnianych przez system operacyjny usługi Azure Sphere.

Ciągłe monitorowanie użycia pamięci

Aby monitorować użycie pamięci w czasie, możesz użyć skryptów do uruchomienia polecenia azsphere device app show-memory-stats w pętli, jak opisano w poniższych przykładach:

Wiersz polecenia systemu Windows

Za pomocą Notatnika lub innego edytora tekstów utwórz plik skryptu wsadowego memuse.bat z następującą zawartością:

@echo off

:loop
call azsphere device app show-memory-stats
choice /d y /t 1 > nul
goto loop

Uruchom skrypt wsadowy, wpisując jego nazwę w wierszu polecenia (lub pełną ścieżkę do pliku, jeśli nie znajduje się w bieżącym katalogu):

C:\Users\username> memuse.bat
 -------------------------- -------------
 Name                       Usage (bytes)
 ========================================
 Total (Kernel + User Mode) 65536
 -------------------------- -------------
 User Mode                  36864
 -------------------------- -------------
 Peak User Mode             36864
 -------------------------- -------------
 -------------------------- -------------
 Name                       Usage (bytes)
 ========================================
 Total (Kernel + User Mode) 65536
 -------------------------- -------------
 User Mode                  36864
 -------------------------- -------------
 Peak User Mode             36864
 -------------------------- -------------

Aby zakończyć działanie skryptu, wpisz ctrl+C w oknie wiersza polecenia , a następnie odpowiedz Y na monit "Zakończ zadanie wsadowe?".

Windows PowerShell

while ($true) {
    azsphere device app show-memory-stats
    Start-Sleep -Seconds 1
}

Użycie pamięci i debuger

Podczas uruchamiania aplikacji w debugerze zgłoszone statystyki pamięci obejmują również użycie pamięci procesu debugowania serwera i inne dodatkowe użycie pamięci spowodowane przez debugowanie, takie jak ustawianie punktów przerwania. Z tego powodu należy zawsze uruchamiać aplikację bez debugowania podczas próby zebrania dokładnych statystyk pamięci.

Jednak użycie profilera użycia pamięci może być przydatne, jeśli uruchamiasz aplikację z debugerem. Ustawianie punktów przerwania i przechodzenie przez wiersze kodu podczas obserwowania względnych zmian zużycia pamięci może być przydatną techniką identyfikowania przyczyn skoków użycia pamięci lub przecieków pamięci.

Podczas debugowania w programie Visual Studio profiler wydajności jest otwierany automatycznie, ale nie wyświetla śledzenia alokacji pamięci sterty.