-
Notifications
You must be signed in to change notification settings - Fork 78
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
Comments
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 ? |
Yeah I think it would help |
FYI I found the leak, it was a PSR logger |
Hi @BitOne, I have a similar problem where it reports mostly primitives types:
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. |
@ostrolucky I'm using Monolog in this script, you too? |
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 #52 So time to work on it ;) |
@guenard yes
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. |
So here's a top of summary table:
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
The text was updated successfully, but these errors were encountered: