ただのにっき。

ただつらつらと日記が書かれていくようです。

24ページ目 (40ページ中)

badblocksにてHDDの検査中。

ddを使ってドライブの隅から隅まで読み書きのテストをしていたHDDのSmartの「Current Pending Sector Count」に2が記録されていた。んで、dmesgにはこんな感じでエラーが記録されていた。

sd 5:0:0:0: [sdb] Unhandled sense code
sd 5:0:0:0: [sdb] Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
sd 5:0:0:0: [sdb] Sense Key : Hardware Error [current]
sd 5:0:0:0: [sdb] Add. Sense: No additional sense information
sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 03 ff 8b 00 00 00 f0 00
end_request: I/O error, dev sdb, sector 67078912
__ratelimit: 20 callbacks suppressed
Buffer I/O error on device sdb, logical block 8384864
Buffer I/O error on device sdb, logical block 8384865
Buffer I/O error on device sdb, logical block 8384866
Buffer I/O error on device sdb, logical block 8384867
Buffer I/O error on device sdb, logical block 8384868
Buffer I/O error on device sdb, logical block 8384869
Buffer I/O error on device sdb, logical block 8384870
Buffer I/O error on device sdb, logical block 8384871
Buffer I/O error on device sdb, logical block 8384872
Buffer I/O error on device sdb, logical block 8384873

うーむ、Buffer I/O error。なんか嫌な予感がするので、badblocksに切り替えて(今思えば、最初からbadblokcsを使っておけばよかったな)破壊検査を実施。これは時間がかかりそうだ。

久しぶりにAWSのManagementConsoleを開いたら、Dynamoが使えるようになったっぽい。

昨日、AWSのEBSのバックアップを取得するべくManagementConsoleにアクセスしたときには気づかなかったが、タブの右端に「DynamoDB」ってタブが増えていた。

AWSのDynamoというと…確か、Amazon製のKVSって印象だけど…ちょっと調べてみたら、Amazonの買い物カゴ機能の裏側でDynamoががんばっているらしいのだが、そんなKVSをAWSユーザーに解放するってことか。ぼんやりとどんな使い方ができるか考えてみよう。

SuicaポイントクラブのポイントでSuicaチャージバック。

JR東日本は、モバイルSuicaや記名式のSuicaなどを対象に「Suicaポイントクラブ」なるものを運営している。

ま、端的に言えば、ポイントクラブに登録してあるSuicaを使って、駅ナカなど乗車券以外の使い方でSuicaのStored Fare=SFを使うと、利用金額に応じてビミョーにポイントバックされる仕組みで、さらに、そのポイントはWAONやYahoo!ポイントなどに移転することもできるし、Suicaにチャージすることもできるという仕組みである。

…と、そんなわけで、久しぶりに何ポイント貯まっているか確認してみたところ、250ポイント。なかなかビミョーな量である。何を勘違いしたのか、Suicaポイントクラブの1ポイント=Suica10円分くらいでチャージされるのかと勝手に期待していたら、Suicaポイントクラブの1ポイント=Suica1円分。つまり、私のキャッシュバックは250円であった。勝手に期待したのは私だが、なんとなく残念な感じだ。250ん円分でもないよりはマシの精神で、素直にモバイルSuicaにチャージさせていただいた。

定期などは記名式のSuicaだと思うので、モバイルSuicaや定期券でSuicaをお使いの方は、Suicaポイントクラブに入って、アカウントとSuicaを結びつけておくと、意外とキャッシュバックされるかもしれない(特に、駅ナカを頻繁に使っている自覚のある人は)

HP製SmartArrayのRAID Arrayの監視とか。

古くからのHP Proliantユーザーにはアタリマエのことかもしれないが、新参者のProliantユーザーにはよくわかんないことが割とある。例えば、SmartArrayカードで組んだRAID Arrayの監視だ。

RAIDの管理コマンドを使えば、RAIDの設定などが割と簡単にできることはわかったけれども、どうも監視についてはどうもピンと来ていないたぶん、ドキュメントは存在している感じだが、まとまった形でドキュメントが用意されていないような気がするのが原因ではないか(*1)。どうやら、IMAなるものをインストールすれば、ハードウェアの監視を一括で引き受けてくれるっぽい。で、何か起こったら、rootへのメールと、/var/log/messageへの書き込みを行なってくれるらしい実際にメッセージを書きだすのはIMAの構成モジュールのASRらしいが(*2)。

