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

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

2012年1月17日 / 管理人 / 0件のコメント

新たにサーバを構築しようとなって、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サーバでインデックスが使えないとどうなるか。

2012年1月13日 / 管理人 / 0件のコメント

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

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

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

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

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

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

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

2012年1月13日 / 管理人 / 0件のコメント

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

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

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

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

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

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

2012年1月12日 / 管理人 / 0件のコメント

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との互換性というか、同じようなオプション体系にするために存在しているオプションであることはわかったけれども、オプションがメモリー使用量に反映されるってのは、なんか混乱してしまうような気がしないでもない。

肩こりが痛い。

2012年1月11日 / 管理人 / 0件のコメント

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

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

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

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

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

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

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

2012年1月10日 / 管理人 / 0件のコメント

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

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

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

Phenom II X6って、もう売ってないじゃん

2012年1月8日 / 管理人 / 0件のコメント

ウチのWindows7マシンは、なんとなくAMDのPhenom II X4搭載マシンである。2009年当時、Quad Coreのプロセッサとしては、Phenom II X4が安かったような気がしたから、AMDマシンにしたのだった。

で、それから2年。あ、もう3年か。2012年1月現在、AMDのCPUはFusion系と、FX系のラインナップを揃えているものの、そのラインナップにPhenomの文字は既にない。…といっても、Intelとの熾烈な競争で劣勢に立たされているAMDのことだから、ライフサイクルを伸ばすための小細工をやって、2年ちょっと前のPCでもCPUは最新版のCPUが刺さるとか、なんかやってくれているんじゃないかという淡い期待をしていた。

確かに、AMDは既存のAM3ソケットの後継にAM3+ソケットを用意して、FXシリーズはAM3+ソケットにささるようになっていた。さすが、AMD。わかってるなぁと思って、ウチのPCのマザーボードを確認してみたら、ソケットAM3。あーーー。つまり、FXシリーズは搭載できないってことのようだ。そんなわけで、AMDの現在のラインナップには乗れないことが判明したら、ソケットAM3の範囲内でアップグレードを図るしかない。となると、Phenom II X6というヘクサコアのCPUを調達するしかなさそうなのだが、もう既にPhenom II X6が市場から消えて久しいらしく、アキバのお店でももう売ってない。

いやー、見事に終わった。こうなったら、マザーボードとCPUをまるごと交換するしかないようだ。そうなるならば、再び、Intelに舞い戻るか、という気にもなってくるが、どうせDirectX9あたりのゲームで遊んでいるのに、わざわざSandy BridgeなCPUにまでする必要があるのか、というと確かに遠い目は避けられない。なんかオワタという感覚が次のマシンを志向させるだけの話で、ニーズの微妙感はぬぐえない。

3年前のびみょーなPCを前に、どうしたもんだろうか。

Amazon S3に有効期限機能とか。

2012年1月6日 / 管理人 / 0件のコメント

どうやら、Amazon S3に有効期限機能が搭載されたらしい。

【AWS発表】 Amazon S3の有効期限機能の発表：
http://aws.typepad.com/aws_japan/2012/01/amazon-s3-object-expiration.html

端的には、S3に格納するオブジェクトに「寿命」が設定できるようになったということだろう。使ったら使っただけお支払いのクラウドサービスにおいては、「寿命」を設定できるのは、(オブジェクトがS3にあるだけで課金対象なわけで)なかなか役に立ちそうな機能であるなぁ、と思う一方で、この「寿命」を設定する機能を使って何ができるだろうと考えると、結構、難しいような気がしないでもない。

まず、なんというか、使いすぎ(ひっくり返せば、放置)を防ぐための保険としての「寿命機能」を使うのはアリだろうな、と思う。とはいえ、memcachedのような容量制限のキツいデータストアにおいては、短命な「寿命」でオブジェクトが消えていくことを前提にアプリケーションは作成できるが、もともと容量制限がないS3において、意味のある形で「寿命」が使えるかとなると…うーむ、という感じはする。

ぱっと思いついたのは、なんかのバックアップをS3に取るだけ取って、古いバックアップの削除については「寿命機能」に任せて、工数削減とか、かな。使えそうだけど、大した工数削減にはなりづらいような気がする。

COBOLでメシを食うには

2012年1月6日 / 管理人 / 0件のコメント

うっかりITProにて、すごい記事を見つけた。

「COBOL資産が移行の障壁」は誤解、最新技術と組み合わせればもっと活用できる：
http://itpro.nikkeibp.co.jp/article/Interview/20111228/377698/

まぁ、広告記事なんですけどね。

COBOLはプログラミング言語というよりビジネスロジックを構築するためのシンプルな言語であり、複雑な処理はランタイム側に組み込める。既存の資産を生かしつつメインフレームからオープンプラットフォームに切り替える「モダナイゼーション」（近代化）の面では、ほかの言語よりも有利なのだ。

ビジネスロジックと、アプリケーション実装の分離みたいな話は永遠のテーマではあるんだろうけど、COBOLもビジネスロジックとアプリケーションの実装のねとねとした部分がぐちゃっと一体化しているのが常態化しているのは現状のはずなんだが、それをさらっと「プログラミング言語というよりビジネスロジックを構築するためのシンプルな言語」と言ってのけてしまうのはさすがだ。

やっぱり、膨大なCOBOLのコードの蓄積こそが問題なのであって、それをビジネスロジックと言い切ってしまうと、やっぱりややこしいことになるんじゃないかと思われ。だいたい、もし、COBOLが本当にビジネスロジックの記述に有利であるならば、既存のCOBOLのコードが存在しないような新システムの構築現場でも使われるはずだが、私の知る限り、聞いたことがないし、この手のCOBOLで商売しようとしている人たちが話し始める時の枕詞は「既存のCOBOLのコードを”活かす”ためには…」であって、あくまでCOBOL資産があることが前提である。

WesternDigitalの「WD10EADS」の調子が悪そう。

2012年1月4日 / 管理人 / 0件のコメント

ま、いつものことなのでどうしたってことでもないけれど、古いLinkStationに使っていた、WesternDigital製の「WD10EADS」が認識されなくなった。というか、動作音から察するにどうも上手くスピンアップしなくなったようであった。

まー、2009年に交換したドライブなので2年とちょっとでダメかーということで、素直に諦めてSeagate製のBarracudaを買ってきて、ゴニョゴニョしながらHDDを交換してファームウェアをインストールして、ひととおりLinkStationとして動く状態まで戻してみた。で、壊れたディスクと知りつつもそこから、データをレストアして、新しくなったLinkStationに書き戻すことにした。

USB-SATAアダプタを使って、Ubuntuマシンに接続してみたら、なんてことなくスピンアップ。正常に認識されて、SMB経由でNASにファイルが無事に書き戻された。…なんだ、別に壊れてないじゃん。

なんとなーく最初の故障と思しき症状の背景を考えてみた。まずは、HDD側の不良の可能性。ま、あり得なくはないものの、外に引っ張り出した途端に、普通にスピンアップしてデータを読み出せたのはどうなんだろう。確かに、Western Digitalが省電力を売りにして発売した「Cavier Green」シリーズの最初の方のHDDだから、自動ヘッド退避などでややこしいことをしているらしく、なんとなく故障しやすいHDDだろうというのは想像がつくのだが…。どうもなぁ…。また、LinkStationの方も、どうやら使っている電解コンデンサの寿命が短いらしく、コンデンサのアタマが膨らんじゃっているようなこともあり、そうなるとHDD周辺で何かが起こるらしい。そして、200円分くらいのコンデンサを秋葉原で手にして、ハンダゴテを使ってコンデンサを交換すると治るらしい。

しかし、LinkStationの電解コンデンサの不良があったとすると、新しいHDDに交換してもダメなはず、、、だけど、今のところ、SeagateのBarracudaは普通に動いているようにみえる。。どうもHDDもLinkStationも怪しい気がするが、それぞれを組み合わさないと自体が起きないようである。

とりあえず、LinkStationから引っ張り出したWestern Digitalの「WD10EADS」を少しテストしてみよう。なんかエラーが出てくれれば、RMAでシンガポールあたりに返却して終了にできるんだけども。

ただのにっき。