On 27.09.2012 12:15, tcr@xxxxxxxxxxxx wrote:
Following up on this thread (which I inadvertently hijacked):
http://squid-web-proxy-cache.1019090.n4.nabble.com/FATAL-Rock-cache-dir-at-cache-rock-failed-to-open-db-file-2-No-such-file-or-directory-td4656753.html
I've started running a valgrind enabled squid 3.2.1 on one of my
proxies. Squid is currently running just under 1GB of RAM and will
continue to grow and grow. Here is the output from squidclient
mgr:mem
http://bit.ly/QxXL3f
Not too familiar with valgrind, but is there some way that I can mark
a baseline right now, and then run it again later to see which
objects
are continuing to be allocated and not freed, now that the server is
"warmed up"?
If you wish. That report though is not related to valgrind, it is the
usual mempools report of memory usage.
That report contains columns for current, maximum and accumulated
memory behaviour for each pooled object type squid allocates (not all
objects are accounted, thus our dependence on mallinfo() and valgrind
for leak detection). If the max is greater than the current then the
objects are unlikely to be leaking (but no guarantee all code paths
using them are the same leak-free).
NP: The report is a TSV (tab separated values) format MS Excel and
other spreadsheet applications can open and display for easier reading.
You can graph them open two and compare differences in column values etc
whatever you can imagine comparing.
Also, has the mgr:info report got any additional details appended by
valgrind that were not there in earlier reports?
The valgrind report shows the details you are looking for.
Amos
