Re: [squid-users] mallinfo() vs. sbrk()

2008-11-09 Thread Henrik Nordstrom
On sön, 2008-11-09 at 14:06 -0800, Mark Nottingham wrote:
> What about
> 
> Memory accounted for:
>   Total accounted:   2039507 KB
> 
> This seems to be the only one that's not wrapped around to negative  
> above 2G on Linux... both mallinfo and sbrk are.

total accounted for works, but does not include all memory allocations.

Regards
Henrik


signature.asc
Description: This is a digitally signed message part


Re: [squid-users] mallinfo() vs. sbrk()

2008-11-09 Thread Mark Nottingham

What about

Memory accounted for:
Total accounted:   2039507 KB

This seems to be the only one that's not wrapped around to negative  
above 2G on Linux... both mallinfo and sbrk are.


Cheers,


On 07/11/2008, at 12:38 PM, Henrik Nordstrom wrote:


On fre, 2008-11-07 at 10:36 -0800, Mark Nottingham wrote:

thx.

When mallinfo fails, how does it appear in cachemgr -- i.e., is there
any way to reliably detect it just by examining the output?


numbers wrap over and become negative, then 0 and positive again.  
Cycle

repeats each 4 GB. (32-bit signed counters counting bytes)

regards
Henrik



--
Mark Nottingham   [EMAIL PROTECTED]




Re: [squid-users] mallinfo() vs. sbrk()

2008-11-07 Thread Henrik Nordstrom
On fre, 2008-11-07 at 10:36 -0800, Mark Nottingham wrote:
> thx.
> 
> When mallinfo fails, how does it appear in cachemgr -- i.e., is there  
> any way to reliably detect it just by examining the output?

numbers wrap over and become negative, then 0 and positive again. Cycle
repeats each 4 GB. (32-bit signed counters counting bytes)

regards
Henrik



Re: [squid-users] mallinfo() vs. sbrk()

2008-11-07 Thread Mark Nottingham

thx.

When mallinfo fails, how does it appear in cachemgr -- i.e., is there  
any way to reliably detect it just by examining the output?


Cheers,


On 06/11/2008, at 7:03 PM, Henrik Nordstrom wrote:


On tor, 2008-11-06 at 13:17 -0800, Mark Nottingham wrote:

I remember reading somewhere (can't forget where, and I may be
incorrect) that when available, sbrk is a more reliable indication of
memory use for squid than mallinfo().


mallinfo is more reliabe than sbrk when it works... but at least Linux
mallinfo fails when the process grows above 2GB in size..

mallinfo includes all memory allocated by the memory allocator (malloc
and friends).

sbrk includes the size of the data segment, where most memory
allocations go, but not all. Large allocations is handled by malloc
outside of the data segment.

Regards
Henrik


--
Mark Nottingham   [EMAIL PROTECTED]




Re: [squid-users] mallinfo() vs. sbrk()

2008-11-06 Thread Henrik Nordstrom
On tor, 2008-11-06 at 13:17 -0800, Mark Nottingham wrote:
> I remember reading somewhere (can't forget where, and I may be  
> incorrect) that when available, sbrk is a more reliable indication of  
> memory use for squid than mallinfo().

mallinfo is more reliabe than sbrk when it works... but at least Linux
mallinfo fails when the process grows above 2GB in size..

mallinfo includes all memory allocated by the memory allocator (malloc
and friends).

sbrk includes the size of the data segment, where most memory
allocations go, but not all. Large allocations is handled by malloc
outside of the data segment.

Regards
Henrik


signature.asc
Description: This is a digitally signed message part


[squid-users] mallinfo() vs. sbrk()

2008-11-06 Thread Mark Nottingham
I remember reading somewhere (can't forget where, and I may be  
incorrect) that when available, sbrk is a more reliable indication of  
memory use for squid than mallinfo(). However, I'm seeing this on a box;


Process Data Segment Size via sbrk(): 1040844 KB
Maximum Resident Size: 0 KB
Page faults with physical i/o: 0
Memory usage for squid via mallinfo():
Total space in arena:  1621452 KB
Ordinary blocks:   1620888 KB   8820 blks
Small blocks:   0 KB  0 blks
Holding blocks: 20928 KB  4 blks
Free Small blocks:  0 KB
Free Ordinary blocks: 563 KB
Total in use:  1641816 KB 100%
Total free:   563 KB 0%
Total size:1642380 KB
Memory accounted for:
Total accounted:   1565651 KB

As you can see, sbrk() is considerably less than total size via  
mallinfo(). Is this unusual? Any thoughts about which is better, if  
both are available?


Thanks,

--
Mark Nottingham   [EMAIL PROTECTED]