Feilsøking av GNS3-ytelse

Av | november 9, 2021

Et av tilbakeslagene ved bruk av GNS3 er CPU-bruk. Selv om datamaskinen din bruker en flerkjerneprosessor og kjører et 64-bits Windows-operativsystem med 8 GB minne, kan et lite laboratorium sende 100 % CPU-bruk. Hvis du oppretter et laboratorium med et stort antall rutere, vil dette føre til at datamaskinen din blir veldig treg og kan til og med føre til at GNS3-applikasjonen ikke reagerer på grunn av minne og CPU-bruk. Disse problemene kan løses med følgende GNS3-alternativer:

Minnebruk:

Store topologier med mange ruting- og svitsjeenheter kan forbruke en stor mengde ekte og virtuelt minne. Alternativene «ghostios» og «sparemem» er inkludert i GNS3 for å hjelpe til med å løse henholdsvis disse to irriterende problemene.

Ghostios:

Ghostios-alternativet kan betydelig redusere mengden faktisk verts-RAM som kreves for laboratorier med en rekke rutere med samme IOS-bilde. Med denne funksjonen, i stedet for at hver virtuell enhet lagrer den samme kopien av iOS til den virtuelle RAM-en, vil verten tildele et delt minneområde som alle enhetene vil bruke. Så, for eksempel, hvis du bruker 10 rutere alle med samme iOS, som har en størrelse på 60 MB, vil du beholde 9 * 60 = 540 MEGABYTES ekte RAM når du kjører lab-topologien. I GNS3 er Ghostios-alternativet aktivert som standard.

Sparsemem:

«sparsemem»-funksjonen sparer ikke ekte minne, men minimerer mengden virtuelt minne som forbrukes av hver ruterforekomst. Dette kan være viktig, ettersom operativsystemet ditt begrenser en ensom prosedyre til 2 GB virtuelt minne på 32-biters Windows og 3 GB på 32-biters Linux. Å tillate sparsemem utpeker ganske enkelt det virtuelle minnet til verten som iOS faktisk bruker under disse ruterforholdene, i stedet for hele mengden RAM som er konfigurert. Dette kan tillate deg å kjøre ytterligere omstendigheter. I GNS3 er Sparsemem-alternativet aktivert som standard.

CPU bruk:

Som vi har gjennomgått tidligere, kan store komplekse laboratorietopologier føre til overdreven CPU-bruk. Dette er fordi Dynamips, den sentrale emulatoren som kjører under GNS3-grensesnittet, ikke gjenkjenner når den virtuelle ruteren er inaktiv og når den gjør virkelig arbeid. Kommandoen «idlepc» kjører en evaluering på et kjørende bilde for å etablere de mest sannsynlige kodefaktorene som representerer en inaktiv sløyfe i iOS-prosessen. Når den er implementert, plasserer Dynamips den virtuelle ruteren med jevne mellomrom i hvile når denne tomgangsløkken utføres. Dette reduserer CPU-bruken betraktelig til verten uten å redusere muligheten til den virtuelle ruteren til å utføre selve arbeidet.

Inaktiv PC:

Inaktive PC-innstillinger er spesifikke for et iOS-bilde. De vil være unike for hver versjon av iOS, samt forskjellige funksjonssett fra samme versjon av iOS. Selv om idlepc-verdier ikke er unike for vertsdatamaskinens operativsystem eller Dynamips hurtigreparasjonen som kjører GNS3. Dynamips kan kanskje ikke finne og idlepc-verdien for et bestemt iOS-bilde, eller verdiene den finner fungerer kanskje ikke optimalt. Hvis dette skjer, bruk vertytelsesmonitoren og gjenta prosessen til du har funnet den laveste CPU-bruken.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *