php-meminfo
php-meminfo copied to clipboard
BitOne
Provide a way to find memory leak when cause is lot of primitive data types
So here's a top of summary table:
+------------------------------------------------------------+-----------------+-----------------------------+
| Type | Instances Count | Cumulated Self Size (bytes) |
+------------------------------------------------------------+-----------------+-----------------------------+
| string | 1494183 | 39037387 |
| array | 117970 | 8493840 |
| null | 88943 | 1423088 |
| boolean | 4683 | 74928 |
| integer | 2339 | 37424 |
| ReflectionProperty | 460 | 33120 |
| Doctrine\ORM\Mapping\Column | 370 | 26640 |
| Everlution\SearchBundle\Model\Builder\Field | 317 | 22824 |
| Everlution\SearchBundle\Model\Builder\FieldType\StringType | 237 | 17064 |
| Closure | 169 | 12168 |
+------------------------------------------------------------+-----------------+-----------------------------+
As you see, string takes most of the memory, not any class. README does not provide info on how to deal with such problem. How to proceed? I've looked into json file, I searched there for biggest strings, but found those which are big are not the issue. Memory is probably taken by lot of smaller strings.
Dump attached meminfo.json.tar.gz
Hey @ostrolucky ,
I'm thinking of adding an option to dump the content of each string (up to a limit of n characters) in the json file.
Would that help ?
Hi @BitOne, I have a similar problem where it reports mostly primitives types:
| Type | Instances Count | Cumulated Self Size (bytes) |
+--------------------------------------------+-----------------+-----------------------------+
| string | 176746 | 8485871 |
| null | 2321 | 37136 |
| array | 77 | 5544 |
| integer | 48 | 768 |
| boolean | 29 | 464 |
| stdClass | 16 | 1152 |
| unknown | 11 | 176 |
| resource | 4 | 64 |
| float | 4 | 64 |
Do you still have plans to output first chars of string types with php-meminfo? Many thanks
Maybe this is a bug. Those scalars were held in an array which is held in logger class, so this class should be at the top imho.
Hi @guenard and @ostrolucky ,
It makes sense that it's the logger. And @ostrolucky , it's not really a bug that this single logger class is not at the top, as the size is only the self size (aka exclusive size), that is the size of the class, and not the size of the items that are inside this class (aka inclusive size). So it's not really a bug.
And yes, that would be nice to have the inclusive size as well. It's not that easy to compute, as a single object or array can be shared between different classes, by using reference for example. Then what object is the real owner of the size?
Same thing with circular references between objects. Which one of the object inside the circular reference loop is the "owner" of the size?
Anyway, in your case, that would be a very efficient addition to have the inclusive size, as as @ostrolucky said, that would put the Logger class at the top of the summary.
By the way, I've logged this improvement idea almost a year ago https://github.com/BitOne/php-meminfo/issues/52
So time to work on it ;)
@guenard yes
Same thing with circular references between objects. Which one of the object inside the circular reference loop is the "owner" of the size?
I would be fine for it counting it for both
@BitOne thanks a lot for the reply. It would be great as I couldn't manage to find the source of my memory leak just by playing with php-meminfo. In my specific case (a long running php 7.2 daemon), what's reported by the two PHP memory get usage functions is not even accurate to what the php-cli process is really consuming so I'm clueless at this point.