|
From: | Nestor Urquiza |
Subject: | Re: Solaris 11 memory usage |
Date: | Wed, 22 Oct 2014 12:58:46 -0400 |
Hi Nestor,
you can use something like this to get the distribution (will record the memstat output + user space distribution ... processes by RSS):
if memory usage > 80% then exec "/bin/sh -c 'exec >> /tmp/memstat.$$; echo ___________ `date` ___________; echo ::memstat | sudo mdb -k; prstat -c -s rss 1 10'"
There was fix for memory usage report for Solaris in Monit 5.7 ... please can you upgrade to Monit 5.9? If the problem will persist - is the system where Monit is running 32-bit or 64-bit? Is it the Solaris zone?
Regards,
Martin
> On 20 Oct 2014, at 22:04, Nestor Urquiza <address@hidden> wrote:
>
> Hi Martin,
>
> Is there a way to put monit in debug mode so we get more information about the memory distribution at the moment of the alert?
>
> One thing we have noticed is that regardless how many cycles we wait to alert, the succeed message comes in the next cycle after the alert which is really weird.
>
> Thanks,
>
> - Nestor
>
> On Sun, Oct 19, 2014 at 12:32 PM, Nestor Urquiza <address@hidden> wrote:
> I am sorry about the examples but yes we do get memory utilization spikes:
>
> "mem usage of 82.6% matches resource limit [mem usage>80.0%],"
>
> It is difficult to get that information at the time of the alert though. Is there a way to put monit on debug mode or something to get exactly the memory utilization distribution?
>
> Right now everything is alright:
>
> $ sudo monit status
>
> ...
>
> System 'server'
>
> status Running
>
> monitoring status Monitored
>
> load average [0.13] [0.12] [0.11]
>
> cpu 0.3%us 1.4%sy 0.0%wa
>
> memory usage 11822268 kB [35.2%]
>
> swap usage 0 kB [0.0%]
>
> data collected Sun, 19 Oct 2014 12:23:47
>
> ...
>
>
>
> $ echo ::memstat | sudo mdb -k
>
> Page Summary Pages MB %Tot
>
> ------------ ---------------- ---------------- ----
>
> Kernel 591587 2310 7%
>
> ZFS File Data 1089502 4255 13%
>
> Anon 999345 3903 12%
>
> Exec and libs 50239 196 1%
>
> Page cache 249081 972 3%
>
> Free (cachelist) 3821104 14926 46%
>
> Free (freelist) 1587621 6201 19%
>
>
> Total 8388479 32767
>
>
>
>
>
> Thanks,
>
> - Nestor
>
>
>
>
>
>
> On Sat, Oct 18, 2014 at 4:22 PM, Martin Pala <address@hidden> wrote:
> Hi,
>
> the attached error message ("cpu system usage ...") is for CPU test ... not related to memory usage. High "cpu system" usage may be for example sign of heavy disk I/O activity and/or swapping (memory shortage) - check vmstat output for details.
>
> If the memory usage report is problem, please can you provide output of "echo ::memstat | mdb -k" and "monit status" (just the System service part is sufficient).
>
>
> Regards,
> Martin
>
>
>
> > On 16 Oct 2014, at 16:41, Nestor Urquiza <address@hidden> wrote:
> >
> > Hi guys,
> >
> > Since we went from Solaris 10 to 11 we have seen an increase monit alerts related to memory resource utilization. We used to get no alerts even when we set the memorty threshold really low, for example:
> >
> > "...cpu system usage of 45.8% matches resource limit [cpu system usage>40.0%]"
> >
> >
> > We have incremented the threshold to 90% but still we get alerts.
> >
> > Could it be that the way monit decides what is free memory in Solaris is incorrect when using ZFS http://serverfault.com/questions/378392/how-should-i-monitor-memory-usage-performance-in-sunos-solaris
> >
> > We are running monit version 5.5 BTW which has been working fine for ages.
> >
> > Perhaps version 5.9 has done something in that regard as I read the release notes ( http://mmonit.com/monit/changes/ ) are allowing to monitor generic device strings (not related really but worth to ask).
> >
> > Thanks!
> >
> > - Nestor
> >
> > --
> > To unsubscribe:
> > https://lists.nongnu.org/mailman/listinfo/monit-general
>
>
> --
> To unsubscribe:
> https://lists.nongnu.org/mailman/listinfo/monit-general
>
>
> --
> To unsubscribe:
> https://lists.nongnu.org/mailman/listinfo/monit-general
--
To unsubscribe:
https://lists.nongnu.org/mailman/listinfo/monit-general
[Prev in Thread] | Current Thread | [Next in Thread] |