statistics empty

Asked by dima

i build last d8 mysql-server .
restore 100mb dump old base and done more select querys
after all use 'show user_statistics'
get 'Empty set (0.00 sec)'

i tried 'select * from information_schema.user_statistics' and get 'Empty set (0.00 sec)'

also empty user|client|table|index_statistics ,

Question information

Language:
English Edit question
Status:
Solved
For:
OurDelta Edit question
Assignee:
No assignee Edit question
Solved by:
dima
Solved:
Last query:
Last reply:
Revision history for this message
dima (dima85) said :
#1

how to set userstat_running=on after restart mysql-server ?

Revision history for this message
dima (dima85) said :
#2

i write on start script for mysql-server 'set global userstat_running=on'

Revision history for this message
Cafuego (cafuego) said :
#3

You can add the userstat_running=on directive to the [mysqld] section in your my.cnf

Keep in mind that userstats leaks a bit of memory, so you shouldn't leave it enabled for a long time. Basically, turn it on when you want to measure stats, then turn it back off when done.

Revision history for this message
Arjen Lentz (arjen-lentz) said :
#4

On 29/09/2009, at 3:45 PM, Cafuego wrote:
> Question #65524 on OurDelta changed:
> https://answers.launchpad.net/ourdelta/+question/65524
>
> Cafuego posted a new comment:
> You can add the userstat_running=on directive to the [mysqld]
> section in
> your my.cnf
>
> Keep in mind that userstats leaks a bit of memory, so you shouldn't
> leave it enabled for a long time. Basically, turn it on when you
> want to
> measure stats, then turn it back off when done.

They won't leak in the upcoming 5.0.86 build, thanks to Neil Katin's
fixes.

--
Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Exceptional Services for MySQL at a fixed budget.

Follow our blog at http://openquery.com/blog/
OurDelta: enhanced builds for MySQL @ http://ourdelta.org

Revision history for this message
Weldon Whipple (weldon) said :
#5

That's very interesting memory leak information! At our company we use a
mixture of the Google and Percona patches, plus some of our own. Our own
modifications make MySQL communicate with a (still experimental, under
development) throttling daemon (to make sure that individual users don't
abuse mysqld).

We were noticing a huge (what appeared to be a) memory leak until we fixed
SHOW CLIENT_STATISTICS to allow host names of longer than 16 bytes. However,
we are still noticing smaller memory leaks on some boxes.

I will look at the 5.0.86 modification and see if it eliminates the
remaining leaks. (We're currently running 5.0.81 in production.)

Thanks in advance for all your help!

Weldon Whipple

(P.S. I have ported the Google/Percona/OurLocal combined patch to MySQL
5.1.39. Because it includes our experimental throttling modifications, it
goes beyond the changes of OurDelta. Maybe I should separate them into two
patches? I'm still trying to understand patch-based source control. I
maintain our source in subversion. Whenever I want to generate a patch, I
export the base version and the modified version and use diff to create a
patch. Can anyone point to other methods that give "absolute" source control
using patches? Maybe using quilt, as some Linux kernel developers do?)

On Tue, Sep 29, 2009 at 12:24 AM, Arjen Lentz <
<email address hidden>> wrote:

> Question #65524 on OurDelta changed:
> https://answers.launchpad.net/ourdelta/+question/65524
>
> Arjen Lentz posted a new comment:
>
> On 29/09/2009, at 3:45 PM, Cafuego wrote:
> > Question #65524 on OurDelta changed:
> > https://answers.launchpad.net/ourdelta/+question/65524
> >
> > Cafuego posted a new comment:
> > You can add the userstat_running=on directive to the [mysqld]
> > section in
> > your my.cnf
> >
> > Keep in mind that userstats leaks a bit of memory, so you shouldn't
> > leave it enabled for a long time. Basically, turn it on when you
> > want to
> > measure stats, then turn it back off when done.
>
>
> They won't leak in the upcoming 5.0.86 build, thanks to Neil Katin's
> fixes.
>
>
> --
> Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
> Exceptional Services for MySQL at a fixed budget.
>
> Follow our blog at http://openquery.com/blog/
> OurDelta: enhanced builds for MySQL @ http://ourdelta.org
>
> You received this question notification because you are a member of
> OurDelta-developers, which is an answer contact for OurDelta.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ourdelta-developers<https://launchpad.net/%7Eourdelta-developers>
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~ourdelta-developers<https://launchpad.net/%7Eourdelta-developers>
> More help : https://help.launchpad.net/ListHelp
>

Revision history for this message
Arjen Lentz (arjen-lentz) said :
#6

Hi Weldon

(cc ourdelta-developers, just remove question cc in your reply once/if
you're also connected there. It's going out of scope for this question)

On 30/09/2009, at 1:51 AM, Weldon Whipple wrote:
> (P.S. I have ported the Google/Percona/OurDelta combined patch to
> MySQL
> 5.1.39.

You did? That sounds like a significant effort, with quite a few
pitfalls.
If you indeed have it working, it'd be interesting to look at.

However, it being one giant patch is somewhat problematic in terms of
ability to review.

> Because it includes our experimental throttling modifications, it
> goes beyond the changes of OurDelta. Maybe I should separate them
> into two
> patches? I'm still trying to understand patch-based source control.
> I maintain our source in subversion. Whenever I want to generate a
> patch,
> I export the base version and the modified version and use diff to
> create a
> patch. Can anyone point to other methods that give "absolute" source
> control
> using patches? Maybe using quilt, as some Linux kernel developers do?)

OurDelta uses quilt, bzr and Launchpad.
See the readme in the base of an OurDelta bzr branch.

For 5.1, the changes would be merged into the Maria tree (also bzr/
Launchpad based).
Having one giant patch however can still pose a problem, depending on
exactly which revision it'd get merged into it could create a lot of
conflicts; plus the review of the code itself, plus the fact that in
5.1 we use XtraDB plugin not the old innobase subdirectory. And so
on... lots of differences.
But, still interesting to look at! So please do show us the goods!

Cheers,
Arjen.
--
Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Exceptional Services for MySQL at a fixed budget.

Follow our blog at http://openquery.com/blog/
OurDelta: enhanced builds for MySQL @ http://ourdelta.org