ただ、なんとなくここまで大掛かりに監視したくないような気もする。監視用のエージェントがメモリとかCPUとか食わないだろうかといった心配もあるし、単にRAIDがコケてないことを確認したい場合の選択肢がないか、と探してみたら、SourceForgeにccissドライバと共に公開されている「cciss_vol_status」ってアプリケーションを使って、RAID Arrayのステータスを取得して、そのメッセージをどうにかすれば監視ができそうだ。

例えば、「cciss_vol_status」を実行しつつ、メッセージを取得して、取得した結果がおかしなことになっていたらアラートを上げるみたいなシェルスクリプトをcronで定期実行するのもありかなぁという気もする。

で、試しに「cciss_vol_status」をビルドして実行してみようとしたら、「/dev/cciss/c*d0」なんてデバイスが存在しないのだった(汗)Scientific Linux6を使っている関係で、ccissドライバではなく、hpsaドライバが使われているせいだろうけれど。。。で、ドキュメントを読んでみたら、hpsaドライバを使っている場合は、scsi genericデバイスが割当てられるらしく、「cciss_vol_status /dev/sg0」とかやると、RAID Arrayのステータスが返ってきた。ま、あとはシェルスクリプトを書くだけ、と。

*1:たぶん、ドキュメントは存在している感じだが、まとまった形でドキュメントが用意されていないような気がするのが原因ではないか、と

*2:実際にメッセージを書きだすのはIMAの構成モジュールのASRらしいが

HDDのエージングってどうしたものか。

新たにサーバを構築しようとなって、HDDを調達してみたものの…これ、どうやってエージングするのが正しいのだろうか、と考えると、結構面倒くさいことになりそうな気がしてきた。

例えば、ddでディスクの隅から隅までをゼロフィルしたとして、その間に書き込めないセクタが見つかればエラーを検出してくれそうな気がする。一方で、読み込みの方は、例えば、ifに検査対象の/dev/sdXを指定することで、/dev/sdXから読み込んで、/dev/nullに書きこんであげれば(…といっても電子空間の狭間に消えて行くわけですが)、また、HDDからの読み込み中にddが読み込めないセクタに直面したら、きっとエラーが検出されるだろう(てか、検出して欲しい)

一応、テストにはなりそうな気がしてくるものの、1回、隅から隅まで読み書きしただけでOKとするのも心許ないような気がするので、読み書きを何回かくりかえすことになりそうだ。しかも、この手のテストは、隅から隅までHDDを舐め回すので、1本のHDDを処理するのにさすがに時間がかかりそうだ。しかも、RAID1+Hotspareなサーバが2台だから、テストすべきHDDは6本。orzあとは、1台のPCに複数台のHDDを接続して、同時並行でテストするしかないかと…。

MySQLサーバでインデックスが使えないとどうなるか。

ちょっとした理由でMySQLの大きめなテーブルにてインデックスが使えない状態となった。さて、そんな時、MySQLサーバのCPU使用率などはどんな傾向を示すのだろうか。…いや、わかりきっているんですけども

…というどっちでもいいことをGangliaのグラフから拾ってみた。一応、インデックスの復旧を頑張っていたので、使えていた状態から使えなくなる部分の差異は拾えなかったので、インデックスが効かない状態だったから、インデックスが有効になって使える状態に遷移した時のGangliaのグラフを。

まず、CPU使用率のグラフから。とある時点から、グラフの面積が明らかに小さくなっていると思うが、そこで、indexが復活している。

f:id:y_fudi:20120113173935j:image

indexが効いていない間は、MySQLがCPUを使っているので、CPUのUserがぐーんと使われることになり、インデックスが効けば、きゅーんと下がる。

f:id:y_fudi:20120113173936j:image

んで、当然のことながら、load averageはCPUの使用率に追随してくれる感じなので…。

f:id:y_fudi:20120113173937j:image

15分のload averageは思ったよりもわかりやすく見えるなぁ…。これまた、わかりきったことではありますが、RDBMSにおかれましては、インデックスの存在は極めて重要だな、というわかりきったことが改めてわかった次第でございます。

大きなファイルを一定の行数で分割して複数のファイルに分ける。

手元に、MySQL向けのSQLの束があって、それを実行したいんだけど、一気に実行するとどーんとサーバに負荷がかかってしまうので、負荷を見ながら、こそこそと細かく実行していきたいなぁと。でも、1つのファイルのまま、MySQLのクライアントに渡してしまうと、もちろん一気に実行されてしまうので、例えば、SQLの束のファイルを分割することにより、複数回に分けて、MySQLクライアントに渡せばやろうとしていることが実現できそうってことで。

