ウチの監視システムの変遷について書く | Ore no homepage
今、リアルタイムでは休暇中でフランクフルト経由ベルリン行きの飛行機の中にいる。暇すぎる。うちの会社、ってかトレタの監視系の変遷について書く。でも絵を描く気力はないので文字のみ。 今の状況です ルフトハンザは日本線は軽食の時間に ONIGIRI が出てくるので結構好きな航空会社です。休暇中なのにラップトップ持ってくのはプロ社畜の証。まあ今会社で裏側見てるのが俺しかいないので、エエ…。しかし世の中ホント便利に便利になってる。空の上でもインターネットができる。言い方を変えると空の上でもアラートが届くっていう…。飛行機の中は暇すぎるけどさすがに仕事はしたくないね。というかこの旅行中は仕事を忘れたい。 2014/10以前 俺が入社する前。 コア機能：Engineyard(OS: gentoo)。 プロセス異常監視、閾値監視など：monit エラートラッキング、レスポンスタイム、SQL：NewReli
MySQL InnoDBの圧縮に関する雑感 | Ore no homepage
7月は一回も記事書かなかった。3年くらい前からInnoDBの圧縮をしてみたり止めてみたりって行為を度々しているので、所感についてまとめとく。 2011年頃(MySQL5.1) 容量削減目的で圧縮を試す。 環境 CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz(仮想8コア)×1 memory: 24GB storage: ioDrive Duo(2面合わせて600GBくらい。SW RAID0で組む。) OS: CentOS 5.4(kernel: 2.6.18-164.el5) filesystem: xfs(noatime, nobarrier) MySQL: 5.1 innodb plugin Query: ピーク時に更新系が5kqpsくらいだったかなあ…忘れた。 圧縮した結果 容量は半分に削減できた。 パフォーマンスはあまり変わらなかった。 CPU
serverspec インフラ層のテスト項目を考える | Ore no homepage
最近は担当システムが平和だけど俺が平和じゃない。疲れてる。忘年会の連チャンもきっついトシになっちまった。会社の制度で1週間くらい休みがとれるので、一人で温泉とスノボと開発合宿でもしに北海道にでも行こうかなって思ってる。1月か2月くらいに。 えーと、担当しているサービスにserverspecを導入した。それにあたってテスト項目を考えたので軽くまとめる。もちろんserverspec導入前もサーバ構築後は動作確認というか、テストらしいことはしていたっちゃしていたんだけど、テスト項目をまともに考えたのはこれが初めてかもしれない。serverspecのバージョンは0.13.2である。Rubyは2.0.0。 0. 環境 下記のような環境に導入した。ありふれた構成だと思う。60台くらいの規模。DBはマスタ3台に分割されていて、それぞれにスレーブがn台ぶらさがっている。LBの箱は二つあるが、物理的には1台
MySQL ibdata1が肥大化する理由(記事の意訳) | Ore no homepage
毎日暑い…。というか蒸し暑い。何年か前にベトナムとカンボジアをバックパッカー旅行したときを思い出す。日本の気候が亜熱帯ってか東南アジアっぽくなってきたような…昔はこんな頻繁にゲラリ豪雨とか降らなかったよねー？温暖化ってやつ？日本の植生とか変わるんじゃねーのかな…。 えーと、おれがよく見ている技術ブログの一つにPercona社のMySQL Performance Blogがある。そのブログに先日、「Why is the ibdata1 file continuously growing in MySQL?」という記事が投稿された。内容はInnoDBのibdata1の肥大化とその解消方法に関するもの。ibdata1の肥大化を解消する手段は、ダンプをとってDBを作り直してあげないと治らないということは多くのInnoDBユーザが知っていることだと思うけど、おれもInnoDBを触り始めたころは、「気
Riak 05 システムプランニング | Ore no homepage
ハードウェア層 OS層 クラスタの留意点 負荷分散 ベンチマーク BitcaskとLevelDB コンフィグファイル スケールアウトとスケールアップの手順 運用上の注意点 64ビットCPUアーキテクチャ 最低4GBのメモリ。メモリは最も重要。局所性を活かせるのであれば多くメモリを必要としない。 RAID0、SSDを考慮すると良い。IOバウンドになりがちなので。 ミラーリング(RAID1)は考えなくて良い。 RAID(RAID1？)はやめちゃいな(クラスタ組んでるしいいんじゃない？的な？)。 ディスクサイズ重要。 ギガビットイーサも考慮にいれて。ネットワークも使うよ。 仮想マシンを使う場合は一番良いインスタンスを使う。同じデータセンタ/リージョンに配置するようにする。 クラスタ全体で必要なディスクサイズは次のように計算できる。 オブジェクト数 * 平均オブジェクトサイズ * n_val 50
Riak 04 クラスタへのアクセスと一貫性レベル | Ore no homepage
あ、どうも。ストレスが溜まって癒しを欲する今日この頃。ところでおれのPC、「いやし」を変換すると「嫌死」になるんだけど…。 3台構成のRiakクラスタを組んで一貫性レベルに応じた可用性の実験したという記事。一貫性レベル(Consistency level)についてなんだけど、Riakに限らずMongoDB(笑)やCassandra(墓)などの分散DBは同様の概念をもっている。これについてはある程度は馴染んでいるハズなんだけど、Riakは読み込みについてだけでもr(Read Quorum)に加えて、pr(Primary Read Quorum)など、ちょっと見慣れない(おれの知らない)パラメータがある。書き込みについてはw(write quorum), dw(durable write quorum), pw(primary write)と、実に3つのパラメータを使って一貫性を調整するようだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
