I/O wait reported from secondary NagiosXI

[jpipitone]

Update: I ran the database repair script and the server seems to be responding normally now.

Is anyone able to give me any insight regarding my physical memory question? This is a 32 bit OS - if we install more memory in the server, will the OS see it, and will Nagios be able to utilize it?

If not, we can rebuild with a 64 bit OS and import the existing Nagios config.

Any ideas?

[abrist]

Most 32bit linux kernels will and already do support physical address extensions. A single process may still be restricted, but as nagios is mostly a collection of different scripts and binaries, more memory would not hurt. Lets make sure that you server's memory usage is actually high, and not just filled with disk caching (which is mostly benign).

Code: Select all

free -m

[jpipitone]

Code: Select all

[root@nagiosxi ~]# free -m
             total       used       free     shared    buffers     cached
Mem:          4040       3506        534          0        154       2550
-/+ buffers/cache:        801       3239
Swap:         5023          0       5023

[abrist]

-/+ buffers/cache:        801       3239

You are actually using very little of your memory. 3.2 gb are used for disk caching which is released when needed. Your io issues must be caused by something else other than lack of memory. Is you disk full?

Code: Select all

df -h
df -i

[jpipitone]

Disk isn't anywhere near full. I ran the nagios database repair script which seemed to have resolved the I/O issues.

[abrist]

Great. You may want to take a look at the mysqld logs for crashed table errors:

Code: Select all

tail -200 /var/log/mysqld.log | grep crashed

[jpipitone]

Will do. Thank you!