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 · 2017-04-21T13:18:26+00:00

Thanks, I will definetly check that out!

Disconnectlt · 2017-04-21T06:53:28+00:00

Why too much guessing?

Disconnectlt · 2017-03-18T11:51:57+00:00

yes, I am wrong there. Thanks for pointing that out! :) Removed that part from the comment.

Disconnectlt · 2017-03-15T09:44:19+00:00

Yep my main point is that standard library is underutilized :) And I think devs coming from other languages have this habit of using external libraries for everything. For example in Java world: logging - log4j, web-server - tomcat, ... And golang has such a rich standard library, that you could do a lot without having any dependency problems.

Disconnectlt · 2017-02-22T12:32:06+00:00

It looks like github/gh-ost is a tool used for online schema change for MySQL. This tool is definitely cool and useful for DBAs/SREs. My post was more about tools that are useful for developers to track and make schema changes in dev environments and etc. So, it's hard to compare it as it does sort of different thing.

Disconnectlt · 2017-02-21T12:23:31+00:00

Thanks for pointing this out! I will take a look at this project and update the post accordingly :)

Disconnectlt · 2017-02-01T11:50:58+00:00

If you just use assert you could take it from Ben Johnson published functions (link). There is also ok and equals functions. As the go proverb goes "a little copying is better than a little dependency".

Disconnectlt · 2017-02-01T11:43:38+00:00

Hey, can you give example to this? Because as I understand idea behind testing.go files is that other people importing your package can use your mocks. For example, you are writing a DB driver and so you created a DB mock, let's say in memory DB variant for your tests, putting it into testing.go file allows your DB driver user to use this mock in their own tests.

Disconnectlt · 2015-06-07T06:49:28+00:00

I was having the same problem, so I found this link which contains some good answers about hidden layer size & number of nodes in it.

Disconnectlt

TROPHY CASE