With softlimit (and ulimit) one can set several memory limits, most interesting data and stack segment. How do I determine the actual memory consumption for data and stack of a process? With tools like ps and top I only get code + data + stack summed up. -- -- Bernhard Graf
On Tuesday 06 May 2008 08:37:36 am Bernhard Graf wrote: > With softlimit (and ulimit) one can set several memory limits, most > interesting data and stack segment. > > How do I determine the actual memory consumption for data and stack of a > process? > With tools like ps and top I only get code + data + stack summed up. Something like pmap? rwoodrum <at> frums:~$ pmap -d 888 888: /bin/bash Address Kbytes Mode Offset Device Mapping 08048000 664 r-(Continue reading)x-- 0000000000000000 008:00001 bash 080ee000 20 rw--- 00000000000a6000 008:00001 bash 080f3000 2572 rw--- 00000000080f3000 000:00000 [ anon ] b7c67000 28 r--s- 0000000000000000 008:00005 gconv-modules.cache b7c6e000 212 r--s- 0000000000000000 008:00006 passwd b7ca3000 1256 r---- 0000000000000000 008:00005 locale-archive b7ddd000 4 rw--- 00000000b7ddd000 000:00000 [ anon ] b7dde000 1312 r-x-- 0000000000000000 008:00001 libc-2.7.so b7f26000 4 r---- 0000000000148000 008:00001 libc-2.7.so b7f27000 8 rw--- 0000000000149000 008:00001 libc-2.7.so b7f29000 16 rw--- 00000000b7f29000 000:00000 [ anon ] b7f2d000 8 r-x-- 0000000000000000 008:00001 libdl-2.7.so b7f2f000 8 rw--- 0000000000001000 008:00001 libdl-2.7.so b7f31000 184 r-x-- 0000000000000000 008:00001 libncurses.so.5.6 b7f5f000 12 rw--- 000000000002d000 008:00001 libncurses.so.5.6 b7f77000 8 rw--- 00000000b7f77000 000:00000 [ anon ] b7f79000 104 r-x-- 0000000000000000 008:00001 ld-2.7.so
On Tuesday 06 Mai 2008, Ryan Woodrum wrote: > On Tuesday 06 May 2008 08:37:36 am Bernhard Graf wrote: > > With softlimit (and ulimit) one can set several memory limits, most > > interesting data and stack segment. > > > > How do I determine the actual memory consumption for data and stack > > of a process? > > With tools like ps and top I only get code + data + stack summed > > up. > > Something like pmap? > > rwoodrum <at> frums:~$ pmap -d 888 > 888: /bin/bash > Address Kbytes Mode Offset Device Mapping > 08048000 664 r-(Continue reading)x-- 0000000000000000 008:00001 bash > 080ee000 20 rw--- 00000000000a6000 008:00001 bash > 080f3000 2572 rw--- 00000000080f3000 000:00000 [ anon ] > b7c67000 28 r--s- 0000000000000000 008:00005 gconv-modules.cache > b7c6e000 212 r--s- 0000000000000000 008:00006 passwd > b7ca3000 1256 r---- 0000000000000000 008:00005 locale-archive > b7ddd000 4 rw--- 00000000b7ddd000 000:00000 [ anon ] > b7dde000 1312 r-x-- 0000000000000000 008:00001 libc-2.7.so > b7f26000 4 r---- 0000000000148000 008:00001 libc-2.7.so > b7f27000 8 rw--- 0000000000149000 008:00001 libc-2.7.so > b7f29000 16 rw--- 00000000b7f29000 000:00000 [ anon ] > b7f2d000 8 r-x-- 0000000000000000 008:00001 libdl-2.7.so > b7f2f000 8 rw--- 0000000000001000 008:00001 libdl-2.7.so > b7f31000 184 r-x-- 0000000000000000 008:00001 libncurses.so.5.6
On Wednesday 07 May 2008 12:04:56 pm Bernhard Graf wrote: > On Tuesday 06 Mai 2008, Ryan Woodrum wrote: > > On Tuesday 06 May 2008 08:37:36 am Bernhard Graf wrote: > > > With softlimit (and ulimit) one can set several memory limits, most > > > interesting data and stack segment. > > > > > > How do I determine the actual memory consumption for data and stack > > > of a process? > > > With tools like ps and top I only get code + data + stack summed > > > up. > > > > Something like pmap? > > > > rwoodrum <at> frums:~$ pmap -d 888 > > 888: /bin/bash > > Address Kbytes Mode Offset Device Mapping > > 08048000 664 r-(Continue reading)x-- 0000000000000000 008:00001 bash > > 080ee000 20 rw--- 00000000000a6000 008:00001 bash > > 080f3000 2572 rw--- 00000000080f3000 000:00000 [ anon ] > > b7c67000 28 r--s- 0000000000000000 008:00005 gconv-modules.cache > > b7c6e000 212 r--s- 0000000000000000 008:00006 passwd > > b7ca3000 1256 r---- 0000000000000000 008:00005 locale-archive > > b7ddd000 4 rw--- 00000000b7ddd000 000:00000 [ anon ] > > b7dde000 1312 r-x-- 0000000000000000 008:00001 libc-2.7.so > > b7f26000 4 r---- 0000000000148000 008:00001 libc-2.7.so > > b7f27000 8 rw--- 0000000000149000 008:00001 libc-2.7.so > > b7f29000 16 rw--- 00000000b7f29000 000:00000 [ anon ] > > b7f2d000 8 r-x-- 0000000000000000 008:00001 libdl-2.7.so > > b7f2f000 8 rw--- 0000000000001000 008:00001 libdl-2.7.so > > b7f31000 184 r-x-- 0000000000000000 008:00001 libncurses.so.5.6
Hi, runit version 1.9.0 is available for testing http://smarden.org/runit/ The default directory for services is now /service/, and no longer /var/service/. To be consistent with the new default location, create a symbolic link when upgrading # ln -s /var/service / When installing runit on a system that should comply with the Filesystem Hierarchy Standard (FHS), neither /service/ nor /var/service/ should be chosen, but /etc/service/. It is recommended to create a compatibility symlink /service pointing to /etc/service in this case. This version additionally fixes the runsv program to properly handle service directories with ./log being a symlink to a directory on a different device, and slightly updates the sv program and the documentation. If you use runit regularly, please contribute[0] to the project. Thanks, Gerrit.
Gerrit Pape wrote: > When installing runit on a system that should comply with the Filesystem > Hierarchy Standard (FHS), neither /service/ nor /var/service/ should be > chosen, but /etc/service/. It is recommended to create a compatibility > symlink /service pointing to /etc/service in this case. Is this for the actual service configurations, or the directory monitored by runsvdir-start ? Are you sure this is FHS-compliant? Wouldn't /var/run/service be a better location? R.
Robin Bowes <robin-lists <at> robinbowes.com> writes: > Gerrit Pape wrote: > > When installing runit on a system that should comply with the Filesystem > > Hierarchy Standard (FHS), neither /service/ nor /var/service/ should be > > chosen, but /etc/service/. It is recommended to create a compatibility > > symlink /service pointing to /etc/service in this case. > > Is this for the actual service configurations, or the directory > monitored by runsvdir-start ? The latter. > Are you sure this is FHS-compliant? Wouldn't /var/run/service be a > better location? At Debian, which adheres to the FHS, we agreed that /etc/service/ doesn't conflict with the FHS, so yes. /var/run/service is not suitable, because /var/run/ may well be a ramdisk, and its content is not guaranteed to survive a reboot. Regards, Gerrit. http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION
On Tue 13 May 2008 at 10:48:59 AM +0000, Gerrit Pape wrote: >Robin Bowes <robin-lists <at> robinbowes.com> writes: >> Gerrit Pape wrote: >> > When installing runit on a system that should comply with the Filesystem >> > Hierarchy Standard (FHS), neither /service/ nor /var/service/ should be >> > chosen, but /etc/service/. It is recommended to create a compatibility >> > symlink /service pointing to /etc/service in this case. >> >> Is this for the actual service configurations, or the directory >> monitored by runsvdir-start ? > >The latter. Why not /etc/service as a default for all systems? (as I speculate it's related to /etc/opt : Configuration files for /opt) // George >http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION -- -- George Georgalis, information system scientist <IXOYE><
George Georgalis wrote: > On Tue 13 May 2008 at 10:48:59 AM +0000, Gerrit Pape wrote: >> Robin Bowes <robin-lists <at> robinbowes.com> writes: >>> Gerrit Pape wrote: >>>> When installing runit on a system that should comply with the Filesystem >>>> Hierarchy Standard (FHS), neither /service/ nor /var/service/ should be >>>> chosen, but /etc/service/. It is recommended to create a compatibility >>>> symlink /service pointing to /etc/service in this case. >>> Is this for the actual service configurations, or the directory >>> monitored by runsvdir-start ? >> The latter. > > Why not /etc/service as a default for all systems? > > (as I speculate it's related to /etc/opt : Configuration files for /opt) I've built netbooting/embedded systems where /etc was mounted read-only. Putting the run, check, supervise and finish scripts there makes sense -- but it would be nice if the supervise directories could be split out and stored elsewhere (presumably on tmpfs) in such environments.
On May 15, 2008, at 12:10 PM, Charles Duffy wrote: > George Georgalis wrote: >> On Tue 13 May 2008 at 10:48:59 AM +0000, Gerrit Pape wrote: >>> Robin Bowes <robin-lists <at> robinbowes.com> writes: >>>> Gerrit Pape wrote: >>>>> When installing runit on a system that should comply with the >>>>> Filesystem >>>>> Hierarchy Standard (FHS), neither /service/ nor /var/service/ >>>>> should be >>>>> chosen, but /etc/service/. It is recommended to create a >>>>> compatibility >>>>> symlink /service pointing to /etc/service in this case. >>>> Is this for the actual service configurations, or the directory >>>> monitored by runsvdir-start ? >>> The latter. >> Why not /etc/service as a default for all systems? >> (as I speculate it's related to /etc/opt : Configuration files for / >> opt) > > I've built netbooting/embedded systems where /etc was mounted read- > only. Putting the run, check, supervise and finish scripts there > makes sense -- but it would be nice if the supervise directories > could be split out and stored elsewhere (presumably on tmpfs) in > such environments. I do that exactly -- /, including /etc, is read-only on most of my systems. I put scripts in /etc/supervise so they hit the configuration management, and symlink the supervise directory to /var/tmp/run/(Continue reading)
RSS Feed19 | |
|---|---|
3 | |
1 | |
1 | |
1 | |
7 | |
11 | |
1 | |
15 | |
15 | |
1 | |
1 | |
15 | |
1 | |
5 | |
13 | |
18 | |
10 | |
8 | |
9 | |
3 | |
20 | |
2 | |
12 | |
1 | |
2 | |
3 | |
4 | |
12 | |
2 | |
28 | |
8 | |
6 | |
2 | |
5 | |
6 | |
2 | |
6 | |
4 | |
20 | |
12 | |
12 | |
15 | |
57 | |
3 | |
21 | |
53 | |
7 | |
5 | |
20 | |
53 | |
2 | |
34 | |
31 | |
7 | |
14 | |
13 | |
14 | |
2 | |
12 | |
43 | |
45 | |
24 | |
17 | |
24 | |
45 | |
37 | |
8 | |
43 | |
57 | |
29 | |
45 | |
21 | |
5 | |
32 | |
27 | |
1 | |
4 | |
45 | |
34 | |
18 | |
43 | |
45 | |
9 | |
24 | |
21 | |
22 | |
20 | |
42 | |
74 | |
46 | |
8 | |
41 | |
39 | |
25 | |
5 | |
7 | |
12 | |
22 | |
9 | |
38 | |
24 | |
6 | |
3 | |
35 | |
8 | |
28 | |
13 |
