Differences
This shows you the differences between two versions of the page.
|
ep:labs:09:contents:tasks:ex1 [2021/12/04 20:06] andrei.mirciu [01. [30p] RAM Monitoring] |
ep:labs:09:contents:tasks:ex1 [2023/10/21 14:45] (current) cezar.craciunoiu [01. [30p] RAM Monitoring] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ==== 01. [30p] RAM Monitoring ==== | ==== 01. [30p] RAM Monitoring ==== | ||
| + | |||
| + | === RAM Investigation === | ||
| <note warning> | <note warning> | ||
| Line 9: | Line 11: | ||
| :!: Using **VMMap**, inspect the memory spikes generated by running the same program. | :!: Using **VMMap**, inspect the memory spikes generated by running the same program. | ||
| - | :!: Finally, after installing [[https://marketplace.visualstudio.com/items?itemName=ArkadyShapkin.VisualLeakDetectorforVisualC | Visual Leak Detector]] and including the //vld.h// file to the program, inspect where the allocation took place. What do you observe? | + | <hidden> |
| + | * It can be noticed the steep line representing the increase of our process's memory usage. This leads to the conclusion that this process is the cause of the problem since all the other ones seem stable. | ||
| + | * So far, it was identified the process that causes problems. If this process is not written by you, you can check who is launching it. If you don't need it, you can deactivate it. If you need it, check if there are any updates to fix it. If there aren't any updates to fix the problem, you can try reporting the problem to the producer and hope they will fix it. | ||
| + | </hidden>⠀ | ||
| - | <note tip> | + | === RAM Cleaning === |
| - | Follow these steps to run the **Visual Leak Detector (VLD)** successfully: | + | |
| - | - From Visual Studio, navigate to the Solution Explorer window, right click on the project name and select //Properties//. | + | |
| - | - From //Configuration Properties// menu, select the //VC++ Directories// option and go to the //Include Directories// field. Here, you should add the correct path from your machine pointing to the //include// directory inside the VLD installation directory (it should look like //C:\Program Files (x86)\Visual Leak Detector\include//). | + | |
| - | - From //Configuration Properties// menu, select the //Linker// option and go to the //Input// -> //Additional Dependencies// field. Here, you should add the correct path pointing to the //vld.lib// file (it should look like //C:\Program Files (x86)\Visual Leak Detector\lib\Win32\vld.lib//). | + | |
| - | - From the same //Linker// option, navigate to //Debugging// and you will observe the //Generate Debug Info// field. Here, you need to select //Generate Debug Information optimized for sharing and publishing (/DEBUG:FULL)//. | + | |
| + | <note warning> | ||
| + | For this task we will a tool called **RAMMap**. Download it from [[https://learn.microsoft.com/en-us/sysinternals/downloads/rammap | Microsoft]]. | ||
| </note> | </note> | ||
| - | <note> | + | Previously we identified that a given program allocated memory and did not free it, which started exhausting our resources. |
| - | When writing the code, the following functions need to be overwritten: malloc, free, new, and delete. This allows each memory allocation and deallocation to be tracked. All the detected leakages (having an allocation that is not followed by a deallocation) will be saved in a log file that can be viewed after the program stops running. | + | If we still want to run that program, and we do not want to leave it running uninterrupted, we can try "cleaning" our RAM memory during its execution and hope that it helps. |
| - | </note> | + | Similar with Linux, where we drop caches, in Windows we can use a tool called **RAMMap** to inspect our memory in detail and free space in RAM. |
| - | <hidden> | + | |
| - | * It can be noticed the steep line representing the increase of our process's memory usage. This leads to the conclusion that this process is the cause of the problem since all the other ones seem stable. | + | :!: **After starting the program you should see something similar to the image below.** |
| - | * So far, it was identified the process that causes problems. If this process is not written by you, you can check who is launching it. If you don't need it, you can deactivate it. If you need it, check if there are any updates to fix it. If there aren't any updates to fix the problem, you can try reporting the problem to the producer and hope they will fix it. | + | |
| - | </hidden>⠀ | + | {{ :ep:laboratoare:ep9_ex1_2.png?500 |}} |
| + | |||
| + | Let's now try to use RAMMap to free memory. | ||
| + | In the document you can add just two images, a before-after of running all empty routines. | ||
| + | Follow the steps below: | ||
| + | |||
| + | <note tip> | ||
| + | - Start RAMMap and position it on the left side of your screen | ||
| + | - Start Task Manager and position it on the right side of your screen | ||
| + | - Start several applications to get your RAM up to at least ~70% | ||
| + | - From the highlighted **Empty** tab, run every empty routine from top to bottom and inspect the total in Task Manager | ||
| + | </note> | ||
| + | |||
| + | <solution -hidden> | ||
| + | There is a chance some of them will not see differences after 1-2 runs. | ||
| + | Ask them to reopen the Memory-Heavy applications. | ||
| + | </solution> | ||
| + | |||
| + | :!: Sounds good, but what is a disadvantage of cleaning our RAM too often? Think about performance. | ||
| + | |||
| + | <solution -hidden> | ||
| + | Cleaning too often is similar to swapping all our unused data. | ||
| + | The system will have to fetch the data back from the disk. | ||
| + | </solution> | ||
