One of the setbacks to using GNS3 is the CPU usage. Even if your computer is using a multicore processor and running Windows 64 bit OS with 8 GB of memory a small lab can send your CPU usage to 100%. If you are creating a lab with a large number of routers this will cause your computer to become very sluggish and may even cause the GNS3 application to become unresponsive due to the memory usage and CPU usage. These issues may be resolved with the following GNS3 options:
Large topologies with numerous routing and switching devices may consume a large quantity of real and virtual memory. The “ghostios” and “sparemem” options have been included in GNS3 to help resolve these two annoying issues, respectively.
The Ghostios option could considerably lower the amount of actual host RAM needed for laboratories with a number of routers running the same IOS picture. With this function, instead of each virtual device saving the same copy of iOS in its virtual RAM, the host will certainly allocate one shared region of memory that all devices will utilize. So for example, if you are running 10 routers all with the same iOS, which is 60 MB in size you will conserve 9 * 60 = 540 MEGABYTES of actual RAM when running your lab topology. In GNS3 the Ghostios option is enabled by default.
The “sparsemem” function does not preserve actual memory, yet rather minimizes the amount of virtual memory consumed by each router instance. This can be important, seeing that your OS limits a solitary procedure to 2 GB of virtual memory on 32-bit Windows, and 3 GB on 32-bit Linux. Allowing sparsemem simply designates virtual memory on the host that is really utilized by the iOS in that router circumstances, rather than the whole amount of RAM set up. This can allow you to run additional circumstances. In GNS3 the Sparsemem option is enabled by default.
As we reviewed earlier large complex lab topologies can trigger excessive CPU Usage. This is due to Dynamips, the center emulator running beneath GNS3 interface, does not recognize when the virtual router is idle, and when it is doing actual work. The “idlepc” command executes an evaluation on a running image to establish the most likely factors in the code that represent an idle loop within the iOS process. When implemented, Dynamips places the virtual router periodically in a sleep state when this idle loop is performed. This considerably decreases CPU usage on the host without decreasing the virtual router’s ability to perform actual work.
Idle PC values are specific to an iOS image. They will be unique for each IOS versions, as well as different feature-sets of the same iOS version. Although idlepc values are not unique to the host PCs operating system, or to the revision of Dynamips that GNS3 is running. It is possible that Dynamips will not be capable finding and idlepc value for a particular iOS image, or that the values it finds will not work optimally. If this occurs, use the host performance monitor and repeat the process until you have found the lowest CPU utilization.