# pmp-check-unix-memory always in Critical

**URL:** <https://forums.percona.com/t/pmp-check-unix-memory-always-in-critical/3197>\
**Category:** Percona Monitoring Plugins\
**Created:** [January 13, 2014, 4:44am UTC](https://forums.percona.com/t/pmp-check-unix-memory-always-in-critical/3197 "2014-01-13T04:44:38Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![AdriannaXTS](https://avatars.discourse-cdn.com/v4/letter/a/b487fb/32.png) [@AdriannaXTS](https://forums.percona.com/u/AdriannaXTS)\
**Post date:** [January 13, 2014, 4:44am UTC](https://forums.percona.com/t/pmp-check-unix-memory-always-in-critical/3197/1 "2014-01-13T04:44:38Z")

</div>

Since a few days I have this Nagios check that is all the time in critical on machines that have been identified at least once as a donor node.

Both machines show the following performance :

Percona 1

> [@](#):
>
> top - 10:50:28 up 75 days, 17:43, 1 user, load average: 1.55, 1.42, 1.37  
> Tasks: 109 total, 1 running, 108 sleeping, 0 stopped, 0 zombie  
> Cpu(s): 17.9%us, 3.8%sy, 0.0%ni, 17.2%id, 60.5%wa, 0.0%hi, 0.7%si, 0.0%st  
> Mem: 1922716k total, 1851192k used, 71524k free, 141860k buffers  
> Swap: 983032k total, 918728k used, 64304k free, 287184k cached
> 
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND  
> 6272 mysql 20 0 3102m 1.3g 84m S 21.6 71.4 2497:30 mysqld

Nagios Status

> [@](#):
>
> Status Information: CRIT OK Memory 74% used. Largest process: mysqld (6272) = 3102.95MB (165%)  
> Performance Data: memory\_used=74;90;95;0;100

Percona2

> [@](#):
>
> top - 10:49:55 up 75 days, 17:09, 1 user, load average: 0.09, 0.08, 0.03  
> Tasks: 173 total, 1 running, 172 sleeping, 0 stopped, 0 zombie  
> Cpu(s): 0.4%us, 0.5%sy, 0.0%ni, 98.9%id, 0.1%wa, 0.0%hi, 0.1%si, 0.0%st  
> Mem: 1922308k total, 1844232k used, 78076k free, 205240k buffers  
> Swap: 983032k total, 21720k used, 961312k free, 1112968k cached
> 
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND  
> 31677 mysql 20 0 1964m 467m 138m S 0.7 24.9 235:33.21 mysqld

Nagios Status

> [@](#):
>
> Status Information: CRIT OK Memory 27% used. Largest process: mysqld (31677) = 1964.93MB (104%)  
> Performance Data: memory\_used=27;90;95;0;100

Please find below the configuration I have in file /etc/my.cnf

> [@](#):
>
> # The MySQL server
> 
> [mysqld]  
> port = 3306  
> socket = /var/lib/mysql/mysql.sock  
> skip-external-locking  
> key\_buffer\_size = 384M  
> max\_allowed\_packet = 1M  
> table\_open\_cache = 512  
> sort\_buffer\_size = 2M  
> read\_buffer\_size = 2M  
> read\_rnd\_buffer\_size = 8M  
> myisam\_sort\_buffer\_size = 64M  
> thread\_cache\_size = 8  
> query\_cache\_size = 32M
> 
> # Try number of CPU’s\*2 for thread\_concurrency
> 
> thread\_concurrency = 8  
> max\_connections=1000000  
> max\_connect\_errors=1000000
> 
> [mysqldump]  
> quick  
> max\_allowed\_packet = 16M
> 
> [mysql]  
> no-auto-rehash
> 
> # Remove the next comment character if you are not familiar with SQL
> 
> #safe-updates
> 
> [myisamchk]  
> key\_buffer\_size = 256M  
> sort\_buffer\_size = 256M  
> read\_buffer = 2M  
> write\_buffer = 2M

Should I change any parameters?

---

<div class="post-metadata">

**Author:** ![weber](https://avatars.discourse-cdn.com/v4/letter/w/da6949/32.png) [@weber](https://forums.percona.com/u/weber)\
**Post date:** [January 13, 2014, 5:49am UTC](https://forums.percona.com/t/pmp-check-unix-memory-always-in-critical/3197/2 "2014-01-13T05:49:19Z")

</div>

Install the latest version of the plugin where the override check for largest process VSIZE is disabled.  
Or use “-d” option with the old version of the plugin.

---

<div class="post-metadata">

**Author:** ![AdriannaXTS](https://avatars.discourse-cdn.com/v4/letter/a/b487fb/32.png) [@AdriannaXTS](https://forums.percona.com/u/AdriannaXTS)\
**Post date:** [January 14, 2014, 10:11am UTC](https://forums.percona.com/t/pmp-check-unix-memory-always-in-critical/3197/3 "2014-01-14T10:11:47Z")

</div>

Hello Weber ,

Thanks for your answer , I juste add “-d” option. I’ll upgrade the plugin version later.