[Nagios-devel] [patch] NSCA version 2.9 pre-forked daemon mode
Posted: Tue Dec 06, 2011 10:56 pm
--_002_A5DD33C05033144FBB1D507F8D3A56A834A94AF172QCVXMP01wwcor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi.
I recently had the chance to look at version 2.9 of NSCA. We were originall=
y running it in "--daemon" mode at our installation, but it looks like the =
daemon mode is not bounded by any means; NSCA can fork() as much as it want=
s (up to the socket listener limit, but that is still quite a bit of proces=
ses) to process the incoming check results and I didn't like that. I had a =
look at the "--single" mode of operation and from our tests results, it doe=
sn't scale as much as we need.
I went in and modified the code a bit to implement a PREFORK mode where the=
NSCA daemon forks a number of processes at startup and respawns them if th=
ey exit for some errors. In my opinion, this should have better scalability=
than the single-threaded mode and better resources usage behavior when han=
dling many messages per second. This is imitating the mpm_prefork worker fo=
r "httpd" a bit (much more simplistic though). This adds a new "--prefork" =
command-line option to NSCA.
I also think that the new "check_result_path" configuration directive is a =
good performance shortcut, so that is with what I tested it and it gave goo=
d results for now.
Any comments are welcome, if you want to include the patch upstream, feel f=
ree as I would be glad to have contributed to that project.
The included patch applies clean on nsca-trunk; revision 1846.
---
Michel Belleau
--_002_A5DD33C05033144FBB1D507F8D3A56A834A94AF172QCVXMP01wwcor_
Content-Type: application/octet-stream; name="nsca_29-prefork.patch"
Content-Description: nsca_29-prefork.patch
Content-Disposition: attachment; filename="nsca_29-prefork.patch"; size=6553;
creation-date="Tue, 06 Dec 2011 22:16:26 GMT";
modification-date="Tue, 06 Dec 2011 22:35:22 GMT"
Content-Transfer-Encoding: base64
SW5kZXg6IHNyYy9uc2NhLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3JjL25zY2EuYwkocmV2aXNpb24gMTg0
NikKKysrIHNyYy9uc2NhLmMJKHdvcmtpbmcgY29weSkKQEAgLTMyLDggKzMyLDkgQEAKIHN0YXRp
YyBjaGFyIGFsdGVybmF0ZV9kdW1wX2ZpbGVbTUFYX0lOUFVUX0JVRkZFUl09Ii9kZXYvbnVsbCI7
CiBzdGF0aWMgY2hhciBjb21tYW5kX2ZpbGVbTUFYX0lOUFVUX0JVRkZFUl09IiI7CiBzdGF0aWMg
Y2hhciBwYXNzd29yZFtNQVhfSU5QVVRfQlVGRkVSXT0iIjsKK3N0YXRpYyBpbnQgbmNoaWxkcmVu
ID0gMzI7CiAKLXN0YXRpYyBlbnVtIHsgT1BUSU9OU19FUlJPUiwgU0lOR0xFX1BST0NFU1NfREFF
TU9OLCBNVUxUSV9QUk9DRVNTX0RBRU1PTiwgSU5FVEQgfSBtb2RlPVNJTkdMRV9QUk9DRVNTX0RB
RU1PTjsKK3N0YXRpYyBlbnVtIHsgT1BUSU9OU19FUlJPUiwgU0lOR0xFX1BST0NFU1NfREFFTU9O
LCBNVUxUSV9QUk9DRVNTX0RBRU1PTiwgUFJFRk9SS19QUk9DRVNTX0RBRU1PTiwgSU5FVEQgfSBt
b2RlPVNJTkdMRV9QUk9DRVNTX0RBRU1PTjsKIHN0YXRpYyBpbnQgZGVidWc9RkFMU0U7CiBzdGF0
aWMgaW50IGFnZ3JlZ2F0ZV93cml0ZXM9RkFMU0U7CiBzdGF0aWMgaW50IGRlY3J5cHRpb25fbWV0
aG9kPUVOQ1JZUFRfWE9SOwpAQCAtMTE4LDYgKzExOSw3IEBACiAJCXByaW50ZigiIDxjb25maWdf
ZmlsZT4gPSBOYW1lIG9mIGNvbmZpZyBmaWxlIHRvIHVzZVxuIik7CiAJCXByaW50ZigiIFttb2Rl
XSAgICAgICAgPSBEZXRlcm1pbmVzIGhvdyBOU0NBIHNob3VsZCBydW4uIFZhbGlkIG1vZGVzOlxu
Iik7CiAgICAgICAgICAgICAgICAgcHJpbnRmKCIgICAtLWluZXRkICAgICA9IFJ1biBhcyBhIHNl
cnZpY2UgdW5kZXIgaW5ldGQgb3IgeGluZXRkXG4iKTsKKyAgICAgICAgICAgICAgICBwcmludGYo
IiAgIC0tcHJlZm9yayAgID0gUnVuIGFzIGEgc3RhbmRhbG9uZSBwcmVmb3JrZWQgZGFlbW9uXG4i
KTsKICAgICAgICAgICAgICAgICBwcmludGYoIiAgIC0tZGFlbW9uICAgID0gUnVuIGFzIGEgc3Rh
bmRhbG9uZSBtdWx0aS1wcm9jZXNzIGRhZW1vblxuIik7CiAgICAgICAgICAgICAgICAgcHJpbnRm
KCIgICAtLXNpbmdsZSAgICA9IFJ1biBhcyBhIHN0YW5kYWxvbmUgc2luZ2xlLXByb2Nlc3MgZGFl
bW9uIChkZWZhdWx0KVxuIik7CiAgICAgICAgICAgICAgICAgcHJpbnRmKCJcbiIpOwpAQCAtMTgz
LDYgKzE4NSwxMSBAQAogICAgICAgICAgICAgICAgIGhhbmRsZV9jb25uZWN0aW9uKDAsTlVMTCk7
CiAgICAgICAgICAgICAgICAgYnJlYWs7CiAKKyAgICAgICAgY2FzZSBQUkVGT1JLX1BST0NFU1Nf
REFFTU9OOgorCisJCS8qIG5ld2VyIHN0eWxlLCBwcmVmb3JrZWQgZGFlbW9uICovCisJCS8qIGV4
ZWN1dGlvbiBjYXNjYWRlcyBiZWxvdy4uLiAqLworCiAgICAgICAgIGNhc2UgTVVMVElfUFJPQ0VT
U19EQUVNT046CiAKIAkJLyogb2xkZXIgc3R5bGUsIG11bHQtcHJvY2VzcyBkYWVtb24gKi8KQEAg
LTE5Nyw2ICsyMDQsNyBAQAogCQkgICAgICAgfAogCQkgICAgICAgViAgICAgKi8KIAorCiAgICAg
ICAgICAgICAgICA
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi.
I recently had the chance to look at version 2.9 of NSCA. We were originall=
y running it in "--daemon" mode at our installation, but it looks like the =
daemon mode is not bounded by any means; NSCA can fork() as much as it want=
s (up to the socket listener limit, but that is still quite a bit of proces=
ses) to process the incoming check results and I didn't like that. I had a =
look at the "--single" mode of operation and from our tests results, it doe=
sn't scale as much as we need.
I went in and modified the code a bit to implement a PREFORK mode where the=
NSCA daemon forks a number of processes at startup and respawns them if th=
ey exit for some errors. In my opinion, this should have better scalability=
than the single-threaded mode and better resources usage behavior when han=
dling many messages per second. This is imitating the mpm_prefork worker fo=
r "httpd" a bit (much more simplistic though). This adds a new "--prefork" =
command-line option to NSCA.
I also think that the new "check_result_path" configuration directive is a =
good performance shortcut, so that is with what I tested it and it gave goo=
d results for now.
Any comments are welcome, if you want to include the patch upstream, feel f=
ree as I would be glad to have contributed to that project.
The included patch applies clean on nsca-trunk; revision 1846.
---
Michel Belleau
--_002_A5DD33C05033144FBB1D507F8D3A56A834A94AF172QCVXMP01wwcor_
Content-Type: application/octet-stream; name="nsca_29-prefork.patch"
Content-Description: nsca_29-prefork.patch
Content-Disposition: attachment; filename="nsca_29-prefork.patch"; size=6553;
creation-date="Tue, 06 Dec 2011 22:16:26 GMT";
modification-date="Tue, 06 Dec 2011 22:35:22 GMT"
Content-Transfer-Encoding: base64
SW5kZXg6IHNyYy9uc2NhLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3JjL25zY2EuYwkocmV2aXNpb24gMTg0
NikKKysrIHNyYy9uc2NhLmMJKHdvcmtpbmcgY29weSkKQEAgLTMyLDggKzMyLDkgQEAKIHN0YXRp
YyBjaGFyIGFsdGVybmF0ZV9kdW1wX2ZpbGVbTUFYX0lOUFVUX0JVRkZFUl09Ii9kZXYvbnVsbCI7
CiBzdGF0aWMgY2hhciBjb21tYW5kX2ZpbGVbTUFYX0lOUFVUX0JVRkZFUl09IiI7CiBzdGF0aWMg
Y2hhciBwYXNzd29yZFtNQVhfSU5QVVRfQlVGRkVSXT0iIjsKK3N0YXRpYyBpbnQgbmNoaWxkcmVu
ID0gMzI7CiAKLXN0YXRpYyBlbnVtIHsgT1BUSU9OU19FUlJPUiwgU0lOR0xFX1BST0NFU1NfREFF
TU9OLCBNVUxUSV9QUk9DRVNTX0RBRU1PTiwgSU5FVEQgfSBtb2RlPVNJTkdMRV9QUk9DRVNTX0RB
RU1PTjsKK3N0YXRpYyBlbnVtIHsgT1BUSU9OU19FUlJPUiwgU0lOR0xFX1BST0NFU1NfREFFTU9O
LCBNVUxUSV9QUk9DRVNTX0RBRU1PTiwgUFJFRk9SS19QUk9DRVNTX0RBRU1PTiwgSU5FVEQgfSBt
b2RlPVNJTkdMRV9QUk9DRVNTX0RBRU1PTjsKIHN0YXRpYyBpbnQgZGVidWc9RkFMU0U7CiBzdGF0
aWMgaW50IGFnZ3JlZ2F0ZV93cml0ZXM9RkFMU0U7CiBzdGF0aWMgaW50IGRlY3J5cHRpb25fbWV0
aG9kPUVOQ1JZUFRfWE9SOwpAQCAtMTE4LDYgKzExOSw3IEBACiAJCXByaW50ZigiIDxjb25maWdf
ZmlsZT4gPSBOYW1lIG9mIGNvbmZpZyBmaWxlIHRvIHVzZVxuIik7CiAJCXByaW50ZigiIFttb2Rl
XSAgICAgICAgPSBEZXRlcm1pbmVzIGhvdyBOU0NBIHNob3VsZCBydW4uIFZhbGlkIG1vZGVzOlxu
Iik7CiAgICAgICAgICAgICAgICAgcHJpbnRmKCIgICAtLWluZXRkICAgICA9IFJ1biBhcyBhIHNl
cnZpY2UgdW5kZXIgaW5ldGQgb3IgeGluZXRkXG4iKTsKKyAgICAgICAgICAgICAgICBwcmludGYo
IiAgIC0tcHJlZm9yayAgID0gUnVuIGFzIGEgc3RhbmRhbG9uZSBwcmVmb3JrZWQgZGFlbW9uXG4i
KTsKICAgICAgICAgICAgICAgICBwcmludGYoIiAgIC0tZGFlbW9uICAgID0gUnVuIGFzIGEgc3Rh
bmRhbG9uZSBtdWx0aS1wcm9jZXNzIGRhZW1vblxuIik7CiAgICAgICAgICAgICAgICAgcHJpbnRm
KCIgICAtLXNpbmdsZSAgICA9IFJ1biBhcyBhIHN0YW5kYWxvbmUgc2luZ2xlLXByb2Nlc3MgZGFl
bW9uIChkZWZhdWx0KVxuIik7CiAgICAgICAgICAgICAgICAgcHJpbnRmKCJcbiIpOwpAQCAtMTgz
LDYgKzE4NSwxMSBAQAogICAgICAgICAgICAgICAgIGhhbmRsZV9jb25uZWN0aW9uKDAsTlVMTCk7
CiAgICAgICAgICAgICAgICAgYnJlYWs7CiAKKyAgICAgICAgY2FzZSBQUkVGT1JLX1BST0NFU1Nf
REFFTU9OOgorCisJCS8qIG5ld2VyIHN0eWxlLCBwcmVmb3JrZWQgZGFlbW9uICovCisJCS8qIGV4
ZWN1dGlvbiBjYXNjYWRlcyBiZWxvdy4uLiAqLworCiAgICAgICAgIGNhc2UgTVVMVElfUFJPQ0VT
U19EQUVNT046CiAKIAkJLyogb2xkZXIgc3R5bGUsIG11bHQtcHJvY2VzcyBkYWVtb24gKi8KQEAg
LTE5Nyw2ICsyMDQsNyBAQAogCQkgICAgICAgfAogCQkgICAgICAgViAgICAgKi8KIAorCiAgICAg
ICAgICAgICAgICA
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]