ブログお引越しのお知らせ
こちらのブログからお引越しさせていただくことになりました。
新
www.nakapachi.jp
こちらにはもう更新はしませんが新しい方にて更新をさせていただきますのでよろしくお願いします。
新
www.nakapachi.jp
こちらにはもう更新はしませんが新しい方にて更新をさせていただきますのでよろしくお願いします。
z196+RHEL6.1
z196+RHEL6.1の稼働検証を行いました。
微妙にインストーラーが変わってますが、RHEL6.0とほぼ同じでした。
よくDVDないんですか?って聞かれますが、あるわけがない。
今回は、vncで外からつないでKDEを使ってみました。
SLESだとこの辺は自動的に入りますが、RHELは自分で・・。
yumでインストールします。
yum install Packge名で個々のパッケージは入れられますが、yum grouplistで表示された、groupをgroup毎に入れられるのは知らなかった・・。
この辺は、z/Linuxといえど、Redhat系。ググるとすぐ出てきます。
SLESがあまりにオートマティックなのでRHELのほうが触っててLinuxだなーと思います。
これをやりながら、z/OS上のIMS V11の稼働検証を・・・。
z/Linuxでviをいじりながら、シェルを書きながら、IMSの生成をやって、FF/FPのトランザクションとBMPバッチのテストを並行でやるという・・。ある意味ハイブリッドを自でいってます。
個人的にはz/LinuxのWASからIMSのDEDBをいじくるというテストをしてみたい。
もちろん、DL/IのPGMを書き、Javaもコーディングし、な感じで。
ハイブリットってのはかなりニッチかもしれませんね。
微妙にインストーラーが変わってますが、RHEL6.0とほぼ同じでした。
よくDVDないんですか?って聞かれますが、あるわけがない。
今回は、vncで外からつないでKDEを使ってみました。
SLESだとこの辺は自動的に入りますが、RHELは自分で・・。
yumでインストールします。
yum install Packge名で個々のパッケージは入れられますが、yum grouplistで表示された、groupをgroup毎に入れられるのは知らなかった・・。
この辺は、z/Linuxといえど、Redhat系。ググるとすぐ出てきます。
SLESがあまりにオートマティックなのでRHELのほうが触っててLinuxだなーと思います。
これをやりながら、z/OS上のIMS V11の稼働検証を・・・。
z/Linuxでviをいじりながら、シェルを書きながら、IMSの生成をやって、FF/FPのトランザクションとBMPバッチのテストを並行でやるという・・。ある意味ハイブリッドを自でいってます。
個人的にはz/LinuxのWASからIMSのDEDBをいじくるというテストをしてみたい。
もちろん、DL/IのPGMを書き、Javaもコーディングし、な感じで。
ハイブリットってのはかなりニッチかもしれませんね。
z/Linuxの良いとこ
これがよくわからなかった。
一応最新のメインフレームとIAマシンで円周率の計算、約1億桁という処理をやらせてみた。
結果はかけないが、IAの圧勝で終わってしまった。最近はIBMメインフレームでもクロック数というキーワードを出してきたので結構期待したのだが・・・。
確かにかなりのCPUインテンシブな処理である。IAのほうが非常に有利だと思う。
まぁLinuxという他のアーキテクチャと比較できる土俵があるので比較してみたくなる今日この頃。
実は8年位前にもjavaのJDBCを経由して、z/OS上にあるDB2に対してSQLでInsertしまくるというベンチマークをやったことがある。
この時もIAのサーバーとメインフレーム上のLinuxをそれぞれクライアントにして、比較した。
それそれCPUは1個で実験した。この時も1スレッドであればパフォーマンスでIAの圧勝となってしまう。
ただこの多重度を上げていくと、この時のvmstatを見ると相当なコンテキストスイッチが発生しているが、IAはスレッド毎のInsert件数が安定しない。z/Linuxはスレッドが増えても安定して処理をこなしている。
この理由は、IBM System zの特性が出ている。
コンテキストスイッチが非常に早いということ。コンテキストスイッチのオーバーヘッドがほぼないので安定しているといえると思う。
1スレッドの性能が遅いからと言ってサーバー統合できるわけないだろうと思ったのだが、こういう特性であればサーバーを統合して筐体でフルに性能を使っても安定しているということになる。
これを実現しているのは2つ。z特有のアクセスレジスターの存在とIO専用プロセッサーの存在。
今はIAサーバーでもかなり速いスピードが出てしまうので、単純にパフォーマンスを比較しても無意味かと。
統合しても安定した特性が出せるというのが、z/Linuxの特徴だと思います。
確かに基幹系で安定してスケールアップな統合をするならz/Linux、スケールアウトで行くならIAというところでしょうか?
どちらに優越はないと思います。
というのが最近の結論。
ただ、H/Wが壊れにくいとか安定してますとかだけだと知らない人からすると良くわからない。
アンチメインフレームな人からすると何がいいのかさっぱり理解できないと思う。
メインフレームって世代ごとで考え方が違うようで、50代は俺たちが作ったぜ、40代だとあの昔のものねと、20代になると見たこともないし、知らないしーと思うようです。
コンピューターも適材適所というとこですね。
一応最新のメインフレームとIAマシンで円周率の計算、約1億桁という処理をやらせてみた。
結果はかけないが、IAの圧勝で終わってしまった。最近はIBMメインフレームでもクロック数というキーワードを出してきたので結構期待したのだが・・・。
確かにかなりのCPUインテンシブな処理である。IAのほうが非常に有利だと思う。
まぁLinuxという他のアーキテクチャと比較できる土俵があるので比較してみたくなる今日この頃。
実は8年位前にもjavaのJDBCを経由して、z/OS上にあるDB2に対してSQLでInsertしまくるというベンチマークをやったことがある。
この時もIAのサーバーとメインフレーム上のLinuxをそれぞれクライアントにして、比較した。
それそれCPUは1個で実験した。この時も1スレッドであればパフォーマンスでIAの圧勝となってしまう。
ただこの多重度を上げていくと、この時のvmstatを見ると相当なコンテキストスイッチが発生しているが、IAはスレッド毎のInsert件数が安定しない。z/Linuxはスレッドが増えても安定して処理をこなしている。
この理由は、IBM System zの特性が出ている。
コンテキストスイッチが非常に早いということ。コンテキストスイッチのオーバーヘッドがほぼないので安定しているといえると思う。
1スレッドの性能が遅いからと言ってサーバー統合できるわけないだろうと思ったのだが、こういう特性であればサーバーを統合して筐体でフルに性能を使っても安定しているということになる。
これを実現しているのは2つ。z特有のアクセスレジスターの存在とIO専用プロセッサーの存在。
今はIAサーバーでもかなり速いスピードが出てしまうので、単純にパフォーマンスを比較しても無意味かと。
統合しても安定した特性が出せるというのが、z/Linuxの特徴だと思います。
確かに基幹系で安定してスケールアップな統合をするならz/Linux、スケールアウトで行くならIAというところでしょうか?
どちらに優越はないと思います。
というのが最近の結論。
ただ、H/Wが壊れにくいとか安定してますとかだけだと知らない人からすると良くわからない。
アンチメインフレームな人からすると何がいいのかさっぱり理解できないと思う。
メインフレームって世代ごとで考え方が違うようで、50代は俺たちが作ったぜ、40代だとあの昔のものねと、20代になると見たこともないし、知らないしーと思うようです。
コンピューターも適材適所というとこですね。
