Re: Memory usage of BIND process
Stuart Henderson s...@spacehopper.org writes:
Hello again,
after a bit of searching, I am not sure that the datasize limits imposed
in login.conf for the default class override the datasize for the daemon
class in case of named.
There is an extra restriction for cache size in BIND itself. From the
BIND sources in base I see
bin/named/server.c
...
1137 result = ns_config_get(maps, max-cache-size, obj);
1138 INSIST(result == ISC_R_SUCCESS);
1139 if (cfg_obj_isstring(obj)) {
1140 str = cfg_obj_asstring(obj);
1141 INSIST(strcasecmp(str, unlimited) == 0);
1142 max_cache_size = ISC_UINT32_MAX;
1143 } else {
1144 isc_resourcevalue_t value;
1145 value = cfg_obj_asuint64(obj);
1146 if (value ISC_UINT32_MAX) {
1147 cfg_obj_log(obj, ns_g_lctx, ISC_LOG_ERROR,
1148 'max-cache-size
1149 % ISC_PRINT_QUADFORMAT d' is too
large,
1150 value);
1151 result = ISC_R_RANGE;
1152 goto cleanup;
1153 }
1154 max_cache_size = (isc_uint32_t)value;
1155 }
1156 dns_cache_setcachesize(cache, max_cache_size);
...
lib/isc/unix/include/isc/int.h:#define ISC_UINT32_MAX 4294967295U
So, unless I am mistaken there is a 4GB upper limit in BIND cache size
(which is something I also see in more recent versions of BIND eg 9.7.3
that comes with CentOS 6).
I use the following in login.conf:
# by kzorba for named limits
named:\
:ignorenologin:\
:datasize=infinity:\
:maxproc=infinity:\
:stacksize-cur=8M:\
:localcipher=blowfish,8:\
:vmemoryuse=infinity:\
:openfiles-cur=512:
and restarted BIND through /etc/rc.d/named script. However, I still have
not managed to push the memory usage of named beyond 600M on OpenBSD (the
equivalent tests under Linux used 4.9g RSS size and ~5.5g VM size). The
default max-cache-size value in BIND is 'unlimited' which means 4GB from
what I saw in the sources (unless mistaken). If anyone has seen BIND
under OpenBSD utilize memory in the order of GBs I would like to know.
The next steps will be to measure reqs/sec and also unbound in 5.1 since
it is now part of base. If you know of any stress test tool for DNS
queries feel free to share.
Regards,
Kostas
Does named has such a limit by default?
OpenBSD has a limit by default, see login.conf(5). Daemons started
when the system is booted or using /etc/rc.d scripts typically use
the class 'daemon'.
I gathered that. However in login.conf:
daemon:\
:ignorenologin:\
:datasize=infinity:\
:maxproc=infinity:\
:openfiles-cur=128:\
:stacksize-cur=8M:\
:localcipher=blowfish,8:\
:tc=default:
Also ps(1) output seems to confirm that named process limit is the
entire memory of the machine.
root@openbsd: /var/named/tmp # ps -ax -v | head
PID STAT TIME SL RE PAGEIN VSZ RSS LIM TSIZ %CPU %MEM COMMAND
31077 S 277:43.57 0 127 15 608272 610340 8145988 1292 10.6 7.3
/usr/sbin/named
lim is memory not datasize.
Considering the amount of memory this process is actually using, it
looks to me more like it's being run with a 512MB datasize limit,
so perhaps it's not running under the expected 'daemon' class.
BTW, under OpenBSD/amd64 the most the datasize for a single process
can be without modifying the kernel is 8GB.
--
Kostas Zorbadelos
twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba
() www.asciiribbon.org - against HTML e-mail proprietary attachments
/\
Re: Memory usage of BIND process
Stuart Henderson s...@spacehopper.org writes: Hi Stuart, Also ps(1) output seems to confirm that named process limit is the entire memory of the machine. root@openbsd: /var/named/tmp # ps -ax -v | head PID STAT TIME SL RE PAGEIN VSZ RSS LIM TSIZ %CPU %MEM COMMAND 31077 S 277:43.57 0 127 15 608272 610340 8145988 1292 10.6 7.3 /usr/sbin/named lim is memory not datasize. Considering the amount of memory this process is actually using, it looks to me more like it's being run with a 512MB datasize limit, so perhaps it's not running under the expected 'daemon' class. Thanks Stuart, this seems reasonable. How can I find under what class the named process is? Study the sources? I'm not sure if you can directly identify this after the fact, but this is determined by how it was started. If started by a user logged-in directly as root, it should be using the root user's class, by default 'daemon'. As per rc.d(8) if started by the normal system startup scripts, either at boot or manually afterwards, the class will be 'daemon' *unless* a class with the name of the daemon (in this case named) exists in login.conf, in which case that will be used instead. If restarted at runtime *without* using the rc.d scripts, e.g. 'sudo pkill named; sudo named' then it would use the limits that applied to the user you were logged in as *at the time you logged in*. Note that if you change login.conf while you're logged in you will need a totally new login before the new limits apply. (In the case of ssh multiplexing, the old master process will need to go away too, not just your shell). Also note that people using login.conf.db will need to update it (I would not normally recommend login.conf.db though). Thanks for the good explanations. I always start bind either at system boot, or manually under the root user using the rc.d script. Therefore the class should be daemon according to your explanations and from what I see in /etc/rc.d/rc.subr. However it seems that the process is running with 512MB datasize. Which led me to this comment in /etc/login.conf: # The default values # To alter the default authentication types change the line: # :tc=auth-defaults:\ # to be read something like: (enables passwd, myauth, and activ) # :auth=passwd,myauth,activ:\ # Any value changed in the daemon class should be reset in default # class. # So the value in daemon is daemon:\ :ignorenologin:\ :datasize=infinity:\ :maxproc=infinity:\ :openfiles-cur=128:\ :stacksize-cur=8M:\ :localcipher=blowfish,8:\ :tc=default: while default:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin:\ :umask=022:\ :datasize-max=512M:\ :datasize-cur=512M:\ :maxproc-max=256:\ :maxproc-cur=128:\ :openfiles-cur=128:\ :stacksize-cur=4M:\ :localcipher=blowfish,6:\ :ypcipher=old:\ :tc=auth-defaults:\ :tc=auth-ftp-defaults: could it be that datasize-max prevails from default? I think I will add a named section in login.conf after I study its man page ;-) What do you think? Regards, Kostas -- Kostas Zorbadelos twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\
Re: Memory usage of BIND process - threads?
Stuart Henderson s...@spacehopper.org writes: On 2012-04-20, Kostas Zorbadelos kzo...@otenet.gr wrote: Just discovered that under Linux bind seems to use 5 threads (2 processors). Under the same VM config on OpenBSD bind seems to have no threads (using T under top(1)). In 5.0 and 5.1 threads are entirely done in userland and won't show up separately in top. In -current this has changed however in OpenBSD BIND is built without threads anyway. Doesn't this affect BIND's performance? Anyway, a stress test will tell... Is this part of the patches in the OpenBSD version of BIND? No, this is just an argument to the configure script. The patches in the OpenBSD version of BIND deal with privilege separation, the RNG, and switching to safer string functions. Understood. Thanks, Kostas -- Kostas Zorbadelos twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\
Re: Memory usage of BIND process - threads?
On 2012/04/21 11:54, Kostas Zorbadelos wrote: In -current this has changed however in OpenBSD BIND is built without threads anyway. Doesn't this affect BIND's performance? Anyway, a stress test will tell... Untested but in 5.1 and earlier I doubt you will see an improvement with threads, with -current using kernel-backed threads this might help on a multiprocesor system. No, this is just an argument to the configure script. The patches in the OpenBSD version of BIND deal with privilege separation, the RNG, and switching to safer string functions. ..also use the kernel's normal port allocator rather than bind's.
Re: Memory usage of BIND process
On 2012/04/21 11:51, Kostas Zorbadelos wrote: Thanks for the good explanations. I always start bind either at system boot, or manually under the root user using the rc.d script. Therefore the class should be daemon according to your explanations and from what I see in /etc/rc.d/rc.subr. However it seems that the process is running with 512MB datasize. Which led me to this comment in /etc/login.conf: # The default values # To alter the default authentication types change the line: # :tc=auth-defaults:\ # to be read something like: (enables passwd, myauth, and activ) # :auth=passwd,myauth,activ:\ # Any value changed in the daemon class should be reset in default # class. # So the value in daemon is daemon:\ :ignorenologin:\ :datasize=infinity:\ :maxproc=infinity:\ :openfiles-cur=128:\ :stacksize-cur=8M:\ :localcipher=blowfish,8:\ :tc=default: while default:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin:\ :umask=022:\ :datasize-max=512M:\ :datasize-cur=512M:\ :maxproc-max=256:\ :maxproc-cur=128:\ :openfiles-cur=128:\ :stacksize-cur=4M:\ :localcipher=blowfish,6:\ :ypcipher=old:\ :tc=auth-defaults:\ :tc=auth-ftp-defaults: could it be that datasize-max prevails from default? Ah yes, that's correct, so the settings in daemon are ineffective. I wonder if they should be removed to avoid confusion, or changed so that they are effective... Either way what's there now is just confusing. I think I will add a named section in login.conf after I study its man page ;-) rc.d(8) and rc.subr(8) are also useful references. What do you think? Makes sense to me, if you have a certain daemon you would like to give more resources to while keeping standard limits for most daemons, this is exactly the right way to do it.
Re: Memory usage of BIND process
On 2012-04-20 07:43, Kostas Zorbadelos wrote: I understand the kernel VM layers are completely different, but how come the named process on OpenBSD for the same load consumes so low resident memory? Also, why VZS RSS on OpenBSD? The general question I am trying to answer is, can BIND utilize all available memory on the system (so I can arrange the amount of memory when I order the servers). IMHO you're asking the wrong questions. Do your users care about VZS/RSS/CPU/load average/whatever? If they don't, why should you? From what you wrote, it seems to me that what you should care about is how many records can fit in the cache and how many queries it can handle per second. Then measure that. Measure the number of records in cache, and measure how many queries it can handle per second. That is, measure *externally observable behavior*. Don't measure irrelevant technical details. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: Memory usage of BIND process
On Fri, Apr 20, 2012 at 02:43:05PM +0300, Kostas Zorbadelos wrote: Hello all, sorry for the big mail that follows. These are my first attempts at fine tuning and stress testing in OpenBSD so excuse my ignorance. I am stress testing BIND as a resolver on Linux (CentOS 6) and OpenBSD (5.0 release). I will evaluate unbound since this will be included in base also later. I use BIND that comes with the operating systems (9.4.2-P2 in base for OpenBSD and bind-9.7.3 rpm that comes with CentOS 6), however this is rather irrelevant for my questions. I am trying to fill as much as I can in BIND's cache and I use 2 VMs with identical configuration (2 CPUs, 8GB RAM) for the systems to perform the tests. The tests are simple shell scripts running from a couple of clients that generate random names and ask (using dig(1)) for various RRs, most of them won't exist so the nameserver should cache a negative response. I have increased the caching ttl configs to both systems as # 7 days max ttls for the stress tests max-ncache-ttl 604800; max-cache-ttl 604800; I run the tests for a couple of days, identical load on both systems. Here is the relevant top(1) and ps(1) output on both systems: OpenBSD - load averages: 0.39, 0.41, 0.40 openbsd-dns 14:23:05 37 processes: 36 idle, 1 on processor CPU0 states: 4.2% user, 0.0% nice, 2.2% system, 1.8% interrupt, 91.8% idle CPU1 states: 3.4% user, 0.0% nice, 3.8% system, 0.2% interrupt, 92.6% idle Memory: Real: 609M/1231M act/tot Free: 6728M Cache: 551M Swap: 0K/502M PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 31077 named 20 592M 594M sleep/1 select 217:52 12.65% named 1970 _pflogd40 728K 384K sleep/1 bpf 0:34 0.00% pflogd 1642 root 20 1240K 2124K sleep/0 select0:29 0.00% sendmail ... kzorba@openbsd: ~ -ps -ax -v | head PID STAT TIME SL RE PAGEIN VSZ RSS LIM TSIZ %CPU %MEM COMMAND 31077 S 216:21.22 0 127 7 606228 608260 8145988 1292 13.2 7.3 /usr/sbin/named 10103 Is 0:00.21 127 127 0 3500 3120 8145988 284 0.0 0.0 sshd: kzorba [priv] (sshd) 32112 S 0:00.53 5 127 0 3500 2316 8145988 284 0.0 0.0 sshd: kzorba@ttyp0 (sshd) 23004 Is 0:00.02 127 127 0 3420 3136 8145988 284 0.0 0.0 sshd: kzorba [priv] (sshd) 1816 S 0:00.06 0 127 0 3420 2292 8145988 284 0.0 0.0 sshd: kzorba@ttyp3 (sshd) 15380 Is 0:00.02 127 127 0 3376 3160 8145988 284 0.0 0.0 sshd: kzorba [priv] (sshd) 21925 Is 0:00.16 127 127 0 3372 3144 8145988 284 0.0 0.0 sshd: kzorba [priv] (sshd) 3237 I 0:00.08 127 127 0 3344 2336 8145988 284 0.0 0.0 sshd: kzorba@ttyp2 (sshd) 12462 I 0:00.40 22 127 0 3340 2296 8145988 284 0.0 0.0 sshd: kzorba@ttyp1 (sshd) CentOS 6 Linux --- top - 14:24:11 up 15 days, 23:29, 3 users, load average: 0.00, 0.00, 0.00 Tasks: 114 total, 1 running, 113 sleeping, 0 stopped, 0 zombie Cpu(s): 3.1%us, 2.4%sy, 0.0%ni, 92.8%id, 0.0%wa, 0.3%hi, 1.4%si, 0.0%st Mem: 8062104k total, 5052532k used, 3009572k free, 144560k buffers Swap: 5486188k total,0k used, 5486188k free, 218556k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 19542 named 20 0 4582m 4.3g 2564 S 11.6 55.3 193:28.88 named 1 root 20 0 19328 1528 1220 S 0.0 0.0 0:00.77 init 2 root 20 0 000 S 0.0 0.0 0:00.00 kthreadd 3 root RT 0 000 S 0.0 0.0 0:00.06 migration/0 4 root 20 0 000 S 0.0 0.0 0:16.42 ksoftirqd/0 ... kzorba@linux~-ps aux | head -1 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND kzorba@linux~-ps aux | grep named named19542 6.7 55.4 4692936 4468528 ? Ssl Apr18 194:02 /usr/sbin/named -u named -t /var/named/chroot I understand the kernel VM layers are completely different, but how come the named process on OpenBSD for the same load consumes so low resident memory? Also, why VZS RSS on OpenBSD? You neglect to tell us platform details so we cannot tell. OpenBSD has a bit different accounting on what counts for process size and resident size. Something like code or lib pages are accounted in one but not the other. I always forget the details. The general question I am trying to answer is, can BIND utilize all available memory on the system (so I can arrange the amount of memory when I order the servers). Depends. i386 systems for example can only utilize max 2G per process and can address
Re: Memory usage of BIND process
Otto Moerbeek o...@drijf.net writes: You neglect to tell us platform details so we cannot tell. I mentioned trying to fill as much as I can in BIND's cache and I use 2 VMs with identical configuration (2 CPUs, 8GB RAM) for the systems to perform the tests. more details: kzorba@openbsd: ~ -sysctl hw hw.machine=amd64 hw.model=Intel(R) Xeon(R) CPU X5650 @ 2.67GHz hw.ncpu=2 hw.byteorder=1234 hw.pagesize=4096 hw.disknames=cd0:,sd0:6f2e8c0759d7fce1,fd0: hw.diskcount=3 hw.sensors.acpiac0.indicator0=On (power supply) hw.sensors.vmt0.timedelta0=-6118.931944 secs, OK, Fri Apr 20 20:42:05.200 hw.cpuspeed=2659 hw.vendor=VMware, Inc. hw.product=VMware Virtual Platform hw.version=None hw.serialno=VMware-56 4d ea ff 3c cb c5 ea-3a 4d e9 45 d9 73 01 50 hw.uuid=564deaff-3ccb-c5ea-3a4d-e945d9730150 hw.physmem=8588820480 hw.usermem=8588804096 hw.ncpufound=2 hw.allowpowerdown=1 kzorba@dmeg-dns1: ~ -uname -a OpenBSD hostname 5.0 GENERIC.MP#63 amd64 The Linux machine is an identical VM. OpenBSD has a bit different accounting on what counts for process size and resident size. Something like code or lib pages are accounted in one but not the other. I always forget the details. Perhaps they are counted in resident and that should explain it. The general question I am trying to answer is, can BIND utilize all available memory on the system (so I can arrange the amount of memory when I order the servers). Depends. i386 systems for example can only utilize max 2G per process and can address max 4G physical mem. Other platforms have different limits. We are talking about amd64 with 8GB in the test case. The actual servers when bought will be amd64 with probably a lot more memory (something aroung 32 or 48 GB) if BIND can utilize it. Also, per process limits play a role. Does named has such a limit by default? If I believe ps(1) output kzorba@openbsd: ~ -ps -ax -v | head PID STAT TIME SL RE PAGEIN VSZ RSS LIM TSIZ %CPU %MEM COMMAND 31077 S 216:21.22 0 127 7 606228 608260 8145988 1292 13.2 7.3 /usr/sbin/named it can utilize all of the available memory. However, the process VM and RSS size behavior is completely different than Linux. Currently, while the tests keep running I have OpenBSD load averages: 0.27, 0.37, 0.36 openbsd 20:47:34 35 processes: 34 idle, 1 on processor CPU0 states: 0.2% user, 0.0% nice, 0.2% system, 0.2% interrupt, 99.4% idle CPU1 states: 0.3% user, 0.0% nice, 0.2% system, 0.0% interrupt, 99.5% idle Memory: Real: 611M/1234M act/tot Free: 6726M Cache: 552M Swap: 0K/502M PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 31077 named 20 594M 596M sleep/1 select 264:49 11.82% named Linux top - 20:48:18 up 16 days, 5:53, 3 users, load average: 0.00, 0.00, 0.00 Tasks: 109 total, 1 running, 108 sleeping, 0 stopped, 0 zombie Cpu(s): 0.3%us, 0.2%sy, 0.0%ni, 99.4%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st Mem: 8062104k total, 5548408k used, 2513696k free, 144852k buffers Swap: 5486188k total,0k used, 5486188k free, 219112k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 19542 named 20 0 5062m 4.7g 2564 S 7.9 61.5 232:57.98 named Regards, Kostas -- Kostas Zorbadelos twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\
Re: Memory usage of BIND process
Simon Perreault simon.perrea...@viagenie.ca writes: On 2012-04-20 07:43, Kostas Zorbadelos wrote: Hi Simon, I understand the kernel VM layers are completely different, but how come the named process on OpenBSD for the same load consumes so low resident memory? Also, why VZS RSS on OpenBSD? The general question I am trying to answer is, can BIND utilize all available memory on the system (so I can arrange the amount of memory when I order the servers). From what you wrote, it seems to me that what you should care about is how many records can fit in the cache and how many queries it can handle per second. Then measure that. Measure the number of records in cache, and measure how many queries it can handle per second. That is, measure *externally observable behavior*. Don't measure irrelevant technical details. Eventually you are right. However I am trying to answer the primitive question: should I buy servers with a lot of RAM or not? If BIND cannot utilize more than 4GB let's say, it makes no sense to buy servers with 32GB. The servers' only role will be caching resolvers. A few years back, a colleague had noticed problems in custom compiled BIND we currently use (on Linux), when the process size exceeded 4GB. The server produced a lot of SERVFAIL errors. As a workaround the setting max-cache-size 3G; was introduced in named.conf and since noone investigated further it has remained to this day. IMHO you're asking the wrong questions. Do your users care about VZS/RSS/CPU/load average/whatever? If they don't, why should you? I am not an end-user and I like to undestand and learn things ;-) Simon Regards, Kostas -- Kostas Zorbadelos twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\
Re: Memory usage of BIND process
On 2012-04-20 14:07, Kostas Zorbadelos wrote: Eventually you are right. However I am trying to answer the primitive question: should I buy servers with a lot of RAM or not? If BIND cannot utilize more than 4GB let's say, it makes no sense to buy servers with 32GB. The servers' only role will be caching resolvers. A few years back, a colleague had noticed problems in custom compiled BIND we currently use (on Linux), when the process size exceeded 4GB. The server produced a lot of SERVFAIL errors. As a workaround the setting max-cache-size 3G; was introduced in named.conf and since noone investigated further it has remained to this day. Here's a test protocol for you: 1. Set your VM to 6G. 2. Set max-cache-size to 4G. 3. Measure how many records it can store. 4. Set max-cache-size to 5G. 5. Measure how many records it can store. 6. If #3 and #5 differ, you're good. ;) Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: Memory usage of BIND process
Simon Perreault simon.perrea...@viagenie.ca writes: Here's a test protocol for you: 1. Set your VM to 6G. It is set to 8GB. 2. Set max-cache-size to 4G. 3. Measure how many records it can store. I didn't have a way to see that but just found rndc dumpdb -cache :) Do you have any other suggestion? rndc stats in BIND 9.4 produces much less output than more recent BIND versions. Eitherway, if the process size is nowhere near 4 and 5 GBs I don't think I will see anythig different. 4. Set max-cache-size to 5G. 5. Measure how many records it can store. 6. If #3 and #5 differ, you're good. ;) Simon Regards, Kostas -- Kostas Zorbadelos twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\
Re: Memory usage of BIND process
On 2012-04-20, Kostas Zorbadelos kzo...@otenet.gr wrote: Also, per process limits play a role. Does named has such a limit by default? OpenBSD has a limit by default, see login.conf(5). Daemons started when the system is booted or using /etc/rc.d scripts typically use the class 'daemon'.
Re: Memory usage of BIND process
Stuart Henderson s...@spacehopper.org writes: On 2012-04-20, Kostas Zorbadelos kzo...@otenet.gr wrote: Also, per process limits play a role. Does named has such a limit by default? OpenBSD has a limit by default, see login.conf(5). Daemons started when the system is booted or using /etc/rc.d scripts typically use the class 'daemon'. I gathered that. However in login.conf: daemon:\ :ignorenologin:\ :datasize=infinity:\ :maxproc=infinity:\ :openfiles-cur=128:\ :stacksize-cur=8M:\ :localcipher=blowfish,8:\ :tc=default: Also ps(1) output seems to confirm that named process limit is the entire memory of the machine. root@openbsd: /var/named/tmp # ps -ax -v | head PID STAT TIME SL RE PAGEIN VSZ RSS LIM TSIZ %CPU %MEM COMMAND 31077 S 277:43.57 0 127 15 608272 610340 8145988 1292 10.6 7.3 /usr/sbin/named In any case, perhaps the load I give is not enough to have BIND expand its memory usage. In Linux however, under the same load the process size increases pretty well :) [root@linux data]# ps auxww | grep named named19542 7.2 61.5 5184060 4958428 ? Ssl Apr18 243:54 /usr/sbin/named -u named -t /var/named/chroot Thanks, Kostas -- Kostas Zorbadelos twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\
Re: Memory usage of BIND process - threads?
Just discovered that under Linux bind seems to use 5 threads (2 processors). Under the same VM config on OpenBSD bind seems to have no threads (using T under top(1)). Is this part of the patches in the OpenBSD version of BIND? Regards, Kostas -- Kostas Zorbadelos twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\
Re: Memory usage of BIND process
On 2012/04/20 22:44, Kostas Zorbadelos wrote: Stuart Henderson s...@spacehopper.org writes: On 2012-04-20, Kostas Zorbadelos kzo...@otenet.gr wrote: Also, per process limits play a role. Does named has such a limit by default? OpenBSD has a limit by default, see login.conf(5). Daemons started when the system is booted or using /etc/rc.d scripts typically use the class 'daemon'. I gathered that. However in login.conf: daemon:\ :ignorenologin:\ :datasize=infinity:\ :maxproc=infinity:\ :openfiles-cur=128:\ :stacksize-cur=8M:\ :localcipher=blowfish,8:\ :tc=default: Also ps(1) output seems to confirm that named process limit is the entire memory of the machine. root@openbsd: /var/named/tmp # ps -ax -v | head PID STAT TIME SL RE PAGEIN VSZ RSS LIM TSIZ %CPU %MEM COMMAND 31077 S 277:43.57 0 127 15 608272 610340 8145988 1292 10.6 7.3 /usr/sbin/named lim is memory not datasize. Considering the amount of memory this process is actually using, it looks to me more like it's being run with a 512MB datasize limit, so perhaps it's not running under the expected 'daemon' class. BTW, under OpenBSD/amd64 the most the datasize for a single process can be without modifying the kernel is 8GB.
Re: Memory usage of BIND process
Stuart Henderson s...@spacehopper.org writes: On 2012/04/20 22:44, Kostas Zorbadelos wrote: Stuart Henderson s...@spacehopper.org writes: On 2012-04-20, Kostas Zorbadelos kzo...@otenet.gr wrote: Also, per process limits play a role. Does named has such a limit by default? OpenBSD has a limit by default, see login.conf(5). Daemons started when the system is booted or using /etc/rc.d scripts typically use the class 'daemon'. I gathered that. However in login.conf: daemon:\ :ignorenologin:\ :datasize=infinity:\ :maxproc=infinity:\ :openfiles-cur=128:\ :stacksize-cur=8M:\ :localcipher=blowfish,8:\ :tc=default: Also ps(1) output seems to confirm that named process limit is the entire memory of the machine. root@openbsd: /var/named/tmp # ps -ax -v | head PID STAT TIME SL RE PAGEIN VSZ RSS LIM TSIZ %CPU %MEM COMMAND 31077 S 277:43.57 0 127 15 608272 610340 8145988 1292 10.6 7.3 /usr/sbin/named lim is memory not datasize. Considering the amount of memory this process is actually using, it looks to me more like it's being run with a 512MB datasize limit, so perhaps it's not running under the expected 'daemon' class. Thanks Stuart, this seems reasonable. How can I find under what class the named process is? Study the sources? BTW, under OpenBSD/amd64 the most the datasize for a single process can be without modifying the kernel is 8GB. Interesting. Regards, Kostas -- Kostas Zorbadelos twitter:@kzorbadeloshttp://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail proprietary attachments /\
Re: Memory usage of BIND process
On 2012-04-20, Kostas Zorbadelos kzo...@otenet.gr wrote: Stuart Henderson s...@spacehopper.org writes: On 2012/04/20 22:44, Kostas Zorbadelos wrote: Stuart Henderson s...@spacehopper.org writes: On 2012-04-20, Kostas Zorbadelos kzo...@otenet.gr wrote: Also, per process limits play a role. Does named has such a limit by default? OpenBSD has a limit by default, see login.conf(5). Daemons started when the system is booted or using /etc/rc.d scripts typically use the class 'daemon'. I gathered that. However in login.conf: daemon:\ :ignorenologin:\ :datasize=infinity:\ :maxproc=infinity:\ :openfiles-cur=128:\ :stacksize-cur=8M:\ :localcipher=blowfish,8:\ :tc=default: Also ps(1) output seems to confirm that named process limit is the entire memory of the machine. root@openbsd: /var/named/tmp # ps -ax -v | head PID STAT TIME SL RE PAGEIN VSZ RSS LIM TSIZ %CPU %MEM COMMAND 31077 S 277:43.57 0 127 15 608272 610340 8145988 1292 10.6 7.3 /usr/sbin/named lim is memory not datasize. Considering the amount of memory this process is actually using, it looks to me more like it's being run with a 512MB datasize limit, so perhaps it's not running under the expected 'daemon' class. Thanks Stuart, this seems reasonable. How can I find under what class the named process is? Study the sources? I'm not sure if you can directly identify this after the fact, but this is determined by how it was started. If started by a user logged-in directly as root, it should be using the root user's class, by default 'daemon'. As per rc.d(8) if started by the normal system startup scripts, either at boot or manually afterwards, the class will be 'daemon' *unless* a class with the name of the daemon (in this case named) exists in login.conf, in which case that will be used instead. If restarted at runtime *without* using the rc.d scripts, e.g. 'sudo pkill named; sudo named' then it would use the limits that applied to the user you were logged in as *at the time you logged in*. Note that if you change login.conf while you're logged in you will need a totally new login before the new limits apply. (In the case of ssh multiplexing, the old master process will need to go away too, not just your shell). Also note that people using login.conf.db will need to update it (I would not normally recommend login.conf.db though). BTW, under OpenBSD/amd64 the most the datasize for a single process can be without modifying the kernel is 8GB. Interesting. For other arch, grep MAXDSIZ /sys/arch/*/include/vmparam.h
Re: Memory usage of BIND process - threads?
On 2012-04-20, Kostas Zorbadelos kzo...@otenet.gr wrote: Just discovered that under Linux bind seems to use 5 threads (2 processors). Under the same VM config on OpenBSD bind seems to have no threads (using T under top(1)). In 5.0 and 5.1 threads are entirely done in userland and won't show up separately in top. In -current this has changed however in OpenBSD BIND is built without threads anyway. Is this part of the patches in the OpenBSD version of BIND? No, this is just an argument to the configure script. The patches in the OpenBSD version of BIND deal with privilege separation, the RNG, and switching to safer string functions.