大きなファイルを分割するには、Linuxに搭載されていた「split」コマンドを使った。例えば、以下のような感じ。

split -l (分割したい行数) (分割したいファイル名) (prefix)

何個のファイルに分割されるかは、ファイルの行数次第なので確定はしないけれど、「(prefix)aa」から

始まって「(prefix)ab」…といった感じで連番のファイルに分割してもらえる。で、MySQLクライアントに「(prefix)aa」から実行していけばよさげ。

gzipとbzip2の「–fast」とか「–best」とか。

MySQLからmysqldumpで引っ張り出した巨大なSQLファイルがある。そのサイズはざっと100GBくらい。そのデータをそのままストレージに転がしておくのは非効率なので、当然圧縮する。

そこで、圧縮プログラムの選択となるのだが、何も考えずにgzipで圧縮していたら、圧縮後のファイルサイズはだいたい元のファイルの50%くらい。それでも、まだファイルサイズが大きいので、次にbzip2を試してみた。確かに、圧縮率は向上していて、元のファイルの40%くらいまで圧縮することができた。しかし、圧縮にかかる処理時間は3倍くらいに大幅に伸びてしまった。

確か、gzipには「–fast」とか「–best」とかのオプションがあり、圧縮率と処理速度をトレードオフに、ある程度、調整できそうだったのでbzip2も調べてみたところ、gzipと同じような「–fast」とか「–best」とかのオプションがあることがわかった。

で、「man bzip2」でオプションについて調べてみたところ、以下のような記述が…。

圧縮の場合、ブロックサイズを100 k, 200 k .. 900 kに設定する。 伸長の場合、何も影響を及ぼさない。以下の「メモリ管理」セクションを参照すること。 –fast と –best エイリアスは、主として GNU gzipとの互換性のためにある。特に –fast オプションで目に見えて速くなる訳ではない。また –best は単にデフォルトの動作を選択するだけである。

加えて、その周辺も読んでみた感じ、要は、bzip2の場合、「–best」は「-9」と同値で、これがデフォルト値。「–fast」は「-1」と同値であるが、この「-9」から「-1」のオプションは、bzip2が圧縮処理を行う時のメモリー使用量に反映されるオプションであって、圧縮の処理速度を(圧縮率を犠牲にして)向上させるようなものではないらしい。

…bzip2の「–best」とか「–fast」がgzipとの互換性というか、同じようなオプション体系にするために存在しているオプションであることはわかったけれども、オプションがメモリー使用量に反映されるってのは、なんか混乱してしまうような気がしないでもない。

肩こりが痛い。

なんかITとは全く関係ないが、近ごろ(…というか昨日、今日)、肩こりがひどい。肩こったなぁから一歩進んでなんか痛いな…って感じ。

そんなときは、パスタイム(サロンパスっぽいものたが、サロンパスのあの臭いがないので、こっちを愛用)を肩やクビのあたりに貼りまくる。

ちょっと風邪っぽい悪寒がするので、葛根湯も飲んだ。さらに、この前のウォーキングで、足も疲れてそうなので、パスタイムをさらに土踏まずに追加。

…もう寝るだけなのだが、眠気がやってこないと言う悲惨な深夜。こうこったら、を無理矢理にでも寝るか(汗)

追記:
…ここまで書いて、昨夜は寝落ち。朝になって風邪っぽい感じはなくなった。首や肩も快方に向かっているものの、完全に治ったってかんじでもないな。

追記 その2:
久々にAndroidのWordpressクライアントを使ったら、なぜだかパスワード保護がかかってたという…orz

改めてdlvr.itを使ってみるテスト。

RSSからFacebookやTwitterにぶん投げるツールって、日本語でわっかりやすいのがあるのかなぁーと思ってたら、意外と見つからず。

英語でもOKということであれば、インターフェイスとかわかりやすいので「dlvr.it」あたりがよろしいのではないか、と思っております。ま、FacebookとTwitterでワンストップでいけるっぽいし(…この前、使ってたときもFacebook向けのインターフェイスあったかなぁ、という記憶の怪しさですが…)

そんなわけで、結局、この前も使って見ていた「dlvr.it」を改めて使って見ることにしたので、その連携テストをやってみる、と。はてさて、このエントリーはTwitterやFacebookに滞りなく投稿されるのでしょうかぁぁぁ。

«過去の 投稿 新しい 投稿 »