golangのGCとかgoroutineの状況を確認するライブラリ - okzkメモ
golangで作った長時間動かすアプリで「goroutineリークやメモリリークがないか知りたい」とか「GCの影響がどの程度か知りたい」とかないですか？ありますよね？ そのためのログをダラダラ出力するためのライブラリを公開しました。 # 元々はクローズドなトコで作ったモノを、公開のため完全フルスクラッチで書きなおしてます。 github.com 使い方はmainのアタマとかに適当に組み込むだけです。 func main() { // 1分ごとにログにjson出力 t := stats.SchedulePeriodically(time.Minute, func(s *stats.Stats) { log.Println(s) }) defer t.Stop() // あと本来の処理を…… } # 標準ロガーがアレなら、お好みのロガー使ってください。 String()で生成されるjsonはそ
docker swarmのオーバーレイネットワークの安定性について - okzkメモ
半年くらい前にこんな記事を書いたのですが、まあうまく行きませんでした。 okzk.hatenablog.com 頂いたブコメも試してみたんですけど、結果は芳しくなく。。。 Re: Dockerに載せたサービスをホットデプロイする - okzkメモ --stop-grace-periodの設定とDockerfileのHEARTBEATとSTOPSIGNALの設定をすれば出来るはず2016/08/17 06:19 b.hatena.ne.jp そんな中、元記事のヒトも試してみたようですけど、同じ結果に。。。 h3poteto.hatenablog.com そんな中、CVE-2016-9962も出ちゃったし、docker 1.13もリリースされたコトだし、ということでdocker 1.13でswarmモードをもう一回試してみました。 インストール後、swarm初期化 # docker swarm
workerパターンをcontext化してみたら…… - okzkメモ
はい、というわけで、前記事のworkerパターンをcontextつかったらどーなるか、についてです。 前の記事や、その元記事のソースを読んでいる前提ですので、未読の方はそちらの確認からお願いします。 さて、ざっくりとした変更の方針ですけど、以下の2点です。 contextを使うことで、workerの実装側でキャンセルできるようにする workerに渡す値はcontext経由にする。 というのをヤッツケでやってつくってみました。 以下変更点の解説です。 まず、元実装ではworkerで実行される処理がベタ書きだったのを汎用化するため、dispatcherのqueueに入れるjobをとqueueの定義を変更します。 type ( job struct { proc func(context.Context) ctx context.Context } Dispatcher struct { qu
Re: golang の channel を使って Dispatcher-Worker を作り goroutine 爆発させないようにする - okzkメモ
こちらを読みました。 blog.kaneshin.co channel自体にdispatch機構があるからもっとシンプルに書けるのでは？と思って書き直したのがこちら。 コードだけぶん投げてもアレなので、あとで解説書きます。 ついでに「go1.7で標準化されたcontext使ったらどうなるか」も気力次第で書くかもしれません。 というわけで追記というか、本編というか、解説です。 channel整理 元のコードを読んでいくと、 dispatcherのqueueにjobを突っ込む dispatcherがidle状態のworkerをpoolから取り出す 同じ行で取り出したworkerのqueueにjobを渡す workerがjobを受け取って処理する。 というカンジの処理の流れになってるんですが、dispatch機構自体がchannelにはあるので、 dispatcherのqueueにjobを突っ込
golangで書いたアプリケーションをどう動かすか？ - okzkメモ
まとまりなく、何パターンか列挙します。 アプリケーションコンテナで動かす 通常ステートレスなアプリに限られると思いますけど、dockerで動かすというやり方です。 # 個人的にはdocker 1.12で組み込まれたswarmモードがすごくお手軽でよいと最近思ってます。 バイナリはstatic linkでビルドして、alpineで動かすと軽量でイイカンジです。 Dockerfileは以下みたいなカンジ FROM alpine RUN apk add --no-cache ca-certificates COPY your_app /usr/local/bin/ CMD ["your_app"] 外部サービスにssl/tls接続するのに必要なのでca-certificatesを突っ込んでます。 証明書周りを自分でなんとかするんなら、busyboxにするのもアリかと。 supervisordで動
Re: Dockerに載せたサービスをホットデプロイする - okzkメモ
こちらを拝見したところ、やりたいコトはdocker1.12のswarmモードで解決するんじゃないかなー、と思ってみたので試してみたテスト。 h3poteto.hatenablog.com とりあえず、最新版のdocker(1.12)をインストールです。 手元の環境はCentOS7なので、インストールガイドに従ってゴニョゴニョと。 んでもって、swarm初期化。 # docker swarm init 今回1台だけなので、ノード追加は行いません。 次に実験用にnginxのサービスを立ち上げます。 ポイントはimage差し替え時に「停止→起動」の順番で動くので、あらかじめレプリカ数を2にしておいて、ちゃんとローリングで切り替わるようdelayを設定することです。 # docker service create --update-delay 20s -p 80:80 --name test --
golangで書いたアプリケーションのstatic link化 - okzkメモ
「goで書いたアプリケーションは実行ファイルひとつコピーするだけでいいのでインスコ超ラクチン」なんて思ってたんですが、 go1.4からnetパッケージを使っているアプリケーションは、フツーにビルドするとdynamic linkになるようになってました。 $ cd /path/to/your_app $ go build $ file your_app your_app: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped そんなわけで別環境にバイナリコピーしても動かないケースが発生して超絶アタマを悩ませることになるのですが、 そんなときは以下のようにbuildすればstatic linkになってくれるようです。 $ go build
golangのチャンネルでセマフォ的なナニカ - okzkメモ
mattnさんのエントリに触発されて、某所で使用したちょっと変わったgolangのチャンネルの使い方をご紹介します。 mattn.kaoriya.net 特定の処理の並列度をある程度までに抑えたい、みたいなコトありますよね？ 例えばCPUヘビーな処理の並列数をたかだかコア数くらいまでに抑えたい、とか。 そんなときはバッファ付きチャンネルを用意しておいて、当該処理の前後でそのチャンネルにwrite/readをすることで、セマフォ的な制御ができます。 以下のようなカンジです。 package main import ( "fmt" "sync" "time" ) var ch chan int = make(chan int, 4) // 並列度を4に制限 func heavyFunc(i int) { ch <- 1 // チャンネルのバッファがイッパイになっていたら、ブロックする defe
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
