As we later found out, it is much faster to leave out the cut command during data acquisition, then perform the cut command on the output file later.Īlso, we had no need for timestamps in our tests.īegin Logging: top -bd 0.1 | grep 'KiB Mem' | tee memory_raw.txtĢ levels of cut (filtering), first by comma, then by space. It does turn out that piping through cut cause MASSIVE delay in getting anything out to file. In my case I wanted to use top also because you can run memory stats faster than 1 second per capture, as you can see here I wanted to capture a stat every 1/10th of a second. The user can indeed modify the 0.1 to another number in order to run different capture sample rates. The standard output from top when grep ing with Kib Mem is: KiB Mem : 16047368 total, 8708172 free, 6015720 used, 1323476 buff/cacheīy running this through cut, we filter down to literally just the number prior to used

OR: top -bd 0.1 | grep 'KiB Mem' | cut -d' ' -f10 | tee memory.txt So here is the answer that I came up with: top -bd 0.1 | grep 'KiB Mem' | cut -d' ' -f10 > memory.txt all will seem to output without excess filtering. Public static void main(String.So I know that I am late to this game, but I just came up with this answer, as I needed to do this, and really didn't want the extra fields that vmstat, free, etc. When the same process later has a low CPU utilization or is in sleep state this value will decrease. If the process starts and has a high CPU utilization, then the

CPU usage is unlikely to add up to exactly 100%. This is not ideal, and it does not conform to the standards that ps otherwise conforms to. CPU usage is currently expressed as the percentage of time spent running during the entire lifetime of a process.

Linux monitor cpu and memory usage