インデントを変えた時のDiffってめっちゃ見にくいですよね。インデントを変えただけなのか、実は内容も変わっているのかGithub上で判断したい！ そんな時はURLパラメーターに

Go使いたくなる理由の一つに、マルチスレッドプログラミング的なものを高速な言語で安全に実装したいというのがある。Goにおいてそれを支えるのが、自前で実装した軽量スレッドといえるgoルーチンと、mutexなどのロックの代わりに使えるChannelという概念だ。 実際に実装するときに、Goルーチンは難しくないが、Channelを使うのは割と知識と経験が必要なのでここでは、Channelについてすこし詳しく書いてみる。 Message Passing まずは理論から。 Goのチャネルなどのロックを使わない方法の並行処理はMessage Passingと呼ばれている。 以下の英語版Wikipediaにあるように数学的な理論にもなっているしっかりした枠組み。 ErlangのActor Modelなどもこの仲間。GoのチャネルとActor Modelは、実は、同等の概念で表現方法が違うだけらしい。 (

事前情報 m3.xlargeインスタンス 15GB メモリ 13 ECU = 3.25ECU(2.6GHz) * 仮想4コア DBサイズ 3.38 GB 設定値 max_connections = 100 shared_buffers = 3GB # 実メモリの20% # ここらへんのはとりあえずこのくらいで。小さすぎる分にはlog_temp_filesの設定で書き出されるので後で気づいて調整できる。 temp_buffers = 32MB work_mem = 32MB maintenance_work_mem = 128MB wal_buffers = 16MB # 迷いどころもなく16MB checkpoint_segments = 16 # HDへのフラッシュ回数を減らす effective_cache_size = 7GB # planerのため。実メモリの半分ぐらいがいいらしい

今回はEC2インスタンスのOSとしてUbuntuを選択。 CentOS系のAmazon Linuxだとデフォルトで入るバージョンが色々古くてめんどくさいからね。でもapt-getをyumに変えたらだいたい動くんじゃないかと期待。 wal-eとはもともとHerokuがAWS上でpostgresqlのバックアップを取るために開発していたPythonスクリプト。EC2上で走っているPostgreSQLのデータをS3に保存してくれる。 S3にデータ送信すること自体がscpなどを使えず厄介なので、そこを解決してくれているところもあるのだが、単にs3cmd等でバックアップを取るのと違ってデータを圧縮して送ってくれていたり、今あるバックアップ一覧をコマンド一発で見れたりする部分が良いと思う。それ以上には詳しく調べてないけど、HerokuはAWS上でPostgreSQLを動かすノウハウは一番あるのではない