Subject: Re: smbd dies under heavy transfers
To: Gilles Gravier <Gilles@Gravier.org>
From: Chuck Swiger <email@example.com>
Date: 04/16/2007 13:18:32
On Apr 16, 2007, at 1:09 PM, Gilles Gravier wrote:
> And when my precess would reach a crashing point, the size would be
> about 130 MB... I have (temporarily) set ulimit to unlimited for 3
> variables :
> data seg size (-d)
> max memory size (-m)
> max locked memory (-l)
> Do you think I need all 3? Or can just the data segment count?
The first two are significant, but probably not the third-- not many
programs, aside from GnuPG and OPIE utilize much or any locked memory.
> Running "top" gives me :
> load averages: 2.96, 2.91,
> 95 processes: 2 runnable, 92 sleeping, 1 on processor
> CPU states: 14.9% user, 0.0% nice, 12.9% system, 5.0% interrupt,
> 67.2% idle
> Memory: 269M Act, 135M Inact, 1592K Wired, 40M Exec, 208M File,
> 748K Free
> Swap: 2048M Total, 208M Used, 1841M Free
> PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU
> 677 root 2 0 218M 62M netio 11:22 19.97% 19.97% smbd
> So my smbd is indeed with a size of 218M and 62M of RES
> (resources?). Is that size actually the data segment size?
Size reports the total amount of virtual memory mapped for that
process, and can possibly include allocated but unreferenced pages
which don't need to consume any physical RAM. "RES" stands for
"RESident", which refers to the actual amount of physical RAM
currently used by that process. The rest is typically swapped out or
has never been referenced.
There isn't a simple correspondence to the data segment size-- that
refers to the memory dynamically obtained by brk()/malloc() for the
program heap to hold things allocated as the program runs, along with
any pre-initialized program variables from the DATA section from the
a.out or ELF binary object formats.