Here's what I'm finding most confusing making some kind of sense out of all
this.
I'm having trouble relating our output to numbers generated by other
routines in the operating system.
Here's some examples - all SOlaris.
Server A:
Memory size: 11264 Megabytes
# swap -s
total: 2559672k bytes al
On 15/11/06, Thomas Anders <[EMAIL PROTECTED]> wrote:
> >> What's wrong with using "virtual memory" for these objects?
> >
> > I don't want to do this because in most cases, the HAL memory
> > entry that's labelled as VIRTMEM does *not* actually monitor
> > virtual memory.
> At this point in time,
Dave Shield wrote:
> On 13/11/06, Thomas Anders <[EMAIL PROTECTED]> wrote:
>> I'm not sure I see the benefits of tweaking the MIB and the code to
>> replace "virtual memory" by "real+swap" for these objects.
>
> The changes to the MIB are intended to make the behaviour more
> explicit - thus avoid
On 13/11/06, Thomas Anders <[EMAIL PROTECTED]> wrote:
> I'm not sure I see the benefits of tweaking the MIB and the code to
> replace "virtual memory" by "real+swap" for these objects.
The changes to the MIB are intended to make the behaviour more
explicit - thus avoiding the potential ambiguities
Dave Shield wrote:
>> There are [a couple of] areas where the code is non-trivially different:
>
>>- memTotalFree
>>- memSwapError{,Msg}
>
> I offer the attached patch for consideration w.r.t. these two areas.
I'm not sure I see the benefits of tweaking the MIB and the code to
replace
I've finished analysing the new HAL-based ucd-snmp/memory module,
and comparing it against the previous individual statistics.
There are [a couple of] areas where the code is non-trivially different:
- memTotalFree
- memSwapError{,Msg}
I offer the attached patch for consideration w
