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(非標準)
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に監視をする仕組み