OpenSolaris/Illumos (OpenIndiana, etc.) 6 (768ﾚｽ)
OpenSolaris/Illumos (OpenIndiana, etc.) 6 http://mevius.5ch.net/test/read.cgi/unix/1337411922/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
471: 名無しさん＠お腹いっぱい。 [sage] 2013/10/02(水) 22:09:45.65 仮想マシン上のOpenSolarisにApacheとPHPをインストールしなければならないのですが、 手元の資料にはどちらも解凍・展開からの手順しか書いておらず進められずにいます 解凍・展開前に必要な準備等がありましたら教えて頂けないでしょうか http://mevius.5ch.net/test/read.cgi/unix/1337411922/471
472: 名無しさん＠お腹いっぱい。 [sage] 2013/10/02(水) 23:22:37.37 まず服を脱ぎます。 http://mevius.5ch.net/test/read.cgi/unix/1337411922/472
473: 名無しさん＠お腹いっぱい。 [sage] 2013/10/02(水) 23:24:29.22 まず服を脱ぎます http://mevius.5ch.net/test/read.cgi/unix/1337411922/473
474: 名無しさん＠お腹いっぱい。 [sage] 2013/10/03(木) 08:39:21.94 PHP出版に勤めます http://mevius.5ch.net/test/read.cgi/unix/1337411922/474
475: 名無しさん＠お腹いっぱい。 [sage] 2013/10/04(金) 19:51:07.50 PHP出版を辞めましたエントリを書きます http://mevius.5ch.net/test/read.cgi/unix/1337411922/475
476: 名無しさん＠お腹いっぱい。 [sage] 2013/10/04(金) 19:52:54.75 つまんね。 http://mevius.5ch.net/test/read.cgi/unix/1337411922/476
477: 名無しさん＠お腹いっぱい。 [sage] 2013/10/05(土) 21:05:41.25 >>467 スナップショットがこけててもバックアップがあるんだから問題ないだろ。 2TBの書き戻しは気が変になりそうだろうが、がんばれ/ http://mevius.5ch.net/test/read.cgi/unix/1337411922/477
478: 名無しさん＠お腹いっぱい。 [sage kani?] 2013/10/06(日) 15:15:27.57 >>471 展開前のブツをDLしてきたとか手持ちであるならそこから進めるだけじゃん？ｗ つーかその資料とやらを作ったヤシに聞けよ http://mevius.5ch.net/test/read.cgi/unix/1337411922/478
479: 名無しさん＠お腹いっぱい。 [sage] 2013/11/03(日) 12:20:27.14 CIFSストレージとして使ってますが、ストレージ空き容量が減ってくると 加速度的に読み書きが遅くなりますね http://mevius.5ch.net/test/read.cgi/unix/1337411922/479
480: 名無しさん＠お腹いっぱい。 [] 2013/11/03(日) 14:12:45.89 >>479 ZFSの事か？ ま、公式にも使用量は80%以下で使えと言われているし、 CoWの仕組み上、空き容量が減ってくると遅くなるのは、 しようが無い事ではある。 DISK数が少ないと、なおさら効いてくるかもな。 http://mevius.5ch.net/test/read.cgi/unix/1337411922/480
481: 名無しさん＠お腹いっぱい。 [sage] 2013/11/03(日) 15:14:16.11 そこでZILとL2ARCをSSDで、ですよ奥さん！ http://mevius.5ch.net/test/read.cgi/unix/1337411922/481
482: 名無しさん＠お腹いっぱい。 [sage] 2013/12/06(金) 22:56:03.83 dedup=onでrecordsize=4kとかにするとファイル書き込んだときにwriteが増えて異常に遅くなるんだがこれなんだろ? recordsize弄らなければ急に遅くはならないし、read増えてないのでDDTに書きに行ってるとかか?? recordsize大きいとデータに埋もれて見えないだけとかいうオチか? dedup率優先なpoolにしようかと思ったが遅すぎる 実験方法: vmに16〜32GB程度メモリ割り当て。zpool create ; zfs create ; zfs set dedup=on, compress=on, sync=disabled cp dummy_5GB.bin hoge zfs set recordsize=4k cp dummy_5GB.bin hoge http://mevius.5ch.net/test/read.cgi/unix/1337411922/482
483: 名無しさん＠お腹いっぱい。 [sage] 2013/12/07(土) 07:48:19.15 >>482 ttps://blogs.oracle.com/roch/entry/tuning_zfs_recordsize Other consideration (metadata overhead, caching) dictates however that the recordsize not be reduced below a certain point (16K to 64K; do send-in your experience). http://mevius.5ch.net/test/read.cgi/unix/1337411922/483
484: 名無しさん＠お腹いっぱい。 [sage] 2013/12/07(土) 19:19:55.08 今回のはdedupが支配要因に見えるしここまで遅いとそういう話ではないような気も。 ひとまず32kでやってみるけど。 ddtとかのメタデータって2〜3重化されてるんだっけ？ 実験的にOFFにできるのかな。 実験先のドライブが1LUNなのが問題な気がしてきた。 http://mevius.5ch.net/test/read.cgi/unix/1337411922/484
485: 名無しさん＠お腹いっぱい。 [sage] 2013/12/08(日) 08:34:34.33 2重化されてる。 ZAPはrecordsize単位で作られるのだから128K→4Kでは32倍にもなる。 http://mevius.5ch.net/test/read.cgi/unix/1337411922/485
486: 名無しさん＠お腹いっぱい。 [sage] 2013/12/08(日) 09:08:30.23 ところで、本番で想定しているプールサイズで、メモリ消費量予想してみました? ttp://www.c0t0d0s0.org/archives/7271-ZFS-Dedup-Internals.html RAM 32GB→ARC 24GB→metadata 6GB→... recorsize=4KBだと、プール1TBで DDT 3GBくらいとか? dedupでストレージを節約しようとしても、代償に必要とされる メモリが高コストにつくと、あまり意味ないのでは。 http://mevius.5ch.net/test/read.cgi/unix/1337411922/486
487: 名無しさん＠お腹いっぱい。 [sage] 2013/12/09(月) 19:54:47.72 >>485が書いてくれてるとおりrecordsizeの減少はmetadataの急激な増大を生むので単にそれが原因ぽい 特に1ドライブ上で実験してしまうと離れた位置に2重化して書き込もうとするので猛烈なrandom writeに。 (割とマシなSANでもRAID6 1LUNマウントでは追いつかなかった) 物理ドライブを8本にしてみたら極端な遅さにはならなくなった(1〜2本が酷いだけで4本程度あれば十分かもしれない)が write総量がかなり増えることには違いないので相性の良いハードで無い限りrecordsize=4kはしんどそう 格納するデータが2k〜4kブロックでないと重複排除が効きづらいものだとzfsの使用は悩ましいことになる recordsize=128kでの重複排除率が低すぎる場合はserver2012あたりに浮気した方がいいのかもしれない >>486 メモリ64のマシンが余ったので仮想で半分割り当ててみたんだがarc_meta_limit上げれば割と収まるんじゃないかなー 若しくはARCは16程度でL2に64くらいとか(計算してないけど) http://mevius.5ch.net/test/read.cgi/unix/1337411922/487
488: 名無しさん＠お腹いっぱい。 [sage] 2013/12/14(土) 09:43:55.45 Dedupの効率？みたいな物の比較ってある？ 確かにZFSでDedupしても予想の半分程度しか減らないことがある Compressと併用すると効率が悪くなったりしないよね http://mevius.5ch.net/test/read.cgi/unix/1337411922/488
489: 名無しさん＠お腹いっぱい。 [sage] 2013/12/14(土) 17:36:55.37 dedupは思ったほど効果なかったなぁ そのデメリットがあまりにひどすぎて使うのやめたが gzip圧縮の方がかなり効く そもそもdedupがそんなに必要となる状況ってどんなのがあるんだろう？ バックアップで各世代をそのまま保存しつつ、変更がないから同じファイルが いくつも存在するといった場合なら、そもそもsnapshotバックアップでいいし http://mevius.5ch.net/test/read.cgi/unix/1337411922/489
490: 名無しさん＠お腹いっぱい。 [sage] 2013/12/14(土) 20:40:55.24 仮想マシンのイメージファイル置き場がメジャーじゃね ひな形vmをコピーする際にzfs cloneすればいいんだが、実際は丸コピした方が楽な場合が多くw (ファイル単位でclone出来るようにはならんのか?) http://mevius.5ch.net/test/read.cgi/unix/1337411922/490
491: 名無しさん＠お腹いっぱい。 [sage] 2013/12/14(土) 20:50:36.07 マジレスすると、メールアーカイブで添付ファイルとかに効くと思う http://mevius.5ch.net/test/read.cgi/unix/1337411922/491
492: 名無しさん＠お腹いっぱい。 [sage] 2013/12/14(土) 22:28:48.23 添付ファイル単位で単離されてるならそりゃ効くだろうけども メル鯖によってはbase64encされた状態でtextの間に挟まってないかそれ? dedup効くのかね http://mevius.5ch.net/test/read.cgi/unix/1337411922/492
493: 名無しさん＠お腹いっぱい。 [sage] 2013/12/14(土) 22:42:06.40 >>490 cloneはファイルシステムを分けて使う場合は便利だけど、 逆にそれが不便になる場合もあるからねぇ さくらでZFSストレージをVPSのファイルサーバに使って大失敗してたけど あれどんなシステムでどんな失敗だったんだろうな http://mevius.5ch.net/test/read.cgi/unix/1337411922/493
494: 名無しさん＠お腹いっぱい。 [sage] 2013/12/14(土) 23:55:38.85 上で上がってたような特定用途の領域を必要なだけFSとして切り出してdedupかけるのが （メモリ的にも現実的な）本来の用途なわけで、数TB、数十TBのプール全体にdedupかけて、なんてのはアホの極みでしかないな。 1GBくらいのディスクイメージcpして使用領域増えてないわーい、みたいなブログ記事たまに見るけどそんなこと言ってもねぇ・・・ http://mevius.5ch.net/test/read.cgi/unix/1337411922/494
495: 名無しさん＠お腹いっぱい。 [sage] 2013/12/15(日) 01:01:29.62 さくらの場合はnfsで使っていて1000台ぐらいで性能が頭打ちに なったとかどっかで見た気がする。 そもそもnfsを使うのが筋が悪かった。 http://mevius.5ch.net/test/read.cgi/unix/1337411922/495
496: 名無しさん＠お腹いっぱい。 [sage] 2013/12/15(日) 01:33:43.51 特定用途のvm置き場にdedupかけたけど効果はさっぱりだったな。ブロックサイズ固定まではしてみなかったが さくらはzfsでdedupかけてたのかな？ どちらにせよzfs自体が大規模トラフィックに向いてない気がするな。nfsは構造上小規模向けだろうに GlusterFSやらの分散型でスケールアウト狙った方が http://mevius.5ch.net/test/read.cgi/unix/1337411922/496
497: 名無しさん＠お腹いっぱい。 [sage] 2013/12/15(日) 01:38:34.13 NFSはそもそも共有して意味があるんであって クライアントが別々にのファイルにアクセスするなら NFSする意味がないからな iSCSIの方が良かったんじゃないのかと cloneで同じ設定のVMを作り出すのは便利だからそこだけうまくやってればねぇ http://mevius.5ch.net/test/read.cgi/unix/1337411922/497
498: 名無しさん＠お腹いっぱい。 [sage] 2013/12/15(日) 09:54:37.02 共有してるからvMotionできる iSCSIよりずっと手軽で管理しやすい http://mevius.5ch.net/test/read.cgi/unix/1337411922/498
499: 名無しさん＠お腹いっぱい。 [sage] 2013/12/15(日) 10:44:40.53 それは微妙にzfsとは違う方向から異論が出そうだが、 iscsiの使い勝手が悪い件については賛成。 そりゃnfsでファイル見えてりゃ規模が大きくなればなるほど管理が圧倒的に楽になる。 ただzfsでサブディレクトリ作ってもクライアントから追加でマウントしないと共有が見えない。 Linuxのnfsdで出来てるんだから何とかしろよ絶対便利だろそれorz http://mevius.5ch.net/test/read.cgi/unix/1337411922/499
500: 名無しさん＠お腹いっぱい。 [sage] 2013/12/15(日) 11:04:15.45 サブディレクトリ？？？ http://mevius.5ch.net/test/read.cgi/unix/1337411922/500
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 268 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.018s