openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Ed Tanous <edtanous@google.com>
To: "Ambrozewicz, Adrian" <adrian.ambrozewicz@linux.intel.com>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: ObjectMapper - quantity limitations?
Date: Wed, 27 Jan 2021 09:14:39 -0800	[thread overview]
Message-ID: <CAH2-KxDCorEjGSneVsSDWx7AXFvQZ8fJ1zaqf1zOJfndbW9eNA@mail.gmail.com> (raw)
In-Reply-To: <8fc3b7be-42bc-fc28-6bbd-c5d8de95feaf@linux.intel.com>

On Wed, Jan 27, 2021 at 9:04 AM Ambrozewicz, Adrian
<adrian.ambrozewicz@linux.intel.com> wrote:
>
> Hello,
>
> I'm doing some performance measurements of OpenBMC telemetry subsystem.
> I'm using my custom app, which spawns valid D-Bus Sensors, I configure
> TelemetryService to monitor them and EventService to push MetricReports
> to external server.

Which sensor code are you using?

>
> I observe certain limitation on my system. Each sensor is mapped as two
> objects in ObjectMapper hierarchy. It seems that I am able to correctly
> create up to 1500 sensors. When I go above this limit part of the
> sensors are not represented in ObjectMapper tree.

When I wrote it originally, there were no arbitrary limits on how many
objects the mapper could cache or return, but considering how big your
responses will be, I'm guessing you're hitting the dbus per-message
limit.  You don't mention if you're seeing any errors in the
journalctl log from either the broker or object manager.  That might
give you more clues.

>
> Our use-case would most likely require creating even more sensors than
> the limit I've reached now. I'm just starting to investigate the issue
> and I would be happy if you could give me pointers or ideas what could
> be the culprit here.
>
> Regards,
> Adrian

  reply	other threads:[~2021-01-27 17:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-27 17:03 ObjectMapper - quantity limitations? Ambrozewicz, Adrian
2021-01-27 17:14 ` Ed Tanous [this message]
2021-02-09 15:36   ` Ambrozewicz, Adrian
2021-02-10 12:11     ` Andrew Jeffery

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH2-KxDCorEjGSneVsSDWx7AXFvQZ8fJ1zaqf1zOJfndbW9eNA@mail.gmail.com \
    --to=edtanous@google.com \
    --cc=adrian.ambrozewicz@linux.intel.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).