Several pinba daemons on the same server

10 views
Skip to first unread message

Evgeniy Potapov

unread,
Oct 27, 2009, 2:28:20 PM10/27/09
to pinba-...@googlegroups.com
Hello!

For some reasons I want to aggregate stats from several completely
different (and geographically distributed) projects on one server.

As the most simple and quick solution I see creating few distributions
of pinba mysql engine on the same mysql server.

By quick look through the plugin sources and MySQL documentation I
understand that I need to change plugin declaration and
libpinba_engine plugin library name with the custom plugin name name I
need for each project.

Are there any hidden issues I could meet on this way?

Is there any best way to do it?

Actually I want to handle 10-20 pinba-using projects on the same
server, each one not too much loaded with low number of timers, with
RPS up to 100-200 on each

Is it possible at all?

Best Regards,
Evgeniy Potapov
eapo...@gmail.com

Ihalainen Nickolay

unread,
Oct 27, 2009, 2:37:52 PM10/27/09
to pinba-...@googlegroups.com
why not a simple 20 mysql daemons installations with mysqld_mult?

Evgeniy Potapov

unread,
Oct 27, 2009, 2:46:19 PM10/27/09
to pinba-...@googlegroups.com
Haha, actually that's the second (and it seems to be the most simple) thing I want to do :)
but if it's possible to do add another daemon just by applying some diff patch and installing new plugin - why not? :)

Alexey A. Rybak

unread,
Oct 27, 2009, 4:32:54 PM10/27/09
to pinba-...@googlegroups.com
What kind of stats do you want to have? I think that you can just try
to separate stats by hostname using single pinba. I never did that but
it seems that base reports like "info" will be useless, but other
reports (those "devided" by hostnames) - will be OK.
--

wbr,
fisher

Evgeniy Potapov

unread,
Oct 27, 2009, 4:45:09 PM10/27/09
to pinba-...@googlegroups.com
We have a number of clients for which we provide some server
monitoring info and we want to extend this data with some kind of
application statistics.

The timers stats is the main priority. I'm worrying about the case
when one client will have, say, 200 rps, and other - 5-10 at the
moment. As I could understand with timers stats rotation there could
be situation when timer stats table will be overfilled with 200-rps-
client, so other clients stats will be simply merged.

Probably I may be wrong :)

Alexey A. Rybak

unread,
Oct 27, 2009, 5:49:52 PM10/27/09
to pinba-...@googlegroups.com
> The timers stats is the main priority. I'm worrying about the case
> when one client will have, say, 200 rps, and other - 5-10 at the
> moment. As I could understand with timers stats rotation there could
> be situation when timer stats table will be overfilled with 200-rps-
> client, so other clients stats will be simply merged.

Well, 10 clients with 200 rps give 200*10*600 = 1.2M requests for 10
minutes (600 sec).
Let each request have 10 timers - this gives you approx 10M timers for
10 minutes.
I don't think that the table will be "overfilled", AFAIR there is no
hard limitation except memory, and 10M events is not hard to handle in
memory at all.
"Rotation" will be processed by event time, not by any limit number
for events in the table.
--

wbr,
fisher

Evgeniy Potapov

unread,
Oct 27, 2009, 6:04:54 PM10/27/09
to pinba-...@googlegroups.com
Gotcha! Thanks!

After several months of using pinba just for scripts statistics, I
understand the power of the timers only now.

Already created few complex reports tables.

To get "current" client timers' average I added "client" tag with the
client alias, and use it as the criteria to get result from this tables.

No need in separate pinbas or MySQLs or something like that.

Thanks again.

Andrew Sitnikov

unread,
Oct 27, 2009, 5:42:37 PM10/27/09
to pinba-...@googlegroups.com
VIEWS Can help you
http://dev.mysql.com/doc/refman/5.0/en/create-view.html

2009/10/27 Evgeniy Potapov <eapo...@gmail.com>

Antony Dovgal

unread,
Oct 28, 2009, 4:33:05 AM10/28/09
to pinba-...@googlegroups.com
On 28.10.2009 01:04, Evgeniy Potapov wrote:
> Gotcha! Thanks!
>
> After several months of using pinba just for scripts statistics, I
> understand the power of the timers only now.
>
> Already created few complex reports tables.
>
> To get "current" client timers' average I added "client" tag with the
> client alias, and use it as the criteria to get result from this tables.

Yep, that's what came to my mind first =)

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP

Evgeniy Potapov

unread,
Oct 28, 2009, 6:16:48 AM10/28/09
to pinba-...@googlegroups.com
Thanks again.

One more question
>"At the moment only reports with grouping by 1 and 2 tags are
supported."

Is there any possibility that tag reports with more than 2 tags will
be available in future versions of Pinba?
I understand that it is opensource project and the right way of the
answer will be "it would be better if you'll implement it if it's
needed" but may be this functionality implementation is scheduled? :)

While that I'm doing concatenation of few criterias in one tag,
something like "tag1tag3tag4" in the tag2 while tag1 is the client name

is there any best way to generate comlpex tag reports in current
version?

Antony Dovgal

unread,
Oct 28, 2009, 6:24:29 AM10/28/09
to pinba-...@googlegroups.com
On 28.10.2009 13:16, Evgeniy Potapov wrote:
> Thanks again.
>
> One more question
> >"At the moment only reports with grouping by 1 and 2 tags are
> supported."
>
> Is there any possibility that tag reports with more than 2 tags will
> be available in future versions of Pinba?

I was thinking about reports with N tags (where 'N' is as big as you like),
but I'm not yet sure they are really necessary.

If you give me some time, I can estimate the complexity of the task.

Evgeniy Potapov

unread,
Oct 28, 2009, 6:43:55 AM10/28/09
to pinba-...@googlegroups.com
Sure, that's ok ;)

While that LIKE solution matches our current needs (unless we'll reach
varchar 32 tagname limit for the complex tag name "serialization")

Antony Dovgal

unread,
Oct 28, 2009, 8:03:55 AM10/28/09
to pinba-...@googlegroups.com
On 28.10.2009 13:24, Antony Dovgal wrote:
> If you give me some time, I can estimate the complexity of the task.

Well, I started implementing it in a lazy mode - it's a lot of code, so don't expect it anytime soon.

Reply all
Reply to author
Forward
0 new messages