Linuxのメモリダンプ解析の話 (その1) - Qiita
背景 社内で Linux マシンのとあるドライバの挙動がおかしいということで「ライブ crash で見たいなぁ」って呟いたら、「クラッシュって何？壊すの？」という反応が出て自分としてはカルチャーショックを受けたので、メモリダンプ解析の話を書いてみようと思いました。 色々と検索してみたところ、kdumpでメモリダンプ (世の中的にはクラッシュダンプと言う方が多い？) を採取する設定・手順についてはたくさんあるんですが、実際にその解析をどうやるのかって記事はあんまりないなぁと。パッと見つかったレベルだとこんな感じ。英文記事も探せば出てくるのだろうか。 VA Linuxの「ダンプ解析講座」の記事は結構ちゃんと書いてる。 O'Reillyの本 Debug Hacks -デバッグを極めるテクニック&ツール は結構ページ使って説明してる (役に立つかどうかは読み手次第)。 ミラクル・リナックスのLin
Linuxのメモリダンプ解析の話 (その2) - Qiita
Linuxのメモリダンプ解析の話 (その1) の続きです。 メモリダンプ解析の話に結構食いつきがあったので、引き続き書いてみたいと思います。カーネルの中身を理解するのは何故か敷居が高いと思われがちなのですが、全然そんなこと無いってことを分かっていただけると嬉しく思いますし、「ここが分かりにくい」みたいな話があれば教えていただけると有難いです。僕もまだまだカーネルの中身を知ってる段階ではなく、その都度調べてる状況なので。 個人的には Web 界隈の様々なミドルウェア・ツールが乱立してて理解が追いつきません。 それでは早速やりましょう。今回も Ubuntu 上での操作となります。 crashの操作 crash> log log コマンドはカーネル内のバッファに蓄積されたカーネルログを出力します。ログの中身は、一般的なシェル上から使うことのできる dmesg コマンドで出力されるものと同じはずで
Java 8u92から増えた -XX:+CrashOnOutOfMemoryErrorと-XX:+ExitOnOutOfMemoryErrorを試してみた - 水まんじゅう2
※91だと思ってたら増えたのは92からでした。 試したのはWindowsで。OOM発生時にJVMを確実に落とすオプションらしい。 -XX:+CrashOnOutOfMemoryError >java -XX:+CrashOnOutOfMemoryError Main Aborting due to java.lang.OutOfMemoryError: Java heap space # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (debug.cpp:308), pid=6760, tid=0x00000000000026a4 # fatal error: OutOfMemory encountered: Java heap space # # JRE vers
ブロックデバイスのクラッシュ模擬ツールcrashblk の紹介 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、サイボウズ・ラボの星野です。 先日の記事(半年かかったバグ調査の顛末は)では、長期間苦労した不具合調査についてあっさりとまとめて頂いたので、その行間に起きたたくさんのことを思い起こし、ひとり感慨にふけっています。 (私も記事原稿をレビューしましたが、もし私が書いたら思い入れが強すぎて長文になってしまい、きっと読みづらくなってしまったでしょう。。) さて、今回は、crashblk というソフトウェアをオープンソース化したので、その紹介をしたいと思います。 ソースコードは GitHub レポジトリ に置いてあります。 ライセンスは GPLv2 or 3 です。 crashblk とは crashblk (くらっしゅぶろく、と読んでいます) は、Linux カーネルのブロックデバイスドライバやファイルシステムなどをテストするためのブロックデバイスドライバです。私は WalB を開発し
まだMySQL 5.5で消耗してるの？MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法
MySQL 5.6が登場してからかなりの月日が過ぎたが、他のことで多忙だったせいか、MySQL 5.6についてはあまりブログで情報を発信していないことに気がついた。これはイカン！！と思い、MySQL Casual Advent Calendar 2014に合わせて、MySQL 5.6を使用する上で最もオススメしたい機能であるクラッシュセーフなレプリケーションについて解説しようと思う。この記事は16日目の記事である。 レプリケーションがクラッシュセーフとはどういうことかクラッシュセーフとは、何らかの事情により、プロセスがダウンしたりマシンが電源ごと落ちたり（つまりクラッシュ）しても、再起動後に以前の状態に戻って処理を再開できるということだ。データのクラッシュリカバリであればみなさん既によくご存知であろう。（REDOやUNDOするアレのことだ。本稿では面倒臭い・・・ではなかった、本題ではないた
Testing Lucene's index durability after crash or power loss
One of Lucene's useful transactional features is index durability which ensures that, once you successfully call IndexWriter.commit, even if the OS or JVM crashes or power is lost, or you kill -KILL your JVM process, after rebooting, the index will be intact (not corrupt) and will reflect the last successful commit before the crash. Of course, this only works if your hardware is healthy and your I
筑波大学でデータベースの話をしてきました - kuenishi's blog
筑波大学の川島先生に呼ばれて木、金と情報システム特別講義Dというやつに参加してきた。こんなことになるとは思っていなかったが、あろうことか講師側で呼ばれてしまい、思えば遠くへ来たものだと感慨深い。フリは「RiakとNoSQLの話をしてもらえたら」という非常に自由度の高い内容なので、せっかくなので僕の知っていることを全部詰め込んで話してやろうと思ったら10分延長してさらにスライド10枚分くらいを消化不良で終了という、みっともない感じになってしまった。かなり端折ってポイントだけ説明したので流れが分からず苦労した方も多いと思うが、まあ僕の性格なので許してほしい。データベースの講義をひと通り終えた院生レベルを想定してスライドを作ったので、もしかすると、わりと難しかったり分かりにくかったりするかもしれないので、わからないことがあったら適当に質問してください。 言いたかったことの流れを僕なりにまとめると
Faster Websites: Crash Course on Web Performance - igvita.com
Clearly, three hours of web performance content is not enough. I gave an updated version of the below workshop at Fluent 2013, the videos for which are now online on YouTube - check it out! Delivering a fast and optimized user experience in the browser requires careful thinking across many layers of the stack - TCP and up. In a rather ambitious undertaking, when I got the chance to run a three hou
CRaSH a shell to extend the Java Platform
______ .~ ~. |`````````, .'. ..'''' | | | |'''|''''' .''```. .'' |_________| | | `. .' `. ..' | | `.______.' | `. .' `. ....'' | | 1.0
もしもデータベースサーバがクラッシュしたら
人の作ったものは完璧ではない。完璧でないものはクラッシュする。故にデータベースはクラッシュする。サーバハードウェアの故障、OSのクラッシュ、データベースそのもののバグなど原因は様々であるが、永遠に停止することなく動き続けるRDBMSというものは存在しない。もちろん数年間無停止で問題が出ない場合もあるが、クラッシュするときはするので対策が必要である。もしもの時に備えて抜かりないのがスマートなオトコのスタイルである。データベースのご利用は計画的に。 と思ったそこのアナタ！！人生そんなに楽ではありません。 もちろんRDBMSはトランザクションのDurabilityを保証しているので99%の場合はそれでOKだけど、それはCOMMITが成功した場合の話。COMMITは大抵の場合高速な処理であるが、それでも処理にかかる時間はゼロではない。アプリケーションがデータベースサーバにCOMMITを送信してから
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
