Re: Backend memory dump analysis
| От | Vladimir Sitnikov |
|---|---|
| Тема | Re: Backend memory dump analysis |
| Дата | |
| Msg-id | CAB=Je-EnvU5NjppmEmfo6BqtAnaC9kZyhpK0sBWVwQJ2fAX6kg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Backend memory dump analysis (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Backend memory dump analysis
|
| Список | pgsql-hackers |
Tom>Well, as I said, you can do anything you want now in an extension.
That is true. However it basically means "everybody who cares to troubleshoot the memory use of a production system should install an extension".
Should https://wiki.postgresql.org/wiki/Developer_FAQ#Examining_backend_memory_use provide a link to the extension then?
Tom>Actually the key number is the one that already is printed
Tom>first, ie the total space consumed by the contextThe space used is more important than the context name itself.
What do you think of
8192 (2 blocks) CachedPlan: 1504 free (0 chunks); 6688 used: SELECT (SELECT COUNT(*) FROM (SELECT * FROM new_test UNION ALL SELECT * FROM new_test) ss)
?
PS. "1504 free (0 chunks)" reads odd.
Tom>Very occasionally, you might be interested in spotting contexts that have
Tom>a disproportionate amount of free space, but IME that's seldom the main
Tom>issue.
Tom>a disproportionate amount of free space, but IME that's seldom the main
Tom>issue.
Fully agree. That is why I suggest "total, used, free" order so it matches the likelihood of usage.
Vladimir
В списке pgsql-hackers по дате отправления: