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

カテゴリー: ITめいたこと (21ページ目 (31ページ中))

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

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

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

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

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

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

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

ウチの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に有効期限機能とか。

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

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

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

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

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

COBOLでメシを食うには

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

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

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

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

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

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

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

ま、いつものことなのでどうしたってことでもないけれど、古い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でシンガポールあたりに返却して終了にできるんだけども。

2012年のITギョーカイはどうなるか。

いつものごとく、ネットを徘徊していたらワシントン・ポストの記者が書いた記事「Five tech industry predictions for 2012」を見つけました。

この記事が挙げている5つ予想を引用すると、以下のような感じでしょうか(雑な訳でアレですが…)

  1. Social media will lose its sizzle.
  2. -ソーシャルメディアの利用が停滞していくだろう。

  3. The bubble will pop for the current crop of tech IPOs.
  4. -tech系のIPOバブルがはじけるだろう。

  5. An explosion of the tablet market driven by sub-$100 tablets.
  6. -$100以下のタブレット製品によって、タブレット市場が旧成長するだろう。

  7. Voice recognition goes mainstream.
  8. -音声認識が主流になっていくだろう。

  9. “Cloudburst” shakes the tech industry.
  10. -“Cloudburst”がITギョーカイを震撼させるだろう

えーと、”Cloudburst”ってのは、クラウドを使ったサービスの利用が加速することって感じの意味で使われているっぽいと。まー、ざっと見た感じではあんまりアグレッシブな予想ではなく、どっちかというとそんなに大外ししない代わりに、斬新さに欠けるような予想のような気がします。

果たして、日本ではどうなるんだろうなぁと考えてみることにしましょうか。

ソーシャルメディアの利用が停滞するというのはそんなに違和感はないんですが、より細かく見てみると、多種多様なソーシャルメディアがローンチされる割には使われないといった見え方になりそうな気がします。確かに、FacebookやTwitterなどの先行者がつかんだユーザーたちのソーシャルメディア疲れは懸念されるものの、人々がソーシャルメディアに費やす時間が大きく減るかというとそうではないような気がします。スマートフォンの普及によって、ソーシャルメディアへの距離感が近くなった(コストが下がった)というのが1つ。それとは逆に、スマートフォンを使って何かしたいという欲求が発生しているなかで、ゲームやソーシャルメディアなど、スマートフォンでできることのバリエーションは実はそんなに大きくないことから、結果的にソーシャルメディアに接触しているといった使い方もあるんじゃないかということがもう1つ。また、(人によるかもしれませんが)TwitterやFacebookがこれまでのメディアでは流通しづらかったような情報(友達のリアルタイムな近況など)を流通させていることから、明確なメリットを感じている人が少なくないのではないか、ということもあるのではないでしょうか。

Tech系IPOのバブルというのは、LinkedInとか、ZyngaのIPOのことを指しているわけですが、特に、いずれもIPO直後の価格が思惑とは裏腹に下降を続けていることを指しているようです。ま、なんとなくGrouponからの流れがあったような気もしますし、FacebookがIPOするとかしないとかって話がありますが、FacebookでもLinkedInやZyngaと同じことが起こるのか、ということも少し疑問です。個別銘柄の事例から傾向を推し量るのは少し難しいのではないかという印象です。

もとい。日本でもIPOの流れは少しありそう(現にKLabのIPOとか)ですが、例えば、ウノウがZyngaに買収されたような、大きく成長したTech系の事業会社によるStartupの買収が増えてきそうな気がします。例えば、SalesForceも国内の事業会社への投資を増やしていそうですし、同じような流れが他の企業(例えば、楽天とか)起きないとも限らない。そういう意味では、IPOバブルになる前に、さまざまなExitでStartUpが買収されていくのではないかという気がします。むしろ、有望なStartupを事業会社、VCなどで奪い合うような、そんな状況が起こる、とか。

次にタブレットマーケットですが、DoCoMoショップなどの端末の売れ行きを見ていると、まだスマートフォンが中心で、Androidタブレットなどは叩き売られているのが現状のようです。逆に言えば、Androidタブレット端末はキャリアとバンドルされた形の販売形式がメインで、WiFiのiPadのような販売形式が見られないのが現状、と。確かに、Asusなどのタブレットの一部は、量販店に並んでいるものの、やはり売れている印象はありません。

ネタ元の記事の$100以下のタブレットというのは、おそらくは中国や台湾のメーカーがAndroidを搭載した安いタブレットを投入してくることを指している(インド製の$35タブレットは現実味を帯びているようですが)のでしょう。むしろ、$100あたりのタブレットは、これまでも投入されてはいたのですが、静電パネルではなく、感圧式のパネルだったり、バッテリーの持ちがひどかったり…と、実際の利用にあたってはかなり厳しい品質で、まともに使えないものだったのが、少しは洗練されてくるということでしょう。確かに、MITメディアラボの創設者のニコラス・ネグロポンテ氏が教育用の$100以下のPC(OLPC)をなんとかつくろうとされていたことを思い出せば、(1)そこそこのスペックで(2)大量に生産することでコストを下げて(3)利用にあたって安価な、もしくは無料なソフトウェアを搭載した端末は成立しうるのではないかという気がします。教育用の他に、家庭での利用シーンを作れるか、そのシーンに応じたソフトウェアを無料に近い価格で用意できるかが$100以下タブレットのキモなのかもしれません。

そして、音声認識。日本語では厳しいのではないかというか、既にGoogleが音声検索用のアプリを無料で提供していますが、まともに使っている人たちを見かけないことから、2012年も日本では音声検索については厳しいのではないかという印象を持っています。スマートフォンにおいても日本語の入力はかなりの問題を抱えているのは確かですが、だからといって音声にぱたっと倒れるほど、問題はシンプルではないように思います。

最後に、クラウドの利用ですが、正直なところ、ITギョーカイの悪習といってもいいのですが、「クラウド」なるものをしっかり定義することなく、既存のものから新しいものまで、ごった煮にしたあげく、なんでも「クラウド」とラベルを貼ってしまうでしょう。例えば、これまでASPサービスって売っていたものを、「SaaS」と言い換えたところで、特段大きな違和感があるかというとそんなこともない。そうなってくると、否が応でも「クラウド」の利用は進むことになるでしょう。「SaaS」くらいになるともうクラウドで動いているかどうかはあんまり関係ない世界なんだろうと思いますが、いわゆる「IaaS」のあたりのクラウドサービスは、これまでの経験の差がモロに反映されてきそうな気がします。新興「IaaS」がいろんなトラブルを経験する一方で、AWSのような老舗サービスは(既に通った道なので)似たようなトラブルには見舞われない、といったような形で差別化が進むような気がします。新興「IaaS」などは価格で差別化するしかなく、規模が小さい「IaaS」ベンダーなどは価格によっては耐えきれなくなったり刷るのかもしれません。また、同時に、新興「IaaS」ベンダーなどはAWSのような老舗サービスをリファレンスモデルにして「似たようなサービス」を作ることによって、スイッチングコストを下げるような戦略も成立しそうな気がします。

…雑に書きなぐったエントリーですが、一応、以上です(汗)

SmartArrayで使ってたHDDの再利用。

どうでもいいメモ。

RAIDコントローラーの下で管理していたHDDは、そのどこかにRAIDの管理情報が書かれているので、RAIDコントローラーの配下から外して、そのままHDDを再利用しようとすると何かと怒られることが多い。

試しに、HPのRAIDカード、SmartArray P212の下にぶら下がってたHDDを、そのまま、別のサーバのSmartArray P212で構成サれているRAID Arrayのホットスペアにしようとすると、下記のように怒られた。

Error: Drive 1:3 can not be added to the array as a spare. This drive is not an
       existing spare, is not an unassigned drive or is in a state that is
       preventing the operation from completing. Use the "show" command to
       check the status of the drive you are attempting to use.

ddとか使ってデータを飛ばすのも面倒だったので、試しに、このドライブを1物理ドライブ=1論理ドライブにしてみた(SmartArray的には、物理ドライブ1個のRAID0って扱いだったかと)。で、そのあと、論理ドライブをぶっ壊して、そのまま、ホットスペアに指定してみると、今度は怒られずに設定することができた。

前のサーバのRAID Arrayの構成情報が記録されているHDDも、ホットスペアに指定するとエラーが上がって、論理ドライブにするとエラーが出てこないということと、論理ドライブからホットスペアに変更するのもノーエラーってことらしい。…ま、そういうことだという理解をするしかないか。

ふたたびAPCの試用を開始してみるなど。

PHPの中間コードキャッシュ用のモジュールと言えば、いくつかあるが、ま、とりあえずAPCでも使ってみるかということで、ビルドしてapc.soを作って入れてみている。

そして、/etc/php.d/の下にapc.iniを作って、apc.soを読み込ませているつもりだったが、恐るべきことに「extension」と書いたつもりが「extention」とかなっていて、apc.soが読み込まれず。orzこういうスペルミスではまると、なかなか見つからないのが辛いところで、もう少しでAPCをビルドし直すところだった。

とりいそぎ、動き始めたAPCではあるが、いまのところ、割り当てるメモリ不足が不足してなさそうではあるけれど、この辺を監視してチューニングしたいと思っているけど…これまたなかなか面倒くさい(汗)

« Older posts Newer posts »