Subscribed unsubscribe Subscribe Subscribe

ふり返る暇なんて無いね

日々のメモ書きをつらつらと

2013-01-23日誌

tmuxの設定

ちょこちょこ使い始めた。
随時更新する。

percona 5.5 on lenny がクラッシュした件

dmesgに怪しいログが。

[74056446.244014] INFO: task kjournald:617 blocked for more than 120 seconds.
[74056446.244050] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[74056446.244102] kjournald     D 0000000000000000     0   617      2 0x00000000
[74056446.244105]  ffffffff8143d1f0 0000000000000046 0000000000000000 ffffffff8116d598
[74056446.244108]  ffff8801c2251930 ffff88022bd788d0 000000000000f8a0 ffff88022c4a5fd8
[74056446.244111]  00000000000155c0 00000000000155c0 ffff88022bc5b170 ffff88022bc5b468
[74056446.244114] Call Trace:
[74056446.244120]  [<ffffffff8116d598>] ? elv_merged_request+0x30/0x39
[74056446.244124]  [<ffffffff81175826>] ? generic_make_request+0x299/0x2f9
[74056446.244127]  [<ffffffff8110afb3>] ? sync_buffer+0x0/0x40
[74056446.244130]  [<ffffffff812e412e>] ? io_schedule+0x73/0xb7
[74056446.244132]  [<ffffffff8110afee>] ? sync_buffer+0x3b/0x40
[74056446.244135]  [<ffffffff812e462e>] ? __wait_on_bit+0x41/0x70
[74056446.244137]  [<ffffffff8110afb3>] ? sync_buffer+0x0/0x40
[74056446.244139]  [<ffffffff812e46c8>] ? out_of_line_wait_on_bit+0x6b/0x77
[74056446.244142]  [<ffffffff81064a9c>] ? wake_bit_function+0x0/0x23
[74056446.244150]  [<ffffffffa011e1d1>] ? journal_commit_transaction+0x508/0xe2b [jbd]
[74056446.244153]  [<ffffffff8105a45a>] ? lock_timer_base+0x26/0x4b
[74056446.244156]  [<ffffffffa01213fb>] ? kjournald+0xdf/0x226 [jbd]
[74056446.244159]  [<ffffffff81064a6e>] ? autoremove_wake_function+0x0/0x2e
[74056446.244162]  [<ffffffffa012131c>] ? kjournald+0x0/0x226 [jbd]
[74056446.244164]  [<ffffffff810647a1>] ? kthread+0x79/0x81
[74056446.244167]  [<ffffffff81011b6a>] ? child_rip+0xa/0x20
[74056446.244169]  [<ffffffff81064728>] ? kthread+0x0/0x81
[74056446.244171]  [<ffffffff81011b60>] ? child_rip+0x0/0x20
[74056446.244181] INFO: task mysqld:19561 blocked for more than 120 seconds.
[74056446.244214] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[74056446.244265] mysqld        D ffff8801c23d7ea0     0 19561  30146 0x00000000
[74056446.244268]  ffffffff8143d1f0 0000000000000086 0000000000000000 000000010000000e
[74056446.244270]  ffff8800b9754b30 ffff8801c23d7e18 000000000000f8a0 ffff8801c23d7fd8
[74056446.244273]  00000000000155c0 00000000000155c0 ffff88022cfcdbd0 ffff88022cfcdec8
[74056446.244275] Call Trace:
[74056446.244278]  [<ffffffff810b3657>] ? wait_on_page_writeback_range+0xce/0x11b
[74056446.244282]  [<ffffffffa0120f4c>] ? log_wait_commit+0xbf/0x112 [jbd]
[74056446.244284]  [<ffffffff81064a6e>] ? autoremove_wake_function+0x0/0x2e
[74056446.244289]  [<ffffffffa01313f8>] ? ext3_sync_file+0x94/0xc8 [ext3]
[74056446.244292]  [<ffffffff81108b10>] ? vfs_fsync_range+0x73/0x9e
[74056446.244294]  [<ffffffff81108bba>] ? do_fsync+0x28/0x39
[74056446.244296]  [<ffffffff81108be9>] ? sys_fsync+0xb/0x10
[74056446.244299]  [<ffffffff81010b02>] ? system_call_fastpath+0x16/0x1b

