WEBVTT

00:00.000 --> 00:12.000
So everybody knows Fred, nobody's fine.

00:12.000 --> 00:19.000
So if you don't know me, ask Fred, he'll tell you both.

00:19.000 --> 00:29.000
So while I work in front of my school team, from 2011 officially, okay,

00:29.000 --> 00:32.000
so before I just, it was for fun.

00:32.000 --> 00:38.000
And I was working in Santa Cruz System benchmark center.

00:38.000 --> 00:42.000
So it was pretty interesting working with any kind of benchmark,

00:42.000 --> 00:46.000
it's a long investigation on performance in my school,

00:46.000 --> 00:50.000
but tried to scale it and it was so easy, of course.

00:50.000 --> 00:58.000
But at some point, so my school acquired my son acquired my school, sorry.

00:58.000 --> 01:03.000
And so in the previous talk, there is one my school version, which is misset,

01:03.000 --> 01:05.000
and I don't know if you recall this.

01:05.000 --> 01:08.000
There was person my school 5.4.

01:08.000 --> 01:17.000
And in fact, after 2008, some work at closely with my school team to improve performance.

01:17.000 --> 01:22.000
And I know from my school 5.4 for in 2009.

01:22.000 --> 01:25.000
For the first time, we published a benchmark result.

01:25.000 --> 01:29.000
So normally, we would not allow it to change into the record,

01:29.000 --> 01:33.000
but they were strong balls, they changed it.

01:33.000 --> 01:38.000
And we showed to Oracle, then we have better performance than Oracle database.

01:38.000 --> 01:42.000
Unfortunately, so it was presented during my school conference,

01:42.000 --> 01:44.000
and Oracle made a note and they acquired him son.

01:44.000 --> 01:51.000
So, and then all teams worked together, and then it was, well, now you see what we have.

01:51.000 --> 01:55.000
Well, there are many other also details, I will skip it,

01:55.000 --> 01:59.000
but if you want to know, we have a long history here.

01:59.000 --> 02:05.000
So today's talk will be about practical stuff.

02:05.000 --> 02:12.000
So this practical stuff came, if you want to hate somebody, you need to hate Amazon,

02:12.000 --> 02:17.000
because it's all about business, so Oracle should do cloud as well,

02:17.000 --> 02:22.000
because otherwise, you can see all the money going to Amazon,

02:22.000 --> 02:28.000
and my school team delivering product, and here's nothing just use everybody,

02:28.000 --> 02:32.000
and thank you, my school, for Amazon.

02:32.000 --> 02:37.000
So we started to do also real stuff, and, well, all this problem,

02:37.000 --> 02:40.000
well, not problem of my school team.

02:40.000 --> 02:44.000
Who cares about memory location, and now when I discuss it,

02:44.000 --> 02:47.000
live example, booking guys.

02:47.000 --> 02:51.000
So when they discuss it, then do we have other out of memory killer?

02:51.000 --> 02:54.000
Oh, yes, do you know why? Oh, no.

02:54.000 --> 02:56.000
How you manage this?

02:56.000 --> 02:58.000
We just have many replicas.

02:58.000 --> 03:02.000
So it died, it restarted, in other replicas.

03:02.000 --> 03:04.000
People did not care.

03:04.000 --> 03:07.000
In our case, you know, when we believe or something,

03:07.000 --> 03:10.000
it's our product, so we need to understand what's going on.

03:10.000 --> 03:13.000
In many cases, the problem was not ours.

03:13.000 --> 03:18.000
For example, you cannot imagine, but anti wires on your system,

03:18.000 --> 03:21.000
can just eat 16 gigs, we'll kill every single one.

03:21.000 --> 03:23.000
And disappear.

03:23.000 --> 03:27.000
And just see it on your medical service, not more here.

03:27.000 --> 03:31.000
So memory profiling was one of the main problems,

03:31.000 --> 03:35.000
and then CPU profiling came into our.

03:36.000 --> 03:38.000
You, we'll look back in history.

03:38.000 --> 03:41.000
So today was 30 years from my school,

03:41.000 --> 03:44.000
we can speak a lot about history.

03:44.000 --> 03:50.000
You see, the first maloclibrary was just not empty safe.

03:50.000 --> 03:53.000
Not much is how that saves.

03:53.000 --> 03:56.000
One of the, if we can empty safe,

03:56.000 --> 03:58.000
it doesn't mean it will scale.

03:58.000 --> 03:59.000
So just global lock.

03:59.000 --> 04:01.000
So every time spread allocations,

04:01.000 --> 04:04.000
we'll write in for the same matrix, and it's not scaling.

04:04.000 --> 04:07.000
So the first, the first one, which I recall,

04:07.000 --> 04:09.000
was whole library, which was scaling,

04:09.000 --> 04:12.000
and how people discover this, you know,

04:12.000 --> 04:14.000
well, you develop code.

04:14.000 --> 04:17.000
Most of code was implemented in the past and C,

04:17.000 --> 04:20.000
and when you manage your maloclocation,

04:20.000 --> 04:22.000
okay, you can't live with this.

04:22.000 --> 04:24.000
Each thread will allocate an unknown,

04:24.000 --> 04:26.000
big enough memory in your fine,

04:26.000 --> 04:30.000
and then the pay attention to not get too much contents on this.

04:30.000 --> 04:33.000
Once people started to move to C++,

04:33.000 --> 04:35.000
every time you create new variable,

04:35.000 --> 04:36.000
you have malocl,

04:36.000 --> 04:38.000
it's a malocl, a malocl,

04:38.000 --> 04:39.000
and every single one you have a fine,

04:39.000 --> 04:41.000
and you don't have control.

04:41.000 --> 04:45.000
So all this new library's came in game.

04:45.000 --> 04:48.000
G malocl was most popular on Linux.

04:48.000 --> 04:51.000
You have other for another system.

04:51.000 --> 04:53.000
I today prefer to see malocl,

04:53.000 --> 04:55.000
and I will explain new why.

04:55.000 --> 04:59.000
So when we deployed the first system,

04:59.000 --> 05:02.000
and started analyzing why,

05:02.000 --> 05:05.000
it cannot survive during one week.

05:05.000 --> 05:07.000
It was just because of this.

05:07.000 --> 05:12.000
So you have a loop on simple test work load,

05:12.000 --> 05:15.000
so we know there is no memory on my scale,

05:15.000 --> 05:19.000
but you have memory fragmentation coming from a bit similar.

05:19.000 --> 05:21.000
So your memory just growing growing growing,

05:21.000 --> 05:23.000
and it just will be finished in swap,

05:23.000 --> 05:25.000
and then you die.

05:25.000 --> 05:28.000
In worst case, there is no more memory,

05:28.000 --> 05:29.000
and every single frozen,

05:29.000 --> 05:30.000
you cannot boot the system,

05:30.000 --> 05:33.000
if you reset, and you don't know what to do.

05:33.000 --> 05:36.000
So in fact, this was first to discover,

05:36.000 --> 05:39.000
even it works well today.

05:39.000 --> 05:44.000
So it's more designed at now with multi-shrad,

