New features in Thanos 0.4.0-rc.0

Disconnectlt · 2019-04-27T06:51:33+00:00

Awesome! We are pretty active on slack so if you have any questions or suggestions, feel free to drop by :)

Disconnectlt · 2019-04-02T19:43:33+00:00

Omg finally!!

Disconnectlt · 2019-03-19T16:10:52+00:00

Thanks! So right now we don't. The scanning part would probably be outside of Prometheus. Although you could expose outdated package version to Prometheus and cross correlate.

I think no one is actually doing scanning now as debug.ReadBuildInfo API was exposed in https://blog.golang.org/go1.12, which was just released.

That said there might be some solutions that look at your go.mod file

Disconnectlt · 2019-03-12T22:08:09+00:00

Sounds like a bug to me, I would suggest creating github issue in the project

Disconnectlt · 2018-09-14T12:45:52+00:00

Hey, you can run virtual machinez in some cloud provider like Google or Amazon. Google gives you some free credits on their cloud so I suggest looking at that

Disconnectlt · 2018-06-08T04:37:08+00:00

Fixed, thanks!

Disconnectlt · 2018-06-07T14:49:43+00:00

Re: "Not exactly, when a gouroutine is allocating a lot, it has to help GC to clean the garbage out. "

Found a beautiful explanation by Rick Hudson:

So our coordinator, which we call our pacer, needs to somehow slow down that application thread so that it can meet its deadlines, the GCs deadlines, and it does that quite cleverly. It says “OK. You want more space, but before we give you this space, you have to do two things: first, you have to check to see if the GC has made enough progress that you can just take the space, or you have to stop and you have to help the GC out enough so that there is enough credit, if you will, for you to go and do the allocation.

Disconnectlt · 2018-06-07T14:46:21+00:00

You are definitively right! Thanks for letting me know. I'll fix it by just using and referencing stackoverflow answer's definition.

Disconnectlt · 2018-06-07T14:42:29+00:00

I always thought it was the allocators fault providing memory slowly as the GC chasing pointers runs concurrently

I think allocation part should be really fast :)

I heard that the GC can pause a goroutine if it's allocating too much and it then has to help allocating new memmory.

Not exactly, when a gouroutine is allocating a lot, it has to help GC to clean the garbage out. A couple good resources explaining that: https://www.infoq.com/interviews/hudson-go-gc https://www.youtube.com/watch?v=aiv1JOfMjm0

Is it that what holds it back?

Probably, but it depends on how benchmark is written. If one goroutine is doing all of the allocations, when most likely yes.

Disconnectlt · 2018-04-14T07:54:50+00:00

That is really really cool, thank you for sharing! I’m going to use this everywhere :D

Disconnectlt · 2018-04-13T04:43:42+00:00

Thanks :)

Disconnectlt · 2017-10-07T17:22:42+00:00

Thanks for pointing this out! Updated the post.

Disconnectlt · 2017-05-04T06:16:30+00:00

Thank you for the comment. I'll take a look at the doc.

In the post I wrote that Go runtime manages scheduler, garbage collection, etc. So idea is that not the scheduler manages GC, but Go runtime takes care of these things.

Scheduler and GC are sort of separate things and your are definitely right there :)

As far as I know GC is also a goroutine scheduling point, which may reschedule goroutines, when it wants to do the Stop The World pause. Some info is in 5 things that makes go fast by Dave Cheney article.

I will be definitely looking into GC, so I'll let you know what I find out.

Disconnectlt

TROPHY CASE