だまれ小僧!お前にサンが救えるか

このエントリーをはてなブックマークに追加
>>951
LinuxのNFSは、書きこみについては、zero copy が
できるようになったけど、読み込みについては、必ず
1回コピーが生じるよ。
ネットワークから読み込んだパケットにはヘッダが
Ethernetヘッダ、IPヘッダ、UDP/TCP ヘッダ、それに
SunRPC のヘッダと多段についていて、これらをはぎと
らないとNFS経由でOracleに渡すことはできない。
ここでどうしても1回コピーが生じることになる。
(書き込み時は DMA descriptor でメモリをかき集める
ことができるので問題ない)

だから、その記事は、書き込みの zero copy のことを
言ってるだけだよ。
読み込みで限界性能を得ようと思うと、メモリコピーが
避けられないから、NASでは、DASやFC-SANにかなわない
はず。
> LinuxのNFSは、書きこみについては、zero copy が
> できるようになったけど、読み込みについては、必ず
> 1回コピーが生じるよ。

おっとっと、実はここ誤解していた。すまん。
Linux の NFS で zero copy ができるようになったのは、
NFS サーバー機能に関してだけみたいだな。
NFS サーバーが、ネットワークに書き込むとき (すなわち
NFS クライアントが、NFS read オペレーションを発行した
場合) に zero copy になっただけか。
(ネットワークからの読み込みで zero copy ができないの
は上に書いた通り)

今回の場合、NFS のサーバの役割をするのは NetApp で
あって Dell は NFS クライアントに過ぎないので、結局
読み書きともに必ず 1回以上はメモリコピーをしている
ことになるんだろう。これでは DAS や FC-SAN にはかなわんよ。
> Linux の NFS で zero copy ができるようになったのは、
> NFS サーバー機能に関してだけみたいだな。

さらに訂正。Linux 2.5.70 の時点で、NFS クライアント
側についても zero copy が入ったようだ。(ただし、もちろん
送信処理のみ)
結局、953 は不要で、952 そのままで正しかったようだ。
あと、>>951の記事は、zero copy のことを言ってるんじゃ
なくて、O_DIRECT で page cache をバイパスする話をして
るのかもしれんな。Oracle がキャッシュしているデータを
さらに page cache に持つのは無駄だからな。
その場合、write だけじゃなくて read の性能にも関係する
が、どちらにせよ >>952 の理由から、DASやFC-SANにかなう
まい。
956名無しさん@お腹いっぱい。:05/03/16 11:45:15
限界性能を気にするシステムってどれほどあるのかな?
むしろ、バックアップや増設を考えると、NASでRACを
構築するほうがメリットがでかいと思うのだが。。

EMCで構築を考えていたが、NetAppも検討してみるか。。
957名無しさん@お腹いっぱい。:05/03/16 11:46:10
>>943
とりあえず Sunに止めを刺す
DASやFC-SANなら、高負荷時にもI/O要求や応答が失われる
心配はないけど、NASだと負荷がかかると(NAS側は大丈夫
でも)NFSクライアント側がパケットを落す危険があるから、
性能だけじゃなくて、高負荷時の安定性にも難があるんじゃ
ない?
それにDBの場合、SANでもバックアップや増設の手間は
たいして変わらん気がするが。
>>943
SPARC
スレ住民の仕事内容が垣間見える流れでした
>>943
見てみぬ降りをして、Javaと駆け落ちします。
NetAppの工作員が紛れこんでるような希ガス
963名無しさん@お腹いっぱい。:05/03/16 19:05:06
964名無しさん@お腹いっぱい。:05/03/16 19:16:40
>>963
ブログでまで、SunグリッドとIBMグリッドの比較やってる
さすが社長さん、必死だな
965名無しさん@お腹いっぱい。:05/03/16 19:52:26
このスレがDat堕ちする可能性なのど考えてもみなかったよ。
Sun Grid
一瞬、オオと思うが、よく考えてみると数百ドルで数GHzのPCが手に入る今
そんなややこしい事するかね。
数GHz以上のパワーが欲しけりゃBeowulfする方がイイ。

OpenSource Solaris
コミュニティのない今、オプソしても何のメリットもない。
CobaltやSuSE(x86 Linux)を受け入れられなかったツケが今きてる。

Honeycomb
ストレージ2大勢力の切り崩しは無理。
CPUもおぼつかないのにいらん事に金使うな。
Beowulfのような特定組織内のクラスタを安全にInternet全体に
広げたものがGridの筈だが?
従量制のグリッドコンピューティングサービスに対してと意味で受け取ってクレ。
Sun、Javaのライセンス条件を緩和へ
http://www.itmedia.co.jp/enterprise/articles/0503/16/news026.html
>>952
クロック1GHz程度のsparcならメモリコピー性能は1Gbyte/s程度はでる。
なのに、100Mbyte/sのTCPの転送をすると1GHzのCPUを使い切ってしまうのは
何故か?よく考えてみよう。メモリコピーはボトルネックではない。TCP/IP
のプロトコル処理そのものがボトルネック。
うそだとおもうのなら、TCPの転送をしながらlockstat -kIW -D 20で
カーネルのプロファイリングを調べてみるのがよい。
最近はNICで処理してますけどね─
結局NASだと、TCPとかそういう余分なものを経由するので
イクナイと。で、あの構成提案したのはダレ? Dell?
Linuxを例にしてNFS時のcopyを議論していたけど、
SANでもLinuxで動かすのかい?
アプリケーションからIP層をスルーしてethernetのようなデータリンク層で
直接やりとりするようになると早くなるの?ど素人な質問ですみません。
Direct Access Storage (IDEとかSCSIとか)もFibreChannelも、
カーネルから見るとEthernetじゃなくて、ブロックデバイスに
見えるの。だから、そもそもネットワーク処理のためのオーバー
ヘッドは全然かからないし、プロトコルヘッダの処理も要らな
いから、メモリの中身を直接ディスクとの間でDMAできるの。