05:44.000 --> 05:46.000
so there is no performance computation,

05:46.000 --> 05:48.000
the problem is memory fragmentation.

05:48.000 --> 05:51.000
The parent to see, to see malocl, you see.

05:51.000 --> 05:54.000
So it's, I tested it explicitly,

05:54.000 --> 05:56.000
two different versions of,

05:56.000 --> 05:58.000
to see malocl, just understand.

05:58.000 --> 06:01.000
With all versions, everything is fine,

06:01.000 --> 06:02.000
like with new one, it's fine,

06:02.000 --> 06:04.000
but ellipse malocl is like this.

06:04.000 --> 06:07.000
Before performance reason,

06:07.000 --> 06:10.000
and I'm mainly working with performance,

06:10.000 --> 06:11.000
you know, so,

06:11.000 --> 06:13.000
jim malocl is more efficient for performance,

06:13.000 --> 06:16.000
but for memory education,

06:16.000 --> 06:18.000
so it will free,

06:18.000 --> 06:20.000
you don't have this memory fragmentation,

06:20.000 --> 06:22.000
like with ellipse malocl,

06:22.000 --> 06:24.000
it will free or memory, okay,

06:24.000 --> 06:25.000
but you may have the spikes,

06:25.000 --> 06:26.000
because for performance,

06:26.000 --> 06:28.000
you would not pay attention,

06:28.000 --> 06:30.000
let's allocate memory as much as we want,

06:30.000 --> 06:31.000
and you have the spike,

06:31.000 --> 06:33.000
and you just kill your instance.

06:33.000 --> 06:34.000
So if you do test,

06:34.000 --> 06:35.000
and don't care,

06:35.000 --> 06:36.000
fine,

06:36.000 --> 06:37.000
in production,

06:37.000 --> 06:38.000
it's not possible.

06:42.000 --> 06:44.000
So the good point is,

06:44.000 --> 06:46.000
and in my scale today,

06:46.000 --> 06:48.000
so we have the performance schema,

06:48.000 --> 06:51.000
which was pushed at the end of my scale,

06:51.000 --> 06:52.000
five,

06:52.000 --> 06:53.000
it was horrible,

06:53.000 --> 06:55.000
with horrible overhead on the past,

06:55.000 --> 06:56.000
and then,

06:56.000 --> 06:57.000
big work,

06:57.000 --> 06:58.000
big optimization,

06:58.000 --> 07:00.000
work was done around,

07:00.000 --> 07:01.000
and we introduced

07:01.000 --> 07:04.000
memory allocation,

07:04.000 --> 07:06.000
so we have memory instrumentation,

07:06.000 --> 07:09.000
which will give you exactly what happens inside.

07:09.000 --> 07:12.000
It's working fine,

07:12.000 --> 07:14.000
so overhead was very big,

07:14.000 --> 07:15.000
on the beginning,

07:15.000 --> 07:16.000
but then not,

07:16.000 --> 07:17.000
but again,

07:17.000 --> 07:20.000
you cannot go until every malocl, right?

07:20.000 --> 07:22.000
So it can be too costly,

07:23.000 --> 07:26.000
most of the goal today is a C++ in my scale,

07:26.000 --> 07:29.000
so you cannot trace any allocation.

07:29.000 --> 07:31.000
So today,

07:31.000 --> 07:33.000
it's really great to see,

07:33.000 --> 07:34.000
and we have memory,

07:34.000 --> 07:38.000
it can be higher probability to have it in plugin,

07:38.000 --> 07:39.000
on something like this,

07:39.000 --> 07:42.000
but still it may happen.

07:42.000 --> 07:46.000
So when we started to deploy first cloud instance,

07:46.000 --> 07:48.000
it was surprised after surprise,

07:48.000 --> 07:51.000
because you may have some specific plugin,

07:51.000 --> 07:53.000
which will never use it,

07:53.000 --> 07:55.000
and will be used only when given customer,

07:55.000 --> 07:57.000
and this given customer has a problem.

07:57.000 --> 07:59.000
So the good point was,

07:59.000 --> 08:02.000
and TSMoc has memory profiler itself,

08:02.000 --> 08:04.000
and you can use it,

08:04.000 --> 08:08.000
and you can profile our memory to very digit details.

08:08.000 --> 08:10.000
How it works?

08:10.000 --> 08:13.000
All you need is just to set

08:13.000 --> 08:16.000
a heap profile in the Romance variable,

08:16.000 --> 08:18.000
so you start my scale,

08:18.000 --> 08:23.000
and I'll set it up with LDP load for TSMoc,

08:23.000 --> 08:25.000
and then as soon you start,

08:25.000 --> 08:27.000
it starts in bombarding with dumps.

08:27.000 --> 08:32.000
So the dumps are generated automatically,

08:32.000 --> 08:34.000
so we have few options I will show you,

08:34.000 --> 08:38.000
and you can manage which frequency one to have,

08:38.000 --> 08:43.000
and you can see it directly with P-prof,

08:43.000 --> 08:46.000
so it's dedicated tool made by Google.

08:46.000 --> 08:49.000
So it's always coming for Google DevTools,

08:49.000 --> 08:51.000
and you can get it in text,

08:51.000 --> 08:52.000
and you can get it in PDF,

08:52.000 --> 08:55.000
and PDF it's amazing because you really can follow

08:55.000 --> 08:58.000
your memory education from every function,

08:58.000 --> 09:01.000
and in fact you can understand what you're doing with your code,

09:01.000 --> 09:04.000
because people sometimes have different impressions,

09:04.000 --> 09:05.000
I should not do it,

09:05.000 --> 09:06.000
but they do,

09:06.000 --> 09:09.000
because another function will come in this one,

09:09.000 --> 09:10.000
and another here,

09:10.000 --> 09:13.000
and then at the end you can go to another place.

09:13.000 --> 09:15.000
So the only problem is,

09:15.000 --> 09:18.000
then if you did not put it on the start,

09:18.000 --> 09:20.000
you cannot get anything.

09:20.000 --> 09:22.000
So you need to restart my scale,

09:22.000 --> 09:25.000
and you need to have a pretty small case,

09:25.000 --> 09:29.000
because you know what happens in production.

09:29.000 --> 09:31.000
Oh, my memory is growing, why?

09:31.000 --> 09:33.000
Let's restart the most,

09:33.000 --> 09:34.000
if you restart that problem is gone,

09:34.000 --> 09:36.000
you cannot reproduce.

09:36.000 --> 09:39.000
So if only if you have reproducible case,

09:39.000 --> 09:42.000
you can debug it so well,

09:42.000 --> 09:44.000
that's the totalization for this.

09:44.000 --> 09:46.000
And again,

09:46.000 --> 09:47.000
the main point,

09:47.000 --> 09:48.000
and well,

09:48.000 --> 09:50.000
and jump a little bit ahead,

09:50.000 --> 09:53.000
of a hot overhead is very huge.

09:53.000 --> 09:56.000
So you cannot run production like this.

09:56.000 --> 10:10.000
So in fact,

10:10.000 --> 10:15.000
you can start it,

10:15.000 --> 10:18.000
and call API just to start

10:18.000 --> 10:21.000
and stop profiling on demand.

10:21.000 --> 10:26.000
So it's much more simple,

10:26.000 --> 10:27.000
but in theory,

10:27.000 --> 10:29.000
so in fact,

10:29.000 --> 10:30.000
just call in API,

10:30.000 --> 10:33.000
so we've got many discussions

10:33.000 --> 10:35.000
to be edited in my scale code,

10:35.000 --> 10:36.000
or probably not,

10:36.000 --> 10:37.000
or whatever,

10:37.000 --> 10:40.000
but on pile with TCMLog or not.

10:40.000 --> 10:42.000
And so on.

10:42.000 --> 10:43.000
And well,

10:43.000 --> 10:44.000
this discussion was going on

10:44.000 --> 10:45.000
and back and so,

10:45.000 --> 10:46.000
so in fact,

10:46.000 --> 10:48.000
every time we need it to use

10:48.000 --> 10:49.000
TCMLog profile,

10:49.000 --> 10:50.000
they all let's do it.

10:50.000 --> 10:52.000
And then when it's fine,

10:52.000 --> 10:54.000
so people just busy with something else.

10:54.000 --> 10:57.000
And just discuss it,

10:57.000 --> 10:58.000
oh,

10:58.000 --> 11:00.000
it was a few months before for them,

11:00.000 --> 11:02.000
discuss it with Fred,

11:02.000 --> 11:03.000
you know,

11:03.000 --> 11:04.000
I don't know why people,

11:04.000 --> 11:06.000
anytime we have a new problem,

11:06.000 --> 11:07.000
we will be in,

11:07.000 --> 11:08.000
in big trouble,

11:08.000 --> 11:11.000
and we still don't have the solution.

11:11.000 --> 11:14.000
They told me we need to use component,

11:14.000 --> 11:15.000
and Fred has,

11:15.000 --> 11:17.000
I don't know how many slides about

11:17.000 --> 11:18.000
component called developer.

11:18.000 --> 11:19.000
Well,

11:19.000 --> 11:20.000
if you do it all the time,

11:20.000 --> 11:21.000
it's easy.

11:21.000 --> 11:23.000
When you look at your time,

11:23.000 --> 11:24.000
if what?

11:24.000 --> 11:26.000
You have inflation,

11:26.000 --> 11:27.000
rich Chinese,

11:27.000 --> 11:28.000
I don't know.

11:28.000 --> 11:29.000
So,

11:29.000 --> 11:30.000
but it's market easy.

11:30.000 --> 11:32.000
So Fred told me,

11:32.000 --> 11:33.000
you really need it,

11:33.000 --> 11:35.000
you do you have some specification,

11:35.000 --> 11:37.000
I already have a page with the PI,

11:37.000 --> 11:38.000
I don't explain any of them.

11:38.000 --> 11:39.000
In the evening,

11:39.000 --> 11:41.000
you can try it,

11:41.000 --> 11:42.000
I can pilot,

11:42.000 --> 11:44.000
I cannot deliver.

11:44.000 --> 11:46.000
So,

11:46.000 --> 11:48.000
in fact,

11:48.000 --> 11:50.000
you don't need to compile with this envelope,

11:50.000 --> 11:53.000
so your component can be loaded,

11:53.000 --> 11:55.000
install it at any time,

11:55.000 --> 11:56.000
but you won't.

11:56.000 --> 11:57.000
So,

11:57.000 --> 11:59.000
all you need to just to deploy

11:59.000 --> 12:00.000
a GPR2,

12:00.000 --> 12:02.000
or a magical host,

12:02.000 --> 12:03.000
and this variable,

12:03.000 --> 12:04.000
you need to set up.

12:04.000 --> 12:05.000
So, first,

12:05.000 --> 12:06.000
a preload,

12:06.000 --> 12:08.000
a similar library from where you want,

12:08.000 --> 12:11.000
and then you have two variables,

12:11.000 --> 12:13.000
allocated interval.

12:13.000 --> 12:15.000
So, by default,

12:15.000 --> 12:16.000
it's one gig,

12:16.000 --> 12:17.000
I put it to zero,

12:17.000 --> 12:18.000
and use,

12:18.000 --> 12:19.000
and use interval also.

12:19.000 --> 12:20.000
It's one hundred next,

12:20.000 --> 12:21.000
I also put it to zero.

12:21.000 --> 12:22.000
Why?

12:22.000 --> 12:23.000
In fact,

12:23.000 --> 12:24.000
allocation.

12:24.000 --> 12:25.000
So,

12:25.000 --> 12:26.000
you may,

12:26.000 --> 12:27.000
in your code,

12:27.000 --> 12:28.000
you may allocate,

12:28.000 --> 12:29.000
and three memory,

12:29.000 --> 12:30.000
all the time, right?

12:30.000 --> 12:31.000
I trace it,

12:31.000 --> 12:33.000
my school code with dethrase.

12:34.000 --> 12:37.000
You cannot imagine how many millions per second

12:37.000 --> 12:38.000
we do in the lock,

12:38.000 --> 12:40.000
and this is keeping in mind,

12:40.000 --> 12:43.000
and we all have a memory library,

12:43.000 --> 12:45.000
which will all cache some data.

12:45.000 --> 12:46.000
So,

12:46.000 --> 12:47.000
it's not every time,

12:47.000 --> 12:50.000
when we need 10 bytes of memory,

12:50.000 --> 12:51.000
we will call them a lock.

12:51.000 --> 12:53.000
It's already reuse it.

12:53.000 --> 12:54.000
And any,

12:54.000 --> 12:55.000
in this case,

12:55.000 --> 12:56.000
it's many,

12:56.000 --> 12:57.000
many millions per second,

12:57.000 --> 12:58.000
okay?

12:58.000 --> 12:59.000
So,

12:59.000 --> 13:01.000
one gig,

13:01.000 --> 13:03.000
you allocate and three,

13:03.000 --> 13:05.000
it will be probably every two seconds.

13:05.000 --> 13:07.000
So, it just won't bother with these dumps,

13:07.000 --> 13:09.000
which for you probably not make no interest,

13:09.000 --> 13:11.000
because there is no leak.

13:11.000 --> 13:13.000
And the same,

13:13.000 --> 13:15.000
if you increase in memory,

13:15.000 --> 13:16.000
one hundred,

13:16.000 --> 13:18.000
one hundred megs,

13:18.000 --> 13:19.000
so you will have a new dump.

13:19.000 --> 13:20.000
Well,

13:20.000 --> 13:21.000
it may increase decrease,

13:21.000 --> 13:22.000
and so on,

13:22.000 --> 13:23.000
well,

13:23.000 --> 13:24.000
I don't care.

13:24.000 --> 13:25.000
I want to see,

13:25.000 --> 13:27.000
if there's already some big increase,

13:27.000 --> 13:29.000
then I'm interested.

13:30.000 --> 13:31.000
The good point here,

13:31.000 --> 13:32.000
is,

13:32.000 --> 13:35.000
you cannot make this stuff.

13:35.000 --> 13:38.000
You can monitor from other tools,

13:38.000 --> 13:39.000
system tools,

13:39.000 --> 13:40.000
for example,

13:40.000 --> 13:42.000
if your memory is growing in a nice scale,

13:42.000 --> 13:44.000
you just invoke this,

13:44.000 --> 13:48.000
your component may be already installed,

13:48.000 --> 13:49.000
you just invoke the dump,

13:49.000 --> 13:50.000
so,

13:50.000 --> 13:51.000
so,

13:51.000 --> 13:53.000
you get your information.

13:57.000 --> 13:58.000
So,

13:58.000 --> 14:01.000
Fred also add another one from Gmail look.

14:01.000 --> 14:02.000
If you want,

14:02.000 --> 14:03.000
well,

14:03.000 --> 14:04.000
you see,

14:04.000 --> 14:05.000
I prefer to see my look,

14:05.000 --> 14:06.000
because on Gmail look,

14:06.000 --> 14:07.000
so if you have this dump,

14:07.000 --> 14:08.000
so memory location,

14:08.000 --> 14:09.000
so go.

14:09.000 --> 14:11.000
It's interesting for,

14:11.000 --> 14:12.000
well,

14:12.000 --> 14:13.000
if you have free time to check,

14:13.000 --> 14:15.000
but we don't have too much now.

14:15.000 --> 14:16.000
So,

14:16.000 --> 14:18.000
just a few lines,

14:18.000 --> 14:19.000
how it works.

14:19.000 --> 14:20.000
So,

14:20.000 --> 14:21.000
if you have links,

14:21.000 --> 14:22.000
Fred already wrote,

14:22.000 --> 14:25.000
detailed documentation about every steps,

14:25.000 --> 14:27.000
I just put practical steps here.

14:28.000 --> 14:29.000
So, install component,

14:29.000 --> 14:30.000
as you want,

14:30.000 --> 14:31.000
so install,

14:31.000 --> 14:32.000
install,

14:32.000 --> 14:33.000
install,

14:33.000 --> 14:35.000
or install it in.

14:35.000 --> 14:36.000
So, we have,

14:36.000 --> 14:37.000
several components,

14:37.000 --> 14:39.000
so you have generate component profile,

14:39.000 --> 14:41.000
which managing all the staff,

14:41.000 --> 14:42.000
global variables and so on,

14:42.000 --> 14:44.000
and then you have dedicated profile,

14:44.000 --> 14:45.000
or memory.

14:45.000 --> 14:47.000
So, from select,

14:47.000 --> 14:48.000
from my scale component,

14:48.000 --> 14:49.000
you can see,

14:49.000 --> 14:51.000
everything related to your component,

14:51.000 --> 14:53.000
if you have global variables,

14:53.000 --> 14:54.000
and status variables,

14:54.000 --> 14:56.000
related to profile.

14:57.000 --> 14:59.000
So, when you do,

14:59.000 --> 15:00.000
profile are clear enough,

15:00.000 --> 15:02.000
it will clear all your dumps.

15:02.000 --> 15:04.000
So, you have clear on state.

15:04.000 --> 15:05.000
You can start,

15:05.000 --> 15:06.000
and stop,

15:06.000 --> 15:07.000
memory,

15:07.000 --> 15:08.000
profile are,

15:08.000 --> 15:09.000
call it down,

15:09.000 --> 15:10.000
if you want.

15:10.000 --> 15:11.000
So,

15:11.000 --> 15:13.000
I discuss it with Fred from,

15:13.000 --> 15:14.000
you know,

15:14.000 --> 15:15.000
when you test it in practically,

15:15.000 --> 15:16.000
so you see,

15:16.000 --> 15:18.000
and it's better than you have already done,

15:18.000 --> 15:19.000
on start,

15:19.000 --> 15:20.000
and always,

15:20.000 --> 15:21.000
a dump on stop,

15:21.000 --> 15:23.000
in case you forgot about.

15:23.000 --> 15:24.000
Because,

15:25.000 --> 15:27.000
other had maybe,

15:27.000 --> 15:29.000
maybe pretty high.

15:29.000 --> 15:30.000
So,

15:32.000 --> 15:34.000
in the start,

15:34.000 --> 15:36.000
we added all the additional options.

15:36.000 --> 15:38.000
You can start with parameter,

15:38.000 --> 15:41.000
stop it in 20 seconds,

15:41.000 --> 15:42.000
for example,

15:42.000 --> 15:43.000
and give it dump.

15:43.000 --> 15:44.000
Because,

15:44.000 --> 15:45.000
probably when you will start,

15:45.000 --> 15:47.000
you don't have handy anymore.

15:47.000 --> 15:49.000
So, your might scale,

15:49.000 --> 15:50.000
client will not work,

15:50.000 --> 15:52.000
and you will have no way to stop it.

15:52.000 --> 15:53.000
Anything may happen.

15:53.000 --> 15:54.000
Right?

15:54.000 --> 15:57.000
So, we are about security here.

15:57.000 --> 16:00.000
And here's the test case.

16:02.000 --> 16:04.000
So, we,

16:04.000 --> 16:07.000
preload the similar cleverer,

16:07.000 --> 16:10.000
set in heap allocation variables,

16:10.000 --> 16:11.000
start in server,

16:11.000 --> 16:13.000
so both this as script,

16:13.000 --> 16:14.000
based on benchmark kit.

16:14.000 --> 16:16.000
So, you will have a link,

16:16.000 --> 16:17.000
then.

16:17.000 --> 16:19.000
So, we just pre-form,

16:19.000 --> 16:20.000
we use,

16:20.000 --> 16:21.000
we use both our pool,

16:21.000 --> 16:23.000
sides of sort of two gigs.

16:23.000 --> 16:24.000
So, it will be pre-formed,

16:24.000 --> 16:26.000
and then we play in with,

16:26.000 --> 16:27.000
with data,

16:27.000 --> 16:28.000
which are small,

16:28.000 --> 16:30.000
it will be only 20 gigs.

16:30.000 --> 16:31.000
But, it will allocate memory,

16:31.000 --> 16:33.000
because we use order at range,

16:33.000 --> 16:34.000
so we have,

16:34.000 --> 16:35.000
group by inside,

16:35.000 --> 16:36.000
order and so on.

16:36.000 --> 16:37.000
And,

16:37.000 --> 16:38.000
and,

16:38.000 --> 16:39.000
at then,

16:39.000 --> 16:40.000
we want to have a report.

16:40.000 --> 16:41.000
So,

16:41.000 --> 16:43.000
the test load is coming from sort of two,

16:43.000 --> 16:44.000
whatever uses,

16:44.000 --> 16:46.000
finishes by 4,000.

16:46.000 --> 16:47.000
Just for several,

16:47.000 --> 16:48.000
to see them,

16:48.000 --> 16:49.000
to allocate a lot of memory,

16:49.000 --> 16:51.000
and then it will go down.

16:51.000 --> 16:52.000
Okay, and as you can see,

16:52.000 --> 16:53.000
we start from,

16:53.000 --> 16:55.000
just for 60 seconds,

16:55.000 --> 16:56.000
second,

16:56.000 --> 16:57.000
a profiler,

16:57.000 --> 16:58.000
to be sure,

16:58.000 --> 16:59.000
and we,

16:59.000 --> 17:00.000
it will always stop it,

17:00.000 --> 17:02.000
and we don't need to have interest.

17:02.000 --> 17:04.000
What happens next?

17:04.000 --> 17:09.000
So, the first rough is just to show,

17:09.000 --> 17:10.000
you,

17:10.000 --> 17:11.000
okay,

17:11.000 --> 17:13.000
it's three loops of the test.

17:13.000 --> 17:15.000
Connections going to 4,000.

17:15.000 --> 17:16.000
Fine.

17:16.000 --> 17:17.000
Now,

17:17.000 --> 17:19.000
what happens to memory?

17:19.000 --> 17:21.000
So, you say,

17:21.000 --> 17:22.000
memory,

17:22.000 --> 17:23.000
allocation,

17:23.000 --> 17:25.000
and Linux is something.

17:25.000 --> 17:26.000
So, it's, I don't know,

17:26.000 --> 17:28.000
it's can be one day dedicated to talk,

17:28.000 --> 17:29.000
and it's then,

17:29.000 --> 17:30.000
it will not know the truth,

17:30.000 --> 17:32.000
because as many experts you have on Linux

17:32.000 --> 17:34.000
kernel, as many opinion we will have.

17:34.000 --> 17:35.000
So,

17:35.000 --> 17:36.000
you have virtual size,

17:36.000 --> 17:37.000
which is,

17:37.000 --> 17:38.000
virtual expectation,

17:38.000 --> 17:39.000
if you have real size,

17:39.000 --> 17:40.000
or a test.

17:40.000 --> 17:41.000
So,

17:41.000 --> 17:42.000
in virtual,

17:42.000 --> 17:43.000
swap,

17:43.000 --> 17:44.000
allocation is based,

17:44.000 --> 17:45.000
it also on this.

17:45.000 --> 17:46.000
So, you can see,

17:46.000 --> 17:48.000
we allocated,

17:48.000 --> 17:50.000
how much eight gigs

17:50.000 --> 17:52.000
from the start of the test.

17:52.000 --> 17:53.000
And then we don't free,

17:53.000 --> 17:54.000
well,

17:54.000 --> 17:55.000
free,

17:55.000 --> 17:56.000
some part,

17:56.000 --> 17:58.000
but we'll go up and down and so on.

17:58.000 --> 17:59.000
So,

17:59.000 --> 18:01.000
in real allocation,

18:01.000 --> 18:02.000
we'll allocate them less,

18:02.000 --> 18:04.000
and then it will vary it

18:04.000 --> 18:06.000
about one,

18:06.000 --> 18:07.000
dot five gigs,

18:07.000 --> 18:08.000
some say like this.

18:08.000 --> 18:09.000
So,

18:09.000 --> 18:10.000
well,

18:10.000 --> 18:11.000
because some memory will be used,

18:11.000 --> 18:12.000
or they'll look at it

18:12.000 --> 18:13.000
and never free,

18:13.000 --> 18:14.000
one,

18:14.000 --> 18:15.000
some will be free,

18:15.000 --> 18:16.000
some use it by

18:16.000 --> 18:18.000
some cash in and so on.

18:18.000 --> 18:20.000
Now,

18:20.000 --> 18:22.000
from performance schema,

18:22.000 --> 18:25.000
we can see what is allocated.

18:25.000 --> 18:27.000
So, you can see the green line,

18:27.000 --> 18:29.000
this is performance schema allocation.

18:29.000 --> 18:31.000
So, in fact, you need to keep in mind,

18:31.000 --> 18:33.000
performance schema,

18:33.000 --> 18:35.000
has some memory dedicated

18:35.000 --> 18:36.000
for each connection.

18:36.000 --> 18:38.000
So, we arrive at the four south of the case,

18:38.000 --> 18:40.000
one gig,

18:40.000 --> 18:42.000
250 megs,

18:42.000 --> 18:44.000
will be always allocated till the restart.

18:45.000 --> 18:47.000
The main point,

18:47.000 --> 18:49.000
I want to mention here,

18:49.000 --> 18:51.000
you can see them before

18:51.000 --> 18:54.000
to go into 4,000 from 2,000.

18:54.000 --> 18:57.000
It's going from 750 to 1,

18:57.000 --> 19:00.000
so it's 500 megs here.

19:00.000 --> 19:02.000
So, just one jump,

19:02.000 --> 19:03.000
I can renext.

19:03.000 --> 19:05.000
We will see how it's reported

19:05.000 --> 19:07.000
from TCMA log.

19:07.000 --> 19:11.000
Just to mention them from performance schema,

19:11.000 --> 19:13.000
you can see in details,

19:13.000 --> 19:14.000
which,

19:14.000 --> 19:19.000
which part of the performance schema,

19:19.000 --> 19:21.000
which part of whatever else,

19:21.000 --> 19:23.000
allocated the memory and how much.

19:23.000 --> 19:25.000
So, the performance schema

19:25.000 --> 19:27.000
allocated and keep it,

19:27.000 --> 19:28.000
and you know exactly where.

19:28.000 --> 19:30.000
And here we have,

19:30.000 --> 19:33.000
you see memory allocated in 3,

19:33.000 --> 19:34.000
allocated in 3.

19:34.000 --> 19:36.000
It was from SQL bar,

19:36.000 --> 19:37.000
on the file sort,

19:37.000 --> 19:40.000
and also on SQL,

19:41.000 --> 19:43.000
it's a main root sort,

19:43.000 --> 19:46.000
self-cash and a memory location in my SQL.

19:46.000 --> 19:47.000
So, okay,

19:47.000 --> 19:49.000
the performance schema tells this.

19:49.000 --> 19:51.000
Now, let's see what they say in TCMA log,

19:51.000 --> 19:53.000
profile.

19:53.000 --> 19:55.000
So, you can see,

19:55.000 --> 19:56.000
you can see,

19:56.000 --> 19:57.000
it's 3 iteration,

19:57.000 --> 19:59.000
from the first report,

19:59.000 --> 20:01.000
it's exactly reporting 500 megs

20:01.000 --> 20:03.000
for performance schema location.

20:03.000 --> 20:04.000
Good,

20:04.000 --> 20:07.000
we are all agree.

20:08.000 --> 20:11.000
And then, if we look more in details,

20:11.000 --> 20:14.000
so we will say that it also reported

20:14.000 --> 20:15.000
for 5 sort,

20:15.000 --> 20:17.000
the same and the same for memory.

20:17.000 --> 20:19.000
So, exactly the same stuff,

20:19.000 --> 20:21.000
which we have in performance schema,

20:21.000 --> 20:24.000
and so, just the colorate,

20:24.000 --> 20:27.000
and it's all coming to the same stuff.

20:27.000 --> 20:30.000
So, the good point is,

20:30.000 --> 20:33.000
very easy to do it from my SQL connects directly.

20:33.000 --> 20:36.000
So, once you know it's in place,

20:36.000 --> 20:39.000
you can install the uninstall as you want.

20:39.000 --> 20:41.000
You start the term demand.

20:41.000 --> 20:43.000
The dumps are really small,

20:43.000 --> 20:46.000
so you don't use this place and so on.

20:46.000 --> 20:48.000
So, if it's disabled,

20:48.000 --> 20:50.000
there is no impact.

20:50.000 --> 20:51.000
The main problem is,

20:51.000 --> 20:52.000
when you enable,

20:52.000 --> 20:55.000
it's mostly stopped the world.

20:55.000 --> 20:56.000
So, that's fine.

20:56.000 --> 20:58.000
So, it's,

20:58.000 --> 21:01.000
so what happens inside probably can be improved,

21:01.000 --> 21:02.000
I don't know,

21:02.000 --> 21:03.000
but,

21:03.000 --> 21:05.000
well, it's not to be running production.

21:05.000 --> 21:08.000
It's when you want to have a snapshot of your memory,

21:08.000 --> 21:12.000
where it's going for a short period that will be enough.

21:12.000 --> 21:14.000
So,

21:14.000 --> 21:15.000
I enjoy even more now,

21:15.000 --> 21:16.000
performance schema,

21:16.000 --> 21:20.000
because this one is always enabled by default,

21:20.000 --> 21:24.000
and you have the same information with minimal cost.

21:24.000 --> 21:25.000
You know,

21:25.000 --> 21:29.000
the first person of performance schema,

21:29.000 --> 21:31.000
memory instrumentation,

21:31.000 --> 21:33.000
was having something like

21:34.000 --> 21:37.000
such a person who never had a new enable.

21:37.000 --> 21:38.000
And we were,

21:38.000 --> 21:39.000
we were resitating,

21:39.000 --> 21:41.000
and we were during my school conference,

21:41.000 --> 21:42.000
and okay,

21:42.000 --> 21:43.000
which will present this stuff,

21:43.000 --> 21:44.000
but people complain,

21:44.000 --> 21:47.000
as there was many users coming in the complainet,

21:47.000 --> 21:48.000
can you reduce,

21:48.000 --> 21:49.000
can you reduce,

21:49.000 --> 21:50.000
and there was a guy arrive at,

21:50.000 --> 21:51.000
guys,

21:51.000 --> 21:53.000
we solved the production problem,

21:53.000 --> 21:55.000
even it will be hard,

21:55.000 --> 21:56.000
one had,

21:56.000 --> 21:58.000
a person who never had,

21:58.000 --> 21:59.000
doesn't matter,

21:59.000 --> 22:01.000
because it pointed at the problem of solving it.

22:01.000 --> 22:02.000
So, okay,

22:02.000 --> 22:03.000
then we'll continue to now,

22:03.000 --> 22:04.000
it's really fine.

22:04.000 --> 22:06.000
Here we have example of PDF,

22:06.000 --> 22:08.000
you can get from,

22:08.000 --> 22:10.000
a similar profile of,

22:10.000 --> 22:11.000
so you see,

22:11.000 --> 22:13.000
you can really see all the story,

22:13.000 --> 22:14.000
if you're,

22:14.000 --> 22:15.000
it's pretty lonely,

22:15.000 --> 22:16.000
you can put it on slide,

22:16.000 --> 22:17.000
if I put it on slide,

22:17.000 --> 22:18.000
you will see nothing,

22:18.000 --> 22:19.000
but you see,

22:19.000 --> 22:21.000
all allocation going,

22:21.000 --> 22:22.000
how many,

22:22.000 --> 22:23.000
megabyte,

22:23.000 --> 22:24.000
going to each function,

22:24.000 --> 22:28.000
and you can follow exactly the chain of allocation.

22:28.000 --> 22:30.000
And then,

22:31.000 --> 22:33.000
when I discuss it to Fred about the component,

22:33.000 --> 22:34.000
you know,

22:34.000 --> 22:35.000
I said,

22:35.000 --> 22:38.000
I discuss it with developers,

22:38.000 --> 22:40.000
inside of my school team,

22:40.000 --> 22:42.000
well,

22:42.000 --> 22:44.000
we can have memory allocation,

22:44.000 --> 22:45.000
and in my mind,

22:45.000 --> 22:46.000
what's okay,

22:46.000 --> 22:49.000
if one day is agreed to have something

22:49.000 --> 22:51.000
which can enable,

22:51.000 --> 22:53.000
a similar profile of the API,

22:53.000 --> 22:55.000
then I will speak them next step about CPU,

22:55.000 --> 22:57.000
because you also have CPU profile.

22:57.000 --> 22:58.000
Fred,

22:59.000 --> 23:00.000
oh really,

23:00.000 --> 23:01.000
in the morning,

23:01.000 --> 23:02.000
next day in the morning,

23:02.000 --> 23:04.000
you have CPU profile.

23:06.000 --> 23:07.000
Easy,

23:07.000 --> 23:08.000
the component,

23:08.000 --> 23:10.000
I will call him component month,

23:10.000 --> 23:12.000
so if you need anything about component,

23:12.000 --> 23:14.000
one point about components,

23:14.000 --> 23:15.000
you know,

23:15.000 --> 23:17.000
you always need to keep in mind

23:17.000 --> 23:18.000
and it's part of,

23:18.000 --> 23:19.000
once you started,

23:19.000 --> 23:21.000
it's part of my school process.

23:21.000 --> 23:22.000
So if you,

23:22.000 --> 23:23.000
it's easy to write,

23:23.000 --> 23:25.000
but if you do it,

23:25.000 --> 23:27.000
you do a mistake inside,

23:27.000 --> 23:29.000
just crush your server directly.

23:29.000 --> 23:30.000
There is,

23:30.000 --> 23:31.000
there is no way.

23:31.000 --> 23:33.000
If you part of the code,

23:33.000 --> 23:34.000
it's like you,

23:34.000 --> 23:35.000
you added,

23:35.000 --> 23:36.000
I don't know,

23:36.000 --> 23:37.000
I can say it.

23:37.000 --> 23:38.000
So with CPU,

23:38.000 --> 23:39.000
profiler,

23:39.000 --> 23:40.000
the biggest surprise,

23:40.000 --> 23:42.000
zero overhead.

23:42.000 --> 23:43.000
So if for memory,

23:43.000 --> 23:45.000
or you have,

23:45.000 --> 23:46.000
you say,

23:46.000 --> 23:48.000
the problem with,

23:48.000 --> 23:50.000
profiling of the code,

23:50.000 --> 23:52.000
you see if you use P stack,

23:52.000 --> 23:54.000
for example.

23:55.000 --> 23:56.000
Any,

23:56.000 --> 23:58.000
interested in about the stack,

23:58.000 --> 23:59.000
may give you a problem.

23:59.000 --> 24:00.000
So for example,

24:00.000 --> 24:01.000
you cannot find production,

24:01.000 --> 24:03.000
and check your stack all the time.

24:03.000 --> 24:04.000
At some point,

24:04.000 --> 24:05.000
you will kill your instance.

24:05.000 --> 24:06.000
And it doesn't matter.

24:06.000 --> 24:07.000
My scale,

