On 2013/7/24 13:42, Willy Tarreau wrote:
I agree and can confirm your results here. Also, if I replace the
calloc with a malloc, I still see mmap and we don't have the 300M
RSS anymore :
willy@pcw:~$ ps auxw|grep a.out
willy31956 0.0 0.0 2880 632 pts/4S+ 07:36 0:00 strace
On Wed, Jul 24, 2013 at 03:55:23PM +0800, Godbach wrote:
On 2013/7/24 13:42, Willy Tarreau wrote:
I agree and can confirm your results here. Also, if I replace the
calloc with a malloc, I still see mmap and we don't have the 300M
RSS anymore :
willy@pcw:~$ ps auxw|grep a.out
willy
On 2013/7/24 16:18, Willy Tarreau wrote:
On Wed, Jul 24, 2013 at 03:55:23PM +0800, Godbach wrote:
On 2013/7/24 13:42, Willy Tarreau wrote:
I agree and can confirm your results here. Also, if I replace the
calloc with a malloc, I still see mmap and we don't have the 300M
RSS anymore :
On Wed, Jul 24, 2013 at 04:58:31PM +0800, Godbach wrote:
The mechanism of poisoning/memset is used for memory pool. Memory pool
uses MALLOC in dev7 and CALLOC in master, most chunks of memory are
allocated from memory pool while processing sessions. But what we have
talked about is memory
On 2013/7/24 17:07, Willy Tarreau wrote:
On Wed, Jul 24, 2013 at 04:58:31PM +0800, Godbach wrote:
The mechanism of poisoning/memset is used for memory pool. Memory pool
uses MALLOC in dev7 and CALLOC in master, most chunks of memory are
allocated from memory pool while processing sessions. But
❦ 24 juillet 2013 11:07 CEST, Willy Tarreau w...@1wt.eu :
Indeed. I have no idea why we're observing these differences, and I
don't know if the libc uses heuristics to decide to memset() the
area or not.
Unless there is an alternative malloc hooked, the libc heavily relies on
the fact that
Hi Vincent,
On Wed, Jul 24, 2013 at 09:38:36PM +0200, Vincent Bernat wrote:
??? 24 juillet 2013 11:07 CEST, Willy Tarreau w...@1wt.eu :
Indeed. I have no idea why we're observing these differences, and I
don't know if the libc uses heuristics to decide to memset() the
area or not.
Hi Godbach,
On Fri, Jul 19, 2013 at 04:02:17PM +0800, Godbach wrote:
Oh, one thing may be forgotten mentioned in my first mail:
Then I run a simple program which also called calloc to alloc 300Mbytes
meomory, and the reuslt as below:
PID USER PR NI VIRT RES SHR S %CPU %MEM
On Fri, Jul 19, 2013 at 01:55:43PM +0800, Godbach wrote:
Hi Willy,
On 2013/7/19 13:32, Willy Tarreau wrote:
Hi Godbach,
On Fri, Jul 19, 2013 at 12:21:23PM +0800, Godbach wrote:
You should strace it. I'm sure you'll see an mmap() call that matches
the size of your allocation, meaning
On 2013/7/19 14:34, Willy Tarreau wrote:
On Fri, Jul 19, 2013 at 01:55:43PM +0800, Godbach wrote:
Hi Willy,
Here is part information about strace during haproxy startup:
open(h.cfg, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1985, ...}) = 0
mmap(NULL, 4096,
Hi Godbach,
On Fri, Jul 19, 2013 at 12:21:23PM +0800, Godbach wrote:
Hi Willy,
In my opinion, haproxy will full size memory after allocating that for
fdtab and fdinfo since calloc is used. But after I started haproxy with
maxconn 1,048,576 wiht lastest snapshot, the result from `top`
Hi Willy,
On 2013/7/19 13:32, Willy Tarreau wrote:
Hi Godbach,
On Fri, Jul 19, 2013 at 12:21:23PM +0800, Godbach wrote:
You should strace it. I'm sure you'll see an mmap() call that matches
the size of your allocation, meaning that the libc has decided to use
this instead of sbrk() to
12 matches
Mail list logo