Ethernetのようなネットワークデバイスの場合、ヘッダをつけ
足したり、取り除いたり、解釈したり、チェックサムを計算し
たりなどなど、やることがずっと多い。

まあ最近はTCPぐらいなら、ハードウェアがやってくれる場合も
多いけど(TCP Segment Offloading)、NFSを使おうと思うと、
SunRPCとかNFSとか、さらに上位層のヘッダがあるので、結局
効率ではDASやFCにかなわない。
ネットワーク経由ストレージ接続したところで、
本当に性能が気になるならばそれ専用セグメント作りたくなるのが
世の常人の常と思うので・・・

結局、設備投資的にはFCカード増設するのと何ら変わらなくなるんでわ?

※なんちゃって環境だったら変わるだろうけれども
977名無しさん@お腹いっぱい。:05/03/17 10:43:05
最近のCPUで、TCP overhead を気にする必要があるのか?
昔のSunマシンならともかく。。。
そんなのサーバがしょぼいっていっているようなもんじゃないのか?
おまけにNASで専用セグメントつくっても、圧倒的に
SANよりやすいじゃねーか!
FC SWなんて高すぎ。おまけにSANでヘテロな環境構築できねーよ。
現実的に。一社でチンいつするならべつだが。
ヘテロなSANでまともにサポートできるとこあんのか?
どうなんだろ。俺的にはNASは、もうちょっとお手軽に
使うイメージがあるけど。既存ネットワーク上、たくさん
のマシンから共用して使うみたいな。
こういう使い方をするとNAS:クライアント=1:Nでの利用
になるから、NAS側の性能は確かに必要なんだけどね。
> 最近のCPUで、TCP overhead を気にする必要があるのか?

間違いなくあるよ。
Xeon 2.8GHz だと、たかだか1本の Gigabit Etherでも、バンド幅
一杯流してると、CPU能力の3割はプロトコル処理にもっていかれる。
3.4GHzのCPUで、たとえクロック通りに性能が上がったとしても、
CPU能力の25%はプロトコル処理だけで消費されてしまう計算になる。

こんなの誰でも簡単に評価できる話だと思うけど、試してないの?
NASは、かなり強力なCPUをnetwork interface上に持っているよ。つまり必要。
いまやPCIに指す普通のNICでもTCP位は処理するし。
>>978
10年近く前はそうだったけど、
今は性能のことを考えても完全に選択肢に入ってきている。
>>981
NAS 1台で複数のNFSクライアントにサービスして、
クライアント1台あたりの性能はそこそこでいいなら
大丈夫だけど、NAS:NFSクライアント=1:1で限界性能
出そうと思うと、>>979が出した値ではかなり厳しい
んじゃない?

U320 SCSI 1本と同じバンド幅を出そうとするだけで、
Gigabit Ether 3本トランクする必要があって、その
プロトコル処理だけで CPU 使用率が75%〜90% に
いっちゃうよ。
これで、DBも動かして性能出そうってのは無理では?

まあ、自分ではちゃんと性能評価できないお客さん
なら気づかないかもしれないけどさあ。
983名無しさん@お腹いっぱい。:05/03/17 11:19:04
SANとNASでCPUを消費するポイントがことなるだけじゃないの。
というよりDASやFC-SANが、NASよりもCPUを消費しない
(プロトコル処理がないから)ってことでしょ。
> SANとNASでCPUを消費するポイントがことなるだけじゃないの。
×CPU
〇金
http://www.itmedia.co.jp/survey/articles/0503/16/news061.html
外資と国産との差が顕著に表れた2004年の国内サーバ市場

1000近くになると盛り上がるのはどのスレでもしょーがないんでしょうかね
>>986
> 1000近くになると盛り上がるのはどのスレでもしょーがないんでしょうかね

そう思う人の心理の問題だと思う。
988名無しさん@お腹いっぱい。:05/03/17 15:13:27
んじゃあもらうよ1000
989名無しさん@お腹いっぱい。:05/03/17 15:13:53
990名無しさん@お腹いっぱい。:05/03/17 15:14:51
>>1000ゲット
991名無しさん@お腹いっぱい。:05/03/17 15:15:11
>>1000ゲット
米IBM、米Novellと商業協定を締結し全サーバーにSUSE LINUX搭載へ
http://enterprise.watch.impress.co.jp/cda/foreign/2004/03/25/1777.html

1000にむけ燃料投下
993名無しさん@お腹いっぱい。:05/03/17 15:16:09
>>1000ゲット
994名無しさん@お腹いっぱい。:05/03/17 15:16:30
>>1000ゲット
995名無しさん@お腹いっぱい。:05/03/17 15:17:59
>>1000ゲット
996名無しさん@お腹いっぱい。:05/03/17 15:18:23
>>1000ゲット
997名無しさん@お腹いっぱい。:05/03/17 16:53:10
NFSv4 に期待!
Solaris10 頑張れ!
unix 厨ならnasだろーがっ!
998名無しさん@お腹いっぱい。:05/03/17 17:27:42
1000なら、Linux滅びる
999名無しさん@お腹いっぱい。:05/03/17 17:28:02
1000ゲッチュです
1000名無しさん@お腹いっぱい。:05/03/17 17:28:24
1000なら、Windows滅亡する
10011001
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。