Mengatasi Masalah Kinerja GNS3

Salah satu kemunduran dalam menggunakan GNS3 adalah penggunaan CPU. Meskipun komputer Anda menggunakan prosesor multicore dan menjalankan OS Windows 64 bit dengan memori 8 GB, lab kecil dapat mengirim penggunaan CPU Anda hingga 100%. Jika Anda membuat lab dengan banyak router, ini akan menyebabkan komputer Anda menjadi sangat lamban dan bahkan dapat menyebabkan aplikasi GNS3 menjadi tidak responsif karena penggunaan memori dan penggunaan CPU. Masalah ini dapat diselesaikan dengan opsi GNS3 berikut:

Penggunaan memori:

Topologi besar dengan banyak perutean dan perangkat switching dapat menghabiskan banyak memori nyata dan virtual. Opsi “ghostios” dan “sparemem” telah disertakan dalam GNS3 untuk membantu menyelesaikan dua masalah yang mengganggu ini.

Ghostios:

Opsi Ghostios dapat sangat menurunkan jumlah RAM host aktual yang diperlukan untuk laboratorium dengan sejumlah router yang menjalankan gambar IOS yang sama. Dengan fungsi ini, alih-alih setiap perangkat virtual menyimpan salinan iOS yang sama di RAM virtualnya, host pasti akan mengalokasikan satu wilayah memori bersama yang akan digunakan semua perangkat. Jadi misalnya, jika Anda menjalankan 10 router semua dengan iOS yang sama, yang berukuran 60 MB, Anda akan menghemat 9 * 60 = 540 MEGABYTES RAM aktual saat menjalankan topologi lab Anda. Di GNS3, opsi Ghostios diaktifkan secara bawaan.

Sparsemem:

Fungsi “sparsemem” tidak mempertahankan memori sebenarnya, namun meminimalkan jumlah memori virtual yang digunakan oleh setiap instance router. Ini bisa menjadi penting, mengingat OS Anda membatasi prosedur soliter menjadi 2 GB memori virtual pada Windows 32-bit, dan 3 GB pada Linux 32-bit. Mengizinkan sparsemem hanya menunjukkan memori virtual pada host yang benar-benar digunakan oleh iOS dalam keadaan router tersebut, bukan seluruh jumlah RAM yang disiapkan. Ini dapat memungkinkan Anda menjalankan keadaan tambahan. Di GNS3 opsi Sparsemem diaktifkan secara default.

Penggunaan CPU:

Seperti yang kita ulas sebelumnya, topologi lab kompleks yang besar dapat memicu Penggunaan CPU yang berlebihan. Ini karena Dynamips, emulator pusat yang berjalan di bawah antarmuka GNS3, tidak mengenali saat router virtual tidak aktif, dan saat sedang melakukan pekerjaan sebenarnya. Perintah “idlepc” menjalankan evaluasi pada gambar yang sedang berjalan untuk menetapkan faktor yang paling mungkin dalam kode yang mewakili loop idle dalam proses iOS. Saat diimplementasikan, Dynamips menempatkan router virtual secara berkala dalam kondisi tidur saat loop idle ini dilakukan. Ini sangat mengurangi penggunaan CPU pada host tanpa mengurangi kemampuan router virtual untuk melakukan pekerjaan yang sebenarnya.

PC menganggur:

Nilai PC menganggur khusus untuk gambar iOS. Mereka akan unik untuk setiap versi IOS, serta set fitur yang berbeda dari versi iOS yang sama. Meskipun nilai idlepc tidak unik untuk sistem operasi PC host, atau untuk revisi Dynamips yang sedang dijalankan GNS3. Ada kemungkinan bahwa Dynamips tidak akan mampu menemukan dan nilai idlepc untuk gambar iOS tertentu, atau nilai yang ditemukannya tidak akan bekerja secara optimal. Jika ini terjadi, gunakan monitor kinerja host dan ulangi prosesnya hingga Anda menemukan penggunaan CPU yang paling rendah.

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *