With ps
or similar tools you will only get the amount of memory pages allocated by that process. This number is correct, but:
does not reflect the actual amount of memory used by the application, only the amount of memory reserved for it
can be misleading if pages are shared, for example by several threads or by using dynamically linked libraries
If you really want to know what amount of memory your application actually uses, you need to run it within a profiler. For example, Valgrind can give you insights about the amount of memory used, and, more importantly, about possible memory leaks in your program. The heap profiler tool of Valgrind is called 'massif':
Massif is a heap profiler. It performs detailed heap profiling by taking regular snapshots of a program's heap. It produces a graph showing heap usage over time, including information about which parts of the program are responsible for the most memory allocations. The graph is supplemented by a text or HTML file that includes more information for determining where the most memory is being allocated. Massif runs programs about 20x slower than normal.
As explained in the Valgrind documentation, you need to run the program through Valgrind:
valgrind --tool=massif <executable> <arguments>
Massif writes a dump of memory usage snapshots (e.g. massif.out.12345
). These provide, (1) a timeline of memory usage, (2) for each snapshot, a record of where in your program memory was allocated. A great graphical tool for analyzing these files is massif-visualizer. But I found ms_print
, a simple text-based tool shipped with Valgrind, to be of great help already.
To find memory leaks, use the (default) memcheck
tool of valgrind.
Best Answer
You didn't specify which OS, but I can at least speak for Linux:
It may depend on your kernel, NIC and driver as well as ethtool versions.
We need to tell the driver/hardware to do two things it doesn't normally do:
There are two ethtool options to achieve each of these:
With these, I am able to use wireshark or tcpdump to view FCS fields, even if they are not correct. (in my case I have some network device that replaces the checksum on-the-fly with an accurate timestamp - which causes the packets to appear 'bad', and I use the above to recover)
Not all cards will implement this! They may have the above ethtool options 'fixed' off or not respond to them.
At 1G speeds I've seen e1000 cards work well. At 10G I am yet to find a NIC that does this at all, and have to rely on more complex data acquisition cards.
Again, I don't know what the minimum kernel/ethtool version requirements are, but I do recall having to upgrade a CentOS server in order to get it to work.
I also know that r8169 and e1000 drivers/cards can do it, but can't speak for any other combination at all.
Also note you won't be able to capture outgoing FCS values on the machine you're sending them because they're added quite late in the process (perhaps offloaded to the card itself) so will not be visible to pcap.
On a Linux 3.10.11 kernel, with ethtool 3.10:
And then:
Gives me: