Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to find memory leak when cause is lot of primitive data types #66

Open
ostrolucky opened this issue Jul 2, 2018 · 10 comments

Comments

@ostrolucky
Copy link

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

@BitOne
Copy link
Owner

BitOne commented Aug 6, 2018

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 ?

@ostrolucky
Copy link
Author

Yeah I think it would help

@ostrolucky
Copy link
Author

FYI I found the leak, it was a PSR logger

@guenard
Copy link

guenard commented Oct 19, 2018

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

@ostrolucky
Copy link
Author

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.

@guenard
Copy link

guenard commented Oct 22, 2018

@ostrolucky I'm using Monolog in this script, you too?

@BitOne
Copy link
Owner

BitOne commented Oct 22, 2018

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.

@BitOne
Copy link
Owner

BitOne commented Oct 22, 2018

By the way, I've logged this improvement idea almost a year ago #52

So time to work on it ;)

@ostrolucky
Copy link
Author

@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

@guenard
Copy link

guenard commented Nov 5, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants