Hello Uli,
Thanks for your note.
--- You wrote:
66,66 Hz means 1999,8 theoretical Polls in 30 secs - a maximum of 2000 Nodes.
No, this is not the right way to interpret this. InterMapper is designed to query
multiple devices per poll, and can easily handle thousands of nodes/devices.
Let me explain a little more about InterMapper internals. In steady state, InterMapper's
polling process (nominally 66.67 times/second, or every 15 msec) does three major
tasks:
a) probe all the devices that need to be polled now (finding all the devices that
need to be polled, and sending ping packets or SNMP queries, starting a TCP transaction,
starting a command-line probe, etc.). This may lead to dozens of queries being
sent each time.
b) process any responses that have come back (from earlier queries).
c) do "other work" - sending notifications, sending updates to RemoteAccess GUI,
handling http requests, getting data to IM Database, etc.
d) if all this processing completed within 15 msec from its start, InterMapper
then waits until the next polling time. If that polling required more time, InterMapper
immediately starts a new poll.
Note that a burst of activity (web queries, IMDB activity, etc.) may delay the
next poll, but the algorithm is designed to catch up in subsequent polls.
The Problem
We have recently diagnosed a problem where long-term "other work" consumes a lot
of time, and causes a number of problems, notably high packet loss.
This happened because InterMapper has finite length queues for its ping packet
responses, and for SNMP responses. (TCP and command-line probes have their own
threads, so they execute independently.)
If the other work consumed a significant fraction of the processor time (long
term), newly-arrived ping and SNMP responses could overwrite earlier reponses
in the queues. This would lead InterMapper to believe that those overwritten responses
had been lost "by the network", and that there was high packet loss.
We have done a lot of work, and are doing more to solve this:
- InterMapper 5.0.6 expanded the size of the buffers to hold the ping and SNMP
responses. These buffer sizes had been small (a low as 8Kbytes) and are now considerably
larger (their size depends on the OS/platform) and can hold many more responses.
- Recent InterMapper 5.0 releases also contain optimizations that make the "other
work" go faster.
- A signifcant effort in our development on InterMapper 5.1 has gone toward further
optimizations so that it will can better handle large installations.
My question:
- What are the parameters to extend this value ?
- Who can i influence this value?
- more cpus ?
- more ethernet - interfaces ?
- x3 is a easy way - but therefor i have different databases and so on ....
The InterMapper Engine Status probe simply documents the behavior of what InterMapper
is doing during its polling cycle. It gives our developers a few numerical values
to show how InterMapper is spending its time.
There aren't a lot of "moving parts" that you can alter. As explained in the Description,
the Main Loop frequency shows how often the polling process actually executes.
If this value falls below 10, then we would like to know, since this points the
way toward isolating the heavy processing.
Please get back to me if you have further questions. Thanks.
Rich Brown [email protected]
Dartware, LLC http://www.dartware.com
66-7 Benning Street Telephone: 603-643-9600
West Lebanon, NH 03784-3407 Fax: 603-643-2289
____________________________________________________________________
List archives:
http://www.mail-archive.com/intermapper-talk%40list.dartware.com/
To unsubscribe: send email to: [email protected]
