measure memory consumption in an Erlang system
原文地址：
http://erlang.org/faq/how_do_i.html#5.15
Memory consumption is a bit of a tricky issue in Erlang. Usually, you don't need to worry about it because the garbage collector looks after memory management for you. But, when things go wrong, there are several sources of information. Starting from the most general:
Some operating systems provide detailed information about process memory use with tools like top, ps or the linux /proc filesystem:
cat /proc/5898/status
VmSize: 7660 kB
VmLck: 0 kB
VmRSS: 5408 kB
VmData: 4204 kB
VmStk: 20 kB
VmExe: 576 kB
VmLib: 2032 kB
This gives you a rock-solid upper-bound on the amount of memory the entire Erlang system is using.
erlang:system_info reports interesting things about some globally allocated structures in bytes:
3> erlang:system_info(allocated_areas).
[{static,390265},
{atom_space,65544,49097},
{binary,13866},
{atom_table,30885},
{module_table,944},
{export_table,16064},
{register_table,240},
{loaded_code,1456353},
{process_desc,16560,15732},
{table_desc,1120,1008},
{link_desc,6480,5688},
{atom_desc,107520,107064},
{export_desc,95200,95080},
{module_desc,4800,4520},
{preg_desc,640,608},
{mesg_desc,960,0},
{plist_desc,0,0},
{fixed_deletion_desc,0,0}]
Information about individual processes can be obtained from erlang:process_info/1 or erlang:process_info/2:
2> erlang:process_info(self(), memory).
{memory,1244}
The shell's i() and the pman tool also give useful overview information.
Don't expect the sum of the results from process_info and system_info to add up to the total memory use reported by the operating system. The Erlang runtime also uses memory for other things.
A typical approach when you suspect you have memory problems is
1. Confirm that there really is a memory problem by checking that memory use as reported by the operating system is unexpectedly high.
2. Use pman or the shell's i() command to make sure there isn't an out-of-control erlang process on the system. Out-of-control processes often have enormous message queues. A common reason for Erlang processes to get unexpectedly large is an endlessly looping function which isn't tail recursive.
3. Check the amount of memory used for binaries (reported by system_info). Normal data in Erlang is put on the process heap, which is garbage collected. Large binaries, on the other hand, are reference counted. This has two interesting consequences. Firstly, binaries don't count towards a process' memory use. Secondly, a lot of memory can be allocated in binaries without causing a process' heap to grow much. If the heap doesn't grow, it's likely that there won't be a garbage collection, which may cause binaries to hang around longer than expected. A strategically-placed call to erlang:garbage_collect() will help.
4. If all of the above have failed to find the problem, start the Erlang runtime system with the -instr switch.
Memory consumption is a bit of a tricky issue in Erlang. Usually, you don't need to worry about it because the garbage collector looks after memory management for you. But, when things go wrong, there are several sources of information. Starting from the most general:
Some operating systems provide detailed information about process memory use with tools like top, ps or the linux /proc filesystem:
cat /proc/5898/status
VmSize: 7660 kB
VmLck: 0 kB
VmRSS: 5408 kB
VmData: 4204 kB
VmStk: 20 kB
VmExe: 576 kB
VmLib: 2032 kB
This gives you a rock-solid upper-bound on the amount of memory the entire Erlang system is using.
erlang:system_info reports interesting things about some globally allocated structures in bytes:
3> erlang:system_info(allocated_areas).
[{static,390265},
{atom_space,65544,49097},
{binary,13866},
{atom_table,30885},
{module_table,944},
{export_table,16064},
{register_table,240},
{loaded_code,1456353},
{process_desc,16560,15732},
{table_desc,1120,1008},
{link_desc,6480,5688},
{atom_desc,107520,107064},
{export_desc,95200,95080},
{module_desc,4800,4520},
{preg_desc,640,608},
{mesg_desc,960,0},
{plist_desc,0,0},
{fixed_deletion_desc,0,0}]
Information about individual processes can be obtained from erlang:process_info/1 or erlang:process_info/2:
2> erlang:process_info(self(), memory).
{memory,1244}
The shell's i() and the pman tool also give useful overview information.
Don't expect the sum of the results from process_info and system_info to add up to the total memory use reported by the operating system. The Erlang runtime also uses memory for other things.
A typical approach when you suspect you have memory problems is
1. Confirm that there really is a memory problem by checking that memory use as reported by the operating system is unexpectedly high.
2. Use pman or the shell's i() command to make sure there isn't an out-of-control erlang process on the system. Out-of-control processes often have enormous message queues. A common reason for Erlang processes to get unexpectedly large is an endlessly looping function which isn't tail recursive.
3. Check the amount of memory used for binaries (reported by system_info). Normal data in Erlang is put on the process heap, which is garbage collected. Large binaries, on the other hand, are reference counted. This has two interesting consequences. Firstly, binaries don't count towards a process' memory use. Secondly, a lot of memory can be allocated in binaries without causing a process' heap to grow much. If the heap doesn't grow, it's likely that there won't be a garbage collection, which may cause binaries to hang around longer than expected. A strategically-placed call to erlang:garbage_collect() will help.
4. If all of the above have failed to find the problem, start the Erlang runtime system with the -instr switch.