[Question] How can I analyze the following memory footprint?

[maxgalbu]

location_type                            count  memory_usage
=============                            =====  ============
ZendOpArrayBodyMemoryLocation            964    758080
ZendStringMemoryLocation                 8396   628116
ZendArrayTableMemoryLocation             515    299768
ZendOpArrayHeaderMemoryLocation          998    239520
ZendArrayTableOverheadMemoryLocation     467    125280
ZendArgInfosMemoryLocation               811    50976
ZendClassEntryMemoryLocation             80     39680
ZendArrayMemoryLocation                  412    23072
ZendObjectMemoryLocation                 158    22512
RuntimeCacheMemoryLocation               254    22176
LocalVariableNameTableMemoryLocation     804    16040
ObjectsStoreMemoryLocation               1      8192
ZendPropertyInfoMemoryLocation           118    6608
CallFrameVariableTableMemoryLocation     12     6528
DefaultPropertiesTableMemoryLocation     36     1584
DynamicFuncDefsTableMemoryLocation       91     1104
CallFrameHeaderMemoryLocation            13     1040
DefaultStaticMembersTableMemoryLocation  11     464
StaticMembersTableMemoryLocation         10     416
ZendReferenceMemoryLocation              3      96

What is a possible command that can help me find some more info on these data?

[sj-i]

@maxgalbu Hi!

From the output, the total size of the top 20 memory consuming types of locations is 2,251,252 bytes at the time of the analysis.

First, consider whether this approximately 2 MB of information is likely to be useful to you. If you are convinced that you have a memory problem of a much larger size, you may really need a memory analysis at a different timing, or Reli may not be getting the information you want to know, or the analyzed process was the wrong process.

General questions

• What is your purpose of the analysis? Finding memory bottlenecks for performance tuning, or finding the cause of a memory leaks?
• If you are convinced that the target process leaks memory, how are you convinced it?
• In what timing did you use Reli?
• What application runtime do you use? php-fpm, or mod_php?

Getting the summary

You should first see the summary. This summary gives you an rough idea of how useful the output is to you. The output would be like the below.

[
  {
    "zend_mm_heap_total": 536285184,
    "zend_mm_heap_usage": 400364587,
    "zend_mm_chunk_total": 283115520,
    "zend_mm_chunk_usage": 261628896,
    "zend_mm_huge_total": 253169664,
    "zend_mm_huge_usage": 138735691,
    "vm_stack_total": 262144,
    "vm_stack_usage": 10512,
    "compiler_arena_total": 1638400,
    "compiler_arena_usage": 1550992,
    "possible_allocation_overhead_total": 17044713,
    "possible_array_overhead_total": 82895216,
    "memory_get_usage": 533571712,
    "memory_get_real_usage": 536285184,
    "cached_chunks_size": 0,
    "heap_memory_analyzed_percentage": 75.03482249823618,
    "php_version": "v82",
    "analyzer": "reli 0.11.2"
  }
]

Look at "memory_get_usage" and "memory_get_real_usage". If they are much smaller than the memory usage you expected through ps or top commands, the target process may be using a lot of memory in areas outside ZendMM. This is an area that current Reli does not handle very well. So if you are interested in this area, use php-memprof, or massif with an experienced C programmer. If both the memory usage reported by Reli and ps or top commands are below your expectation, then the timing of the analysis or the target process can be wrong.

Also, one of the important fields is "heap_memory_analyzed_percentage". The closer this number is to 100, the better Reli knows the memory usage of the target process. Conversely, if it is closer to 0, Reli does not know much about the memory usage of the target process. Then it may be more fruitful to look for other analysis methods. You've once mentioned Phalcon in another issue. I don't know about phalcon well, but Reli currently doesn't support extracting information in the instance of internal classes provided by extensions, so I'm not confident that Reli can analyze the application built on Phalcon well enough.

[maxgalbu]

thanks for the help. I fixed the memory leak by manually commenting part of code. Phalcon was the culprit so it was impossible to spot using reli-prof