Hyperactive Memory Management

Tags

• Munin
• Monitoring
• Memory

   2015-02-17

First I have to admit that the memory fragmentation graphs don't tell me much since now. Most of my servers are busy with mixed tasks and don't show up with a special profile in this area. The following webserver is special. The high activity doesn't fit to its situation. This is a development machine which is used seldom and should be idle most of the time. Looks like a process lives an independent existence..

When we zoom in, we see that the periodic change happens every 5 minute. So the assumption is that Munin is responsible for the effect.

I then added a further munin plugin ps_memory to the munin-node. It monitors the amount of memory that a process has allocated.

Quickly it showed that mysqld memory allocation was switching between two values. Here the graph, which focus on the range where the mysqld resources reside. Setting the lower limit on the y-axis to 345MB is done with option "graph_args --base 1024 -l 361500000 --rigid" in the plugins configuration.

After 15:00 o'clock I removed the Munin plugins that monitor the MySQL-Server and instantly the amount of mysqld memory stops its oscillation.

So it's clear now. As this server has nothing else to do, we saw Munin's monitoring work in the oscillating curves.

Legend for Memory Fragmentation Graph

Order 0: Number of order 0 (4 KiB) pages
Order 1: Number of order 1 (8 KiB) pages
Order 2: Number of order 2 (16 KiB) pages
Order 3: Number of order 3 (32 KiB) pages
Order 4: Number of order 4 (64 KiB) pages
Order 5: Number of order 5 (128 KiB) pages
Order 6: Number of order 6 (256 KiB) pages
Order 7: Number of order 7 (512 KiB) pages
Order 8: Number of order 8 (1024 KiB) pages
Order 9: Number of order 9 (2048 KiB) pages
Order 10: Number of order 10 (4096 KiB) pages