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

**名無しさん＠お腹いっぱい。** · NG

まあね、JAVAとかいろいろあったし
サーバーも最近はIBMに押され気味だし・・・

**名無しさん＠お腹いっぱい。** · 05/03/13 18:30:54

2chで営業するSun日本法人社員がいるスレはここですか？

**名無しさん＠お腹いっぱい。** · 05/03/13 19:04:09

Sun KK
【酸欠】⇒「アムロの親父」の項を見よ。

**名無しさん＠お腹いっぱい。** · 05/03/13 20:07:14

http://www.fetica.com/unix.swf

**名無しさん＠お腹いっぱい。** · 05/03/13 20:07:41

アムロの親父に失礼だ(#ﾟДﾟ)ｺﾞﾙｧ!!
最後は…だったがガンダムを送り出した偉大な人だぞ。
KKは最初から最後をむかえるまで腐りっぱなしだぞ。

**名無しさん＠お腹いっぱい。** · 05/03/13 20:27:49

ナイヤガラ量産の暁には！！

**名無しさん＠お腹いっぱい。** · 05/03/13 20:37:32

＞＞910
Pirusには期待してる。virtualizationをミドルレンジで搭載してるのはSunだけだよ。
しかもPirusの下に他社のストレージを入れ込めれば、ストレージ全体をシンプルにできる。これは凄いことだ。

**名無しさん＠お腹いっぱい。** · 05/03/13 21:01:13

>>907
SGIのストレージ買うよりはマシだろが

**名無しさん＠お腹いっぱい。** · 05/03/13 21:02:00

>>906
なんか時代錯誤なユーザがいますね(ﾌﾟｹﾞﾗ

**名無しさん＠お腹いっぱい。** · 05/03/13 21:16:57

Sgiのストレージ（ｗ
マジ受けた

**名無しさん＠お腹いっぱい。** · 05/03/13 21:18:17

>906
一緒に提供する = 相性がいい、というわけではないからね。
NTF = No Trouble Found
再現性なし、というやつだね。ご愁傷様。
でも二ヶ月は早かったね。うちがHPに頼んだときは半年かかってＮＴＦだったよ

**名無しさん＠お腹いっぱい。** · 05/03/13 23:44:08

いま明かされる、グーグル・データセンターの秘密
http://japan.cnet.com/news/media/story/0,2000047715,20081099,00.htm

**名無しさん＠お腹いっぱい。** · 05/03/14 06:42:20

>>921
googleはオンライン処理は多分検索のみなのでPC数千台を使用し
た分散システムでDBを構築できる。
通常の会社の業務処理は一般にはオンライントランザクションで
書きこみが発生するので分散できない。大規模DBサーバ１台に
まとめるしかない。

**名無しさん＠お腹いっぱい。** · 05/03/14 11:50:37

Oracle10gって凄いの？？

**名無しさん＠お腹いっぱい。** · 05/03/14 12:58:38

そこでSunの出番ですよ？

**名無しさん＠お腹いっぱい。** · 05/03/14 14:11:10

他社がプレゼン時の引き立て役に?

**名無しさん＠お腹いっぱい。** · 05/03/14 14:17:53

V40zと10gでスケールしますぅ

**名無しさん＠お腹いっぱい。** · 05/03/14 21:42:23

>>925
一歩間違えば詐欺だよな＜Sunのプレゼン

**名無しさん＠お腹いっぱい。** · 05/03/14 23:52:03

IBMの営業のほうが役者が２枚も３枚も上

**名無しさん＠お腹いっぱい。** · 05/03/15 01:04:55

あと下手うった案件を逃げるのもうまいよね。
だから儲かるんだよな。

残された下請けは悲惨ですが…

**名無しさん＠お腹いっぱい。** · 05/03/15 02:09:20

ttp://www.itmedia.co.jp/enterprise/articles/0502/24/news073.html
こういう類のネガティブキャンペーンってどう？
netappが優秀なのはともかく
>4CPU（750MHz）のモジュールで何と800万円
これってあからさまに出るの広告記事だよな
動いてるものをスケールアップできるんだから安全牌なのに
じゃあIA鯖で同数CPU積んで幾らになるか見積もり取ってみろってーの
結局落ち着いた構成ならdellの替わりにv20zで問題ないだろって

**名無しさん＠お腹いっぱい。** · 05/03/15 02:35:01

最近負荷がかかる時間帯にFFの調子が悪くなるようになった
原因はこれか！って、誰かが日記で書いてなかったっけ？
読んだ覚えはあるんだけど見つからない…

**名無しさん＠お腹いっぱい。** · 05/03/15 03:13:38

>>930
Dellでも良ければv20z選びたくないわ

**名無しさん＠お腹いっぱい。** · 05/03/15 03:24:33

http://66.102.7.104/search?q=cache:hRmBRmegrtsJ:live19.2ch.net/test/read.cgi/ogame/1109254232/-100+%22%2Bwww.itmedia.co.jp/enterprise/articles/0502/24/news073.html%22&hl=ja
DellよりはHPにして欲しい元Compaqのヤツ
このURLでググればいろいろ面白い記事でてくるよ（ｗ

**名無しさん＠お腹いっぱい。** · 05/03/15 04:31:02

てゆうか、OracleのDBをNFS経由でアクセスって、
ちょっとでも性能とか負荷耐性とかを気にする
用途だとありえない構成だよね。
誰だよこんな構成提案した奴。

SunFire 2台だったのがたった1年でIAサーバ8台に
増加しているのは、I/O性能がちゃんと出てないん
だろうな。

**名無しさん＠お腹いっぱい。** · 05/03/15 14:19:25

チューニングでDBのホットスポットを回避するってどうやるんだろうね>netapp
本番環境で実験させて貰えてベンダは大喜びだろうけど

**名無しさん＠お腹いっぱい。** · 05/03/15 14:30:54

SunってDebianの開発パートナーでもあったのか。
知らなかった。
しかもNiagaraのチームはDebian使ってるんだって？

**名無しさん＠お腹いっぱい。** · 05/03/16 00:41:37

特集：Solaris 10はLinux攻勢の切り札となるか――前編
http://www.itmedia.co.jp/enterprise/articles/0503/15/news050.html

**名無しさん＠お腹いっぱい。** · 05/03/16 01:01:50

>>937
これはとんでもない提灯記事。ZFSやlinuxとのバイナリ互換性など、まだできて
いないものをsolaris10の特長としてあげている。
こんな記事を書かせるから信用を失うのだ＞サン

**名無しさん＠お腹いっぱい。** · 05/03/16 01:02:56

ナイヤガラ量産の暁には！！

**名無しさん＠お腹いっぱい。** · 05/03/16 01:16:17

Chicago18 でも聴いてるとしよう

**名無しさん＠お腹いっぱい。** · 05/03/16 01:31:10

>>939
OSがLinuxになってるわけか

**名無しさん＠お腹いっぱい。** · 05/03/16 02:28:58

Microsoft Solarisになって第二の黄金期を・・

**名無しさん＠お腹いっぱい。** · 05/03/16 02:53:57

心理テストです。

3人が溺れています。あなたは一人しか助けることができません。
次のうち誰を助けますか？

1. Sun
2. Solaris
3. SPARC

**名無しさん＠お腹いっぱい。** · 05/03/16 02:55:59

誰も助けない

**名無しさん＠お腹いっぱい。** · 05/03/16 03:41:57

>>934
NetAppの場合Localディスクアクセスに匹敵するのを知らんのか。
今時DASやFC-SANにこだわる香具師は負け組。

**名無しさん＠お腹いっぱい。** · 05/03/16 06:02:54

EMCもそうだよ。
もちろん速度だけ見れば割高だけど、速度だけじゃあねえ。

ファイルシステムは、I/O高不可の場合、
ディスクアクセスが最大のボトルネックなので、
ギガイーサをトランクすれば、遠隔ファイルシステムであることの損失は極めてわずか。
一方優れたファイルサーバのサービスの優秀さと言ったら…

**名無しさん＠お腹いっぱい。** · 05/03/16 07:17:02

>>945
この場合、NAS へのアクセスはせいぜい Gigabit Ether でしょ？
とするとトランクしてたとしてもバンド幅は120MB/s×N。
SCSIバス1本にも劣る性能しか実測では出ないんじゃない？
それにNetAppがいくら優秀でも、NFSクライアント側にそれについて
いくだけの性能がでなきゃ意味がない。この場合、N対1で使うわけ
じゃないんだから。
もっともDellだと、どちらにせよすぐにI/Oバスネックになりそうな
気がするが。

**名無しさん＠お腹いっぱい。** · 05/03/16 07:44:51

新スレ用意しておきました。

http://pc5.2ch.net/test/read.cgi/unix/1110926614/

**名無しさん＠お腹いっぱい。** · 05/03/16 09:24:46

高負荷の DBの場合、I/O性能を高めるために、Direct I/O を
用いて直接DMAを行ない、CPU能力を消費しないようにするのが
当たり前。DASやFC-SANでDirect I/Oを使えば、実際、その
通りになる。
しかし、NFSのようにネットワーク系のデバイスドライバを
経由する場合、データ書き込みはともかく読み込みでは、
どうしてもCPUによるメモリコピーを行なわざるを得ない。
その分、I/O能力はどうしても落ちる。
>>945あたりは、そういうギリギリのレベルのチューニングの
ことを理解してないんじゃないかな。

**名無しさん＠お腹いっぱい。** · 05/03/16 09:41:04

>>947
だからRACと相性がいいんじゃないの？
Dell複数台にNetAppでRACを構築していたぞ、このまえのOWで。

**名無しさん＠お腹いっぱい。** · 05/03/16 09:44:39

>>949

from 最強ハイエンドストレージ列伝

信じる信じないは別として、、、

Oracle 10gでは、ネットワーク・ファイル・システム（NFS）もファイル・システム内の
Direct I/Oをサポートするようになりました。「Oracle 10gでは、パッチを適用しなくても、
データベース内で直接Direct I/Oがサポートされます。」とCoekaert氏は述べています。
「これでパフォーマンスが大幅に向上します。特に、NFSではすべてが高速になります。
これは、NFSでRACを実行する場合に非常に効果的です。」Coekaerts氏によると、
シングル・ノードでは、OSのファイル・システム・キャッシュにデータをキャッシュする
必要がなく、Oracleのキャッシュ・アルゴリズムを使用できるため、Direct I/Oの有益性が
さらに高まります。

参照 http://www.oracle.co.jp/technologies/linux/special/top4.html

**名無しさん＠お腹いっぱい。** · 05/03/16 10:20:10

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

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

**名無しさん＠お腹いっぱい。** · 05/03/16 10:49:23

> 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 にはかなわんよ。

**名無しさん＠お腹いっぱい。** · 05/03/16 11:00:53

> Linux の NFS で zero copy ができるようになったのは、
> NFS サーバー機能に関してだけみたいだな。

さらに訂正。Linux 2.5.70 の時点で、NFS クライアント
側についても zero copy が入ったようだ。(ただし、もちろん
送信処理のみ)
結局、953 は不要で、952 そのままで正しかったようだ。

**名無しさん＠お腹いっぱい。** · 05/03/16 11:11:41

あと、>>951の記事は、zero copy のことを言ってるんじゃ
なくて、O_DIRECT で page cache をバイパスする話をして
るのかもしれんな。Oracle がキャッシュしているデータを
さらに page cache に持つのは無駄だからな。
その場合、write だけじゃなくて read の性能にも関係する
が、どちらにせよ >>952 の理由から、DASやFC-SANにかなう
まい。

**名無しさん＠お腹いっぱい。** · 05/03/16 11:45:15

限界性能を気にするシステムってどれほどあるのかな？
むしろ、バックアップや増設を考えると、NASでRACを
構築するほうがメリットがでかいと思うのだが。。

EMCで構築を考えていたが、NetAppも検討してみるか。。

**名無しさん＠お腹いっぱい。** · 05/03/16 11:46:10

>>943
とりあえず Sunに止めを刺す

**名無しさん＠お腹いっぱい。** · 05/03/16 11:56:01

DASやFC-SANなら、高負荷時にもI/O要求や応答が失われる
心配はないけど、NASだと負荷がかかると(NAS側は大丈夫
でも)NFSクライアント側がパケットを落す危険があるから、
性能だけじゃなくて、高負荷時の安定性にも難があるんじゃ
ない？
それにDBの場合、SANでもバックアップや増設の手間は
たいして変わらん気がするが。

**名無しさん＠お腹いっぱい。** · 05/03/16 15:45:10

>>943
SPARC

**名無しさん＠お腹いっぱい。** · 05/03/16 15:45:17

スレ住民の仕事内容が垣間見える流れでした

**名無しさん＠お腹いっぱい。** · 05/03/16 15:46:19

>>943
見てみぬ降りをして、Javaと駆け落ちします。

**名無しさん＠お腹いっぱい。** · 05/03/16 16:31:52

NetAppの工作員が紛れこんでるような希ガス

**名無しさん＠お腹いっぱい。** · 05/03/16 19:05:06

http://blogs.sun.com/roller/page/jonathan
http://blogs.sun.com/roller/page/ako/
http://blogs.sun.com/roller/page/chats/
http://blogs.sun.com/roller/page/akihito

毎日更新して欲しい、内容は評価する。

**名無しさん＠お腹いっぱい。** · 05/03/16 19:16:40

>>963
ブログでまで、SunグリッドとIBMグリッドの比較やってる
さすが社長さん、必死だな

**名無しさん＠お腹いっぱい。** · 05/03/16 19:52:26

このスレがDat堕ちする可能性なのど考えてもみなかったよ。

**名無しさん＠お腹いっぱい。** · 05/03/16 20:48:41

Sun Grid
一瞬、オオと思うが、よく考えてみると数百ドルで数GHzのPCが手に入る今
そんなややこしい事するかね。
数GHz以上のパワーが欲しけりゃBeowulfする方がイイ。

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

Honeycomb
ストレージ2大勢力の切り崩しは無理。
CPUもおぼつかないのにいらん事に金使うな。

**名無しさん＠お腹いっぱい。** · 05/03/16 21:27:51

Beowulfのような特定組織内のクラスタを安全にInternet全体に
広げたものがGridの筈だが?

**名無しさん＠お腹いっぱい。** · 05/03/16 22:05:35

従量制のグリッドコンピューティングサービスに対してと意味で受け取ってクレ。

**名無しさん＠お腹いっぱい。** · 05/03/16 22:28:15

Sun、Javaのライセンス条件を緩和へ
http://www.itmedia.co.jp/enterprise/articles/0503/16/news026.html

**名無しさん＠お腹いっぱい。** · 05/03/17 00:19:33

>>952
クロック1GHz程度のsparcならメモリコピー性能は1Gbyte/s程度はでる。
なのに、100Mbyte/sのTCPの転送をすると1GHzのCPUを使い切ってしまうのは
何故か？よく考えてみよう。メモリコピーはボトルネックではない。TCP/IP
のプロトコル処理そのものがボトルネック。
うそだとおもうのなら、TCPの転送をしながらlockstat -kIW -D 20で
カーネルのプロファイリングを調べてみるのがよい。

**名無しさん＠お腹いっぱい。** · 05/03/17 00:20:55

最近はNICで処理してますけどね─

**名無しさん＠お腹いっぱい。** · 05/03/17 00:53:06

結局NASだと、TCPとかそういう余分なものを経由するので
イクナイと。で、あの構成提案したのはダレ？ Dell？

**名無しさん＠お腹いっぱい。** · 05/03/17 01:09:20

Linuxを例にしてNFS時のcopyを議論していたけど、
SANでもLinuxで動かすのかい?

**名無しさん＠お腹いっぱい。** · 05/03/17 09:55:17

アプリケーションからIP層をスルーしてethernetのようなデータリンク層で
直接やりとりするようになると早くなるの？ど素人な質問ですみません。

**名無しさん＠お腹いっぱい。** · 05/03/17 10:10:36

Direct Access Storage (IDEとかSCSIとか)もFibreChannelも、
カーネルから見るとEthernetじゃなくて、ブロックデバイスに
見えるの。だから、そもそもネットワーク処理のためのオーバー
ヘッドは全然かからないし、プロトコルヘッダの処理も要らな
いから、メモリの中身を直接ディスクとの間でDMAできるの。

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

まあ最近はTCPぐらいなら、ハードウェアがやってくれる場合も
多いけど(TCP Segment Offloading)、NFSを使おうと思うと、
SunRPCとかNFSとか、さらに上位層のヘッダがあるので、結局
効率ではDASやFCにかなわない。

**名無しさん＠お腹いっぱい。** · 05/03/17 10:27:14

ネットワーク経由ストレージ接続したところで、
本当に性能が気になるならばそれ専用セグメント作りたくなるのが
世の常人の常と思うので・・・

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

※なんちゃって環境だったら変わるだろうけれども

**名無しさん＠お腹いっぱい。** · 05/03/17 10:43:05

最近のCPUで、TCP overhead を気にする必要があるのか？
昔のSunマシンならともかく。。。
そんなのサーバがしょぼいっていっているようなもんじゃないのか？
おまけにNASで専用セグメントつくっても、圧倒的に
SANよりやすいじゃねーか！
FC SWなんて高すぎ。おまけにSANでヘテロな環境構築できねーよ。
現実的に。一社でチンいつするならべつだが。
ヘテロなSANでまともにサポートできるとこあんのか？

**名無しさん＠お腹いっぱい。** · 05/03/17 10:46:46

どうなんだろ。俺的にはNASは、もうちょっとお手軽に
使うイメージがあるけど。既存ネットワーク上、たくさん
のマシンから共用して使うみたいな。
こういう使い方をするとNAS:クライアント=1:Nでの利用
になるから、NAS側の性能は確かに必要なんだけどね。

**名無しさん＠お腹いっぱい。** · 05/03/17 10:57:54

> 最近のCPUで、TCP overhead を気にする必要があるのか？

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

こんなの誰でも簡単に評価できる話だと思うけど、試してないの？

**名無しさん＠お腹いっぱい。** · 05/03/17 11:07:23

NASは、かなり強力なCPUをnetwork interface上に持っているよ。つまり必要。
いまやPCIに指す普通のNICでもTCP位は処理するし。

**名無しさん＠お腹いっぱい。** · 05/03/17 11:08:17

>>978
10年近く前はそうだったけど、
今は性能のことを考えても完全に選択肢に入ってきている。

**名無しさん＠お腹いっぱい。** · 05/03/17 11:17:32

>>981
NAS 1台で複数のNFSクライアントにサービスして、
クライアント1台あたりの性能はそこそこでいいなら
大丈夫だけど、NAS:NFSクライアント=1:1で限界性能
出そうと思うと、>>979が出した値ではかなり厳しい
んじゃない？

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

まあ、自分ではちゃんと性能評価できないお客さん
なら気づかないかもしれないけどさあ。

**名無しさん＠お腹いっぱい。** · 05/03/17 11:19:04

SANとNASでCPUを消費するポイントがことなるだけじゃないの。

**名無しさん＠お腹いっぱい。** · 05/03/17 11:20:25

というよりDASやFC-SANが、NASよりもCPUを消費しない
(プロトコル処理がないから)ってことでしょ。

**名無しさん＠お腹いっぱい。** · 05/03/17 11:28:57

> SANとNASでCPUを消費するポイントがことなるだけじゃないの。
×CPU
〇金

**名無しさん＠お腹いっぱい。** · 05/03/17 12:17:04

http://www.itmedia.co.jp/survey/articles/0503/16/news061.html
外資と国産との差が顕著に表れた2004年の国内サーバ市場

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

**名無しさん＠お腹いっぱい。** · 05/03/17 13:23:06

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

そう思う人の心理の問題だと思う。

**名無しさん＠お腹いっぱい。** · 05/03/17 15:13:27

んじゃあもらうよ1000

**名無しさん＠お腹いっぱい。** · 05/03/17 15:13:53

>>1000

**名無しさん＠お腹いっぱい。** · 05/03/17 15:14:51

>>1000ｹﾞｯﾄ

**名無しさん＠お腹いっぱい。** · 05/03/17 15:15:11

>>1000ｹﾞｯﾄ

**名無しさん＠お腹いっぱい。** · 05/03/17 15:15:47

米IBM、米Novellと商業協定を締結し全サーバーにSUSE LINUX搭載へ
http://enterprise.watch.impress.co.jp/cda/foreign/2004/03/25/1777.html

1000にむけ燃料投下

**名無しさん＠お腹いっぱい。** · 05/03/17 15:16:09

>>1000ｹﾞｯﾄ

**名無しさん＠お腹いっぱい。** · 05/03/17 15:16:30

>>1000ｹﾞｯﾄ

**名無しさん＠お腹いっぱい。** · 05/03/17 15:17:59

>>1000ｹﾞｯﾄ

**名無しさん＠お腹いっぱい。** · 05/03/17 15:18:23

>>1000ｹﾞｯﾄ

**名無しさん＠お腹いっぱい。** · 05/03/17 16:53:10

NFSv4 に期待！
Solaris10 頑張れ！
unix 厨ならnasだろーがっ！

**名無しさん＠お腹いっぱい。** · 05/03/17 17:27:42

1000なら、Linux滅びる

**名無しさん＠お腹いっぱい。** · 05/03/17 17:28:02

１０００ゲッチュです

**名無しさん＠お腹いっぱい。** · 05/03/17 17:28:24

1000なら、Windows滅亡する

**１００１** · Over 1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。