24:07.000 --> 24:08.000
or I'll go to the database, whatever,

24:08.000 --> 24:10.000
whatever process you scan you with this,

24:10.000 --> 24:11.000
at some point,

24:11.000 --> 24:13.000
you will kill it.

24:13.000 --> 24:14.000
The same,

24:14.000 --> 24:15.000
with GDB will,

24:15.000 --> 24:17.000
GDB probably,

24:17.000 --> 24:18.000
but we stop it anyway.

24:18.000 --> 24:21.000
So it's pretty dangerous,

24:21.000 --> 24:23.000
and generally you have overhead.

24:23.000 --> 24:26.000
Here it's not overhead at all.

24:26.000 --> 24:28.000
But,

24:28.000 --> 24:30.000
the only interesting stuff,

24:30.000 --> 24:32.000
that something which won't

24:32.000 --> 24:33.000
profile with Perf,

24:33.000 --> 24:35.000
and something which you won't

24:35.000 --> 24:38.000
profile with Google Perf,

24:38.000 --> 24:40.000
CPU profiler,

24:40.000 --> 24:43.000
they don't tell you the same story.

24:43.000 --> 24:45.000
So who is right?

24:45.000 --> 24:46.000
Who is not?

24:46.000 --> 24:48.000
It's hard to say.

24:48.000 --> 24:50.000
So my,

24:51.000 --> 24:53.000
you know,

24:53.000 --> 24:54.000
just use both,

24:54.000 --> 24:56.000
because we,

24:56.000 --> 24:58.000
we working with different hardware

24:58.000 --> 24:59.000
vendor, for example,

24:59.000 --> 25:02.000
when you run Perf on virtual machine,

25:02.000 --> 25:04.000
it will just slow down already

25:04.000 --> 25:05.000
everything you're doing.

25:05.000 --> 25:07.000
But we have also vendors,

25:07.000 --> 25:09.000
when it's impossible to run Perf.

25:09.000 --> 25:10.000
You start Perf,

25:10.000 --> 25:12.000
and this just stops you work.

25:12.000 --> 25:13.000
So everything,

25:13.000 --> 25:14.000
even in your cell,

25:14.000 --> 25:15.000
it's,

25:15.000 --> 25:16.000
it's,

25:16.000 --> 25:17.000
it's not,

25:17.000 --> 25:18.000
it's not.

25:18.000 --> 25:20.000
So this is probably a solution,

25:20.000 --> 25:21.000
at least on the sandwich zone.

25:21.000 --> 25:22.000
And well,

25:22.000 --> 25:23.000
some part of,

25:23.000 --> 25:25.000
through is here anyway,

25:25.000 --> 25:26.000
because I,

25:26.000 --> 25:27.000
is,

25:27.000 --> 25:28.000
I can believe,

25:28.000 --> 25:29.000
and again,

25:29.000 --> 25:30.000
lip system,

25:30.000 --> 25:31.000
and receive,

25:31.000 --> 25:32.000
we spend a lot of time,

25:32.000 --> 25:33.000
because there is communication.

25:33.000 --> 25:34.000
Why it's not reported in Perf,

25:34.000 --> 25:35.000
I don't know.

25:35.000 --> 25:37.000
So probably combining both,

25:37.000 --> 25:40.000
you can get a full picture about everything.

25:40.000 --> 25:44.000
And so,

25:45.000 --> 25:47.000
you have reference,

25:47.000 --> 25:48.000
but,

25:48.000 --> 25:49.000
blog,

25:49.000 --> 25:50.000
if you don't know,

25:50.000 --> 25:51.000
blog from Perf,

25:51.000 --> 25:52.000
so you need to,

25:52.000 --> 25:53.000
to put it on the big lines.

25:53.000 --> 25:55.000
So you have all the details about

25:55.000 --> 25:56.000
the components inside.

25:56.000 --> 25:59.000
It's very well written document.

25:59.000 --> 26:01.000
It's a technical writer,

26:01.000 --> 26:02.000
which,

26:02.000 --> 26:03.000
developer,

26:03.000 --> 26:04.000
component money,

26:04.000 --> 26:05.000
whatever else.

26:05.000 --> 26:06.000
And so,

26:06.000 --> 26:07.000
well,

26:07.000 --> 26:08.000
and I have,

26:08.000 --> 26:09.000
tools,

26:09.000 --> 26:10.000
blog,

26:10.000 --> 26:11.000
and benchmark,

26:11.000 --> 26:12.000
it's interesting.

26:13.000 --> 26:15.000
So the last one is just to celebrate

26:15.000 --> 26:17.000
30 hours with the cake and,

26:17.000 --> 26:19.000
and firework.

26:19.000 --> 26:20.000
Thank you.

26:20.000 --> 26:21.000
Thank you.

26:21.000 --> 26:23.000
Thank you.

26:23.000 --> 26:24.000
Thank you.

26:24.000 --> 26:25.000
Thank you.

26:25.000 --> 26:27.000
Thank you.

26:27.000 --> 26:29.000
We have time for more questions.

26:29.000 --> 26:31.000
Yeah,

26:31.000 --> 26:32.000
I got to leave.

26:32.000 --> 26:34.000
What I'm talking about,

26:34.000 --> 26:35.000
about the digital money,

26:35.000 --> 26:36.000
and the memory profiling,

26:36.000 --> 26:38.000
so it's a really consider,

26:39.000 --> 26:40.000
already system profiling,

26:40.000 --> 26:41.000
and I'm not saying that,

26:41.000 --> 26:42.000
just by the point,

26:42.000 --> 26:43.000
you are one of the balance profiling.

26:43.000 --> 26:45.000
So if I change the digital

26:45.000 --> 26:46.000
of the digital money,

26:46.000 --> 26:47.000
where does the digital money

26:47.000 --> 26:48.000
then we have that,

26:48.000 --> 26:49.000
you know,

26:49.000 --> 26:50.000
where it doesn't know that.

26:50.000 --> 26:51.000
And right now,

26:51.000 --> 26:52.000
you know,

26:52.000 --> 26:54.000
the digital money is going to come from

26:54.000 --> 26:55.000
the digital money.

26:55.000 --> 26:56.000
You,

26:56.000 --> 26:57.000
you speak about memory profiling, right?

26:57.000 --> 26:58.000
I've had a lot of digital profiling.

26:58.000 --> 26:59.000
But,

26:59.000 --> 27:01.000
it doesn't matter what you do,

27:01.000 --> 27:02.000
right?

27:02.000 --> 27:04.000
It will show you what happens.

27:04.000 --> 27:05.000
So,

27:05.000 --> 27:06.000
we know that,

27:06.000 --> 27:07.000
so it means only for,

27:07.000 --> 27:08.000
so,

27:08.000 --> 27:09.000
you need to select,

27:09.000 --> 27:10.000
for example,

27:10.000 --> 27:11.000
to sign up,

27:11.000 --> 27:13.000
we have one library

27:13.000 --> 27:15.000
that allows you to provide memory

27:15.000 --> 27:16.000
once it provides you,

27:16.000 --> 27:17.000
and one,

