[Linux][Java]UFJ銀行グループLinux導入の舞台裏

http://itpro.nikkeibp.co.jp/members/ITPro/oss/20040927/150430/
昔から言ってるけど、Web,AP,DBすべて１つブレード内に収めると、FWを外だしするのも大変で、ネットワークのゾーン設計が出来なくなるって欠点があった。
それを解決するには、各ゾーンごとにブレードを用意するしかない。って思ってたけど、この記事にある図を見るとあまりＦＷなどの考えは導入してないみたいだなぁ。

一応、以下の内容は参考になるのでメモ

Oracleでは，信頼性と拡張性を確保するためRAWデバイスを使用するケースがほとんどですが，RAWデバイスが255個までしか使用できず，足りない。Oracleによれば，Oracleが提供するOracle Cluster File System（OCFS）を使うことで解決できるとのことでした。しかし，実際に検証してみると，Readの処理がOCFSではRAWデバイスの1.5倍から2倍かかる。結局，Readの処理が多いデータベースだけRAWデバイスを使用することで回避しました。

Linuxのバグもありました。負荷が高くなるとkswapdと呼ばれるカーネル・プロセスが暴走し，Linuxがハングする現象です。米国を視察した際にも，kswapdは障害が起きやすいので注意したほうがいいとアドバイスを受けていたのですが，こちらでもテストフェーズで多発しました。アドバイスを受けていたパッチを適用することで発生しづらくはなったのですが，更に根絶するためにカーネルパラメータ設定変更を何回も試して最適値を見つけました。この問題の解決までに1カ月以上かかりました。

これ、言われて見れば何度か経験してた。学生時代だったし、自分で作ったプログラムだったし、トンでもなくメモリ食うのわかってたから気にしなかったけど、そうだったのか・・・

ライブラリのバグにより，Java VMがハングアップするという問題もありました。Java VMが使用するメモリーのサイズを変えてみたり，BEA製のJava VMに代えてSun製，IBM製のJava VMを使用してみたりしましたが解決しない。スレッド・ダンプをBEAに送付して解析したもらったところ，Linuxの標準ライブラリであるglibcのバグではないかという回答で，glibcを最新版に入れ替えたところ解決しました。

現在のLinuxが32ビットCPU上で動く32ビットOSであるための苦労もありました。WebLogicでは1インスタンスで利用できるメモリーは2.1Gバイトで，2.1Gバイトを超えるとOut of Memory Exceptionが発生し，ダンプを出力してダウンします。Oracle接続用のドライバが800Mバイト程度をバッファとして使用するため，実際には1.25Mバイト程度しか使用できるメモリーがない。さらにWebLogicがメモリー・リークを起こすこともあり，アプリケーション側でメモリーを使いすぎないように対策を施す必要がありました。

Linux自体の問題ではないのですが，Oracleの問題もありました。Oracleの代理店と原因を調査したのですが，解明に2カ月かかりました。原因は大容量の物理メモリーを使用したことでした。Oracleのシステム・グローバル領域と呼ばれるメモリー領域の最大サイズは，標準で1.7Gバイトなのですが，拡張機能を使って2.7Gまで広げたのですが，そうすると同じユーザーが複数のアクセスを同時に行うとメモリー競合が発生し，セグメンテーション・フォルトが起きるという障害でした。同じユーザーでアクセスしないよう，アカウントを分けることで対処しました。