On Mon, Aug 18, 2014 at 3:10 AM, Goswin von Brederlow <[email protected]> wrote: > > On Fri, Aug 01, 2014 at 11:23:24AM -0700, Dave Peacock wrote: > > Have just run into this same issue. I haven't tried uclibc yet, tho thanks > > for that suggestion, will investigate later. For those of you running > > embedded linux or similar, under posix it looks like there are a few > > options for controlling this. > > > > * Before the thread is created, you could call pthread_attr_setstacksize ( > > http://man7.org/linux/man-pages/man3/pthread_attr_setstacksize.3.html). > > This requires modifying zeromq source. > > What exactly is the problem with stacksize? Are you running out of > address space or don't you have memory overcommit enabled? > > Because while the thread might get a few MB of stack only those pages > actually being used should get allocated by the kernel. So a new > thread might show 16MB virtual memory used for the stack the resident > memory will be just the few kiB being actually used (unless you do use > more and then a small stack would segfault). >
Indeed not clear there is a problem -- in my case (slightly more physical mem than OP at 128MB, no swap) after processes ran for a while I was sometimes seeing memory-related problems, some kernel drivers complaining about no available memory etc. Overcommit is enabled, but running 350% overcommitted made me suspicious of these "big" processes. I still have suspicions but i can not confirm any wrongdoing. Still trying to get my head around the myriad ways of tracking memory usage in linux. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