27:17.000 --> 27:18.000
provide memory,

27:18.000 --> 27:19.000
and it's easy.

27:19.000 --> 27:20.000
And,

27:20.000 --> 27:21.000
we do a master deal with that,

27:21.000 --> 27:23.000
so we need all the rest of your

27:23.000 --> 27:24.000
operations,

27:24.000 --> 27:25.000
that doesn't care.

27:25.000 --> 27:26.000
Okay,

27:26.000 --> 27:27.000
so,

27:27.000 --> 27:28.000
it's a point,

27:28.000 --> 27:29.000
about,

27:29.000 --> 27:30.000
about,

27:30.000 --> 27:32.000
about,

27:32.000 --> 27:33.000
about,

27:33.000 --> 27:34.000
about,

27:34.000 --> 27:34.960
about,

27:34.960 --> 27:35.000
about,

27:35.000 --> 27:35.340
about,

27:35.340 --> 27:39.000
about,

27:39.000 --> 27:40.000
about,

27:40.000 --> 27:41.000
about,

27:41.000 --> 27:42.020
about,

27:42.020 --> 27:42.060
about,

27:42.060 --> 27:43.000
about,

27:43.000 --> 27:44.000
that,

27:44.000 --> 27:46.020
about,

27:46.020 --> 27:46.040
about,

27:46.040 --> 27:47.000
doubt,

27:47.000 --> 27:47.340
about,

27:48.340 --> 27:49.000
about,

27:50.000 --> 28:00.000
about, about, about, about, about, about, about COPI started,

28:00.000 --> 28:01.320
about invisible real economy working,

28:01.320 --> 28:02.000
about,

28:02.000 --> 28:03.000
about deposits

28:03.000 --> 28:11.040
side. So that your CPU is faster or slower. So it depends on frequency inside. So in

28:11.040 --> 28:16.880
GPRF tools, you don't have option to say at which frequency you want to get a snapshot

28:16.880 --> 28:24.240
about on this term. In Perf, you can say my frequency is 99 or 9 million. So you will get

28:24.240 --> 28:30.320
a bit higher overhead all over. So in this one is overhead is lower because probably

28:30.640 --> 28:35.560
frequency is not a big. And that's why you don't have much overhead. But if you

28:35.560 --> 28:41.200
use CPU a lot, so you have a spike in usage, you can be able to put down the stand

28:41.200 --> 28:45.840
where is it. Because whatever frequency you use, it's something big which will be always

28:45.840 --> 28:46.840
on top.

28:46.840 --> 28:52.040
And then, can you use this number of files on that, that you've got all this should be

28:52.040 --> 28:55.480
brought to the source on the network over the frequency.

28:55.480 --> 28:59.760
No, it's whatever you allocate memory, you can use it. It's just about my skill

28:59.760 --> 29:04.520
instance, right. So it doesn't matter if it's replica of source.

29:13.000 --> 29:19.880
You cannot on the same time. Because you replace memory locator. So I was surprised

29:19.880 --> 29:24.760
that with Lipsy Moloc, you don't have these Lipsy Molocs integrated directly in the

29:24.760 --> 29:29.040
kernel. And if you want to test the different changes on the Lipsy Moloc, it's

29:29.040 --> 29:36.920
silly story, it's time. So if one day it will be externalized, it will make life more

29:36.920 --> 29:43.040
simple, but not for the. So Oracle Linux team addresses this. And they fight and

29:43.040 --> 29:48.840
also they won't, they made some improvement. So then they can stable memory

29:48.840 --> 29:55.840
location. So what, but you don't have profiler inside.

29:55.840 --> 30:00.840
Yeah.

30:00.840 --> 30:24.840
You see, because performance team has so low overhead, because of design. So you say initially,

30:24.840 --> 30:30.200
it was like Lipsy and so on. And with scratch it's the head, with Markov, especially

30:30.200 --> 30:38.840
pasted days in office. So it was, at the time it was some of his head in Paris. And we made

30:38.840 --> 30:45.240
it step by step. So my fight was, and you know, if you're too, which you want to use, give

30:45.240 --> 30:51.600
you bigger overheads on your application, it's useless. And the resistance fight inside

30:51.600 --> 30:56.640
of my skill, okay, we want to, we will do correctness first and performance rest. But when

30:56.640 --> 31:02.400
you enable the performance team, I have blockbuster about this and the past, you just

31:02.400 --> 31:06.680
kill performance. And so you can't show anything because your problem is gone, because

31:06.680 --> 31:12.720
your instrumentation is so heavy, then you remove the problem by yourself. It's not for.

31:12.720 --> 31:17.080
So in performance team, I have to show you all the case. And it's, it's memory. It's

31:17.080 --> 31:21.960
going so fast. And whatever you add some counter, which will have contention, you deal

31:21.960 --> 31:28.760
with everybody. So memory instrumentation is local to each thread, okay. And then when you

31:28.760 --> 31:37.400
run a query, it will just run through all's heads and bring you a summary. But it cannot

31:37.400 --> 31:43.480
be one place or storage or whatever else. Everything will be in memory until your thread

31:43.480 --> 31:49.160
is here. Once your connection is going down, the case is going down. But information about

31:49.160 --> 31:54.680
each thread, we cannot do also, you know, in performance team, and every time you have a

31:54.680 --> 31:58.960
new connection, we'll allocate memory in the free again, allocate and free again.

31:58.960 --> 32:04.360
You know, do you say that it works in the grace of the rest hour from the new thread to

32:04.360 --> 32:06.360
release performance team on the real world?

32:06.360 --> 32:11.560
No, performance team, what's your reach for 1000 connections? It will keep memory for

32:11.560 --> 32:17.200
1000 connections. So it's more safe to use proxy as hell, for example, which will keep

32:17.200 --> 32:22.200
force of non-connections. But in reality, you will have to hunt it on my scale server.

32:22.200 --> 32:29.360
See, because once this memory is allocated, it will be allocated. Well, otherwise, this memory

32:29.360 --> 32:34.800
fragmentation story, because you know, when we deploy my scale, most people don't think

32:34.800 --> 32:39.960
to install gmail, or ccmlog. So they will have memory for fragmentation all the time, because

32:39.960 --> 32:43.440
it's huge amount of memory. And you will die much more faster.

32:48.200 --> 32:56.000
Yeah, so you have, but you can see that some memory is freed. But, now, in performance

32:56.000 --> 33:00.880
team, I guess, by design like this. So it was explicitly designed like this to not

33:00.880 --> 33:07.440
free-wall. I test 4,000 or 32,000 connections just because I want to see if it will

33:07.440 --> 33:13.880
pass or not. But when we look in production, so some not so many people have so many.

33:13.960 --> 33:19.200
You can modify the impact of my schema by set mix. Yeah, sure. And you can do it very

33:19.200 --> 33:23.840
though. Not here, you want to mix a feature request on it. But when we do it, you can't

33:23.840 --> 33:30.240
separate. Could we also do a schema? Why not? But it's possible, but we're very very

33:30.240 --> 33:36.880
go for the VCS. It's possible. Thank you.

33:36.880 --> 33:37.880
Thank you.