Subject: Re: smbd dies under heavy transfers
To: Gilles Gravier <Gilles@Gravier.org>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 04/16/2007 22:13:44
On Mon, Apr 16, 2007 at 10:09:10PM +0200, Gilles Gravier wrote:
> Manuel, you rock! That worked!
> ulimit -a gives me :
> core file size (blocks, -c) unlimited
> data seg size (kbytes, -d) 131072
> file size (blocks, -f) unlimited
> max locked memory (kbytes, -l) 157086
> max memory size (kbytes, -m) 471260
> open files (-n) 64
> pipe size (512 bytes, -p) 1
> stack size (kbytes, -s) 2048
> cpu time (seconds, -t) unlimited
> max user processes (-u) 160
> virtual memory (kbytes, -v) 133120
> 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?
Data would be enough I guess
> 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%
> 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 COMMAND
> 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?).
RES is for "resident", this is the part of data really in RAM (the remaining
is on disk)
> that size actually the data segment size?
Not only, there's also stack and exec pages. But most of it should be data.
Manuel Bouyer <email@example.com>
NetBSD: 26 ans d'experience feront toujours la difference