/proc/sys/kernel/hung_task_timeout_secs とは

設定値はこんな感じだった。

# cat /proc/sys/kernel/hung_task_timeout_secs
120

ブロックデバイスへのアクセスのタイムアウト時間と言うことか?

khungtaskd こやつが使う値。

永遠にブロックされた(何に?)タスクをhung taskとして検知するkernel threadがkhungtaskdらしい。

ただ、時間的にクラッシュした後にデータがメモリに載っていない状態で、急激にIOに負荷がかかった影響で、ログられたっぽいので、クラッシュの原因とは関わりなさげ。

manのセクション

SEE: man -LC man

  • 1. shell command
  • 2. system call
  • 3. library call
  • 4. special files /dev とかの
  • 5. file format
  • 6. game ..? いるの?
  • 7. Miscellaneous ..? 雑多なもの? マクロのパッケージとか
  • 8. admin command
  • 9. kernel routines(非標準)

tmuxの色味

vimの色味がなんかおかしいので、変えてみる。

set-option -g default-terminal xterm-256color

gumistudyのメモ

* ソーシャルゲームのデータ不整合と戦う
幾田さん

Erlangが使えるから入ったのに
OperationSupportの人
RabbitMQ導入

モチベーション
     トレードで増殖するアイテム
     殴ってもHPの減らない零度ボス
     ガチャしても手に入らない
          =>データ不整合

データは資産
不整合は許されない


入社したらMySQLとRedisの園

Oracleをkumofsに変えたりとか前職でしてた
信用を得てからいろいろやろうと思った

CAP
     一貫性を確保し可用性を諦める

Agenda
     MySQL
     Redis
     RabbitMQ

水平垂直分割はしている人はあまりいない
XAトランザクションを使用している人はいない


XAトランザクション
     MysQLを複数台使用
     HASHで分割
     普通ならデータ不整合が起きる

MySQLは2層コミットのみ対応
Transactionの分離レベルはSerializableが安全
     だけど、Deadlockが多発する

djangoはXA Transactionに対応していない

コミットレベルを変更して、
最後のREPEATABLE READに直す

デッドロックが発生したら再実行すること
     MySQLのドキュメントには書かれている

でも、再実行していない


** Redis

Transactionを使用している人は会場にいない

MULTIでキューイング
EXECで不分割に実行
WATCHでCASを実現 楽観ロック
パイプラインで使用すると効率が良い

redis.py pythonで一番使われている


副作用を関数の外に漏れ出さないようにしている

RedisにXAはない
     参加させる方法yがあるかもしれない

MySQLをPrepareした後にExecをする


** RabbitMQ
メッセージングでTransactionを
http://www.rabbitmq.com/
AMQP 0-9-1の実装

dtx AMQP 0-10から使える

** まとめ

真実1
disconnectするとPREPARED な

コミットフェーズの障碍に対応できない

2005年からしてきされているが、Patchあてに失敗

Transactionマネージャーで監視して、手動で不整合を解決するしか無い


真実2

Execを送ってもRedisに届かない場合
レスポンスが届かない場合

commit すべきかRollbackすべきか不明

MySQLのロック待ちにRedisに引っ張られる

Redisの楽観ロックを行かせない
     Redisを使う意味が無い。。。

無駄な努力しない
     RedisとMySQLを

一貫性が保てない場合はユーザが得する順番で処理を行う
     レイドボスのHPを減らしてから行動力を減らすとか

真実3

kombuはtx未対応

トランザクションをサポートしているがゆえにRabbitMQの開発が遅れいている

そもそもTransactionは必要なのか
     PublisherConfirms

MySQLと整合性を保つならdtx

XAを意識した送信

MySQL DisconnectでPreparedなコネクションがきえるr

Redis XAトランザクションがdけいない

Ra XAを意識して使用する

完璧なXA Transactionは無理。今回の構成では

戦い続ける


ユーザデータを保存する新しい仕組みの検証
Wooga


* オペレーションエンジニアとしてのクラウドとの付き合い方
石川さん

