As lmiltchev said, I think the solution here is to find out the cause of the high load. What does "top" reveal?
And would you be able to offload some checks to be passive? In larger installs this can have a dramatic effect, especially for things like ESX checks which historically are a drain on resources.
Alert's history not working after changing concurrent checks
Re: Alert's history not working after changing concurrent ch
Former Nagios employee
Re: Alert's history not working after changing concurrent ch
There's no solution or workaround for this?
Finding a way to suppress the "Max concurrent checks" message would do it for us!
Finding a way to suppress the "Max concurrent checks" message would do it for us!
Re: Alert's history not working after changing concurrent ch
Unfortunately, as I already said, there is no way to suppress these messages. You will have to resolve the load issue.
Be sure to check out our Knowledgebase for helpful articles and solutions!
Re: Alert's history not working after changing concurrent ch
No one can help? No suggestions?
-
sreinhardt
- -fno-stack-protector
- Posts: 4366
- Joined: Mon Nov 19, 2012 12:10 pm
Re: Alert's history not working after changing concurrent ch
Well, you can certainly increase the number of max connections or whichever setting caused this change, unless I am mistaken it sounds like that only started after the changes. As for stopping the messages about it, I doubt there is a way without disabling logging entirely, as this message should definitely be shown when it does happen. Also please do a:
Code: Select all
su - nagios -c "ulimit -a"Nagios-Plugins maintainer exclusively, unless you have other C language bugs with open-source nagios projects, then I am happy to help! Please pm or use other communication to alert me to issues as I no longer track the forum.
Re: Alert's history not working after changing concurrent ch
sreinhardt wrote:Well, you can certainly increase the number of max connections or whichever setting caused this change, unless I am mistaken it sounds like that only started after the changes. As for stopping the messages about it, I doubt there is a way without disabling logging entirely, as this message should definitely be shown when it does happen. Also please do a:Code: Select all
su - nagios -c "ulimit -a"
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 62787
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 32768
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 32768
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
We've also modified the number of available local ports:
cat /proc/sys/net/ipv4/ip_local_port_range
25000 65000
Thanks!
Re: Alert's history not working after changing concurrent ch
Was the server restarted after altering the limits?
Former Nagios employee
"It is turtles. All. The. Way. Down. . . .and maybe an elephant or two."
VI VI VI - The editor of the Beast!
Come to the Dark Side.
"It is turtles. All. The. Way. Down. . . .and maybe an elephant or two."
VI VI VI - The editor of the Beast!
Come to the Dark Side.
Re: Alert's history not working after changing concurrent ch
abrist wrote:Was the server restarted after altering the limits?
Yes, we've already restarted the server.
Re: Alert's history not working after changing concurrent ch
What are the specs on this server? You may need to provision more hardware:
Code: Select all
lscpu
free -mFormer Nagios employee
"It is turtles. All. The. Way. Down. . . .and maybe an elephant or two."
VI VI VI - The editor of the Beast!
Come to the Dark Side.
"It is turtles. All. The. Way. Down. . . .and maybe an elephant or two."
VI VI VI - The editor of the Beast!
Come to the Dark Side.