データセンター => いろいろ => 2010~ gumi
ウェブオペレーションをやっている

AWS
RDS
DynamoDB
SQ.
S3などなど

2009年終わり頃からAWSを使い始めた

経緯
2009年8月PC向けmixiアプリリリース
物理サーバ2台でこなしてた

2009年10月携帯向けmixiアプリ
数分でダウン

CTOが
     知人に勧められてた
     使いたいものがそろっていた
     RDS
     5日で移行

ソーシャルアプリのトラフィックがすごく
サーバを購入する時間と場所が無かった


** 1人でやっていた話

2010年4月入社
CTOから業務巻き取り

CTOは2012年3月にAWSに。。


CTOは作業ログを取っていた
     それを元に作業してた

帰省中も対応
ELBがご機嫌な斜め
東京から離れると障碍が起きる説

東京リージョンに移行

トラックナンバー1
死ねない
500台くらいを1人で見ていた 


** 障碍のはなし

日常的にEC2

大きなモノ
     2011 ELB RDS
     2012 RDS

*** EC2
     突然調子悪くなる
     ネットワーク疎通
     rebootできない
     物理ホスト障碍
     多数同時起動時に数台立ち上がらなかったり


作り直せるようにしておく
3ヶ月以上稼働していれば大丈夫。たぶん
ダメな子もいると考える


*** ELB
2011/8/24
     8:00-23:00


pre-warming
     ELBがスケールする際にレスポンスが変化するのでそれを怒らないようにする

ELB作り直し、DNS変更

このとき元CTO
     セールスの方に連絡

*** RDS

2011/9/4
     止まりました

一度フェールオーバーしてそのあとmysqlが延々と再起動

稼働しているインスタンスは復旧できないかも
     障碍発生8分前のデータRDSを作成(PITR)
     コマンド一つで作り直し

8時間のアプリ停止の計算


2012年はおおむね平和

2012/4/26   昼頃
RDSが名前解決できない

14時過ぎに復旧連絡

** 再起動祭り
***2011冬

全台再起動

EC2
スケジュールされたreboot or 手動で再起動

RDS
メンテナンスウィンドウでrebootを待つ


***2012秋

RDSだけ再起動

再起動はちゃんとできたか?
     おおむねできた
     READレプリカがはずれたこともあった

** ベータ版

RDSはベータ版 ずっとベータ
SLAが無い
日本のクラウドでも用意していないところもある


** 意外に読んでいない公式ドキュメント

使用前のウォームアップ EBS全領域の読み込むことをオススメしています
公式ドキュメントを当たっておくのが無難

PIOPS EBSそんなに速くない疑惑
RDSのパフォーマンス疑惑
     Mult-AZで性能劣化するような


** AWSあるある

使い始めた当時そのサービス無かった
カジュアルに使いすぎる
     コスト。。。

RDS上に書こうとしちゃう
     SELECT… INTO OUTFILE

AWSに人が吸い込まれている
     CTO
     botoの中の人

** これまでの利用から得られたこと
普通にサーバを使ってきたひとなら楽になるはず
さほど使えない人でも容易に使える
     ハンズオン多い

見えない、手を加えられない。ハードウェアで解決できない

中の人となかよくなっておくといい
どこまでクラウドにするか、クラウドにしないか

**この先生き残るには

コードを書けるインフラエンジニアが重要なんじゃないか
そもそも基礎
     ハッカーになろう
          http://cruel.org/freeware/hacker.html
     情報技術者の定義
          http://heikou-konton.blogspot.jp/2001/03/blog-post.html


せっかくクラスタリング組んだのに物理サーバは同じだった
     防ぐ方法は?
          質問すると、物理サーバが同じかどうか答えてくれる
          電話対応はサポートに入らないとダメ。高い

puppet使っているケド
     全部でも無い
     1人の時は使えた
     ツールを覚えるのはコストがかかるので、現在は使えていない

監視
     Amazon CloudWatch
          http://aws.amazon.com/jp/cloudwatch/
     nagios
          http://www.nagios.org/
     gangliaも使っている
          http://ganglia.sourceforge.net/
          gangliaに設定するとnagiosに監視をする仕組み