アカウント名:
パスワード:
OSをSSDにすれば、起動やシャットダウン、サスペンドがは速くなると思うんですが、OS起動後はメモリにOSが乗るのであまりSSDの恩恵はなさそうな気がする・・・
ファイルを頻繁に更新するような作業をする場合はOSよりも作業領域をSSDにした方が快適な気がする
WindowsNTだとカーネルコードもページアウトするよ
そうさせないためのレジストリ設定がありますよ
それに加えて, 各アプリケーションプログラムが使用する細かいワークファイルやローカルキャッシュファイルをRAMディスクに置いて, 適当なタイミングでバッチ的に退避・同期させるのがいいんじゃないかと.
細かい書き込みを頻繁に行うのはSSDが比較的苦手とする処理で寿命にも影響するし, それに主記憶が8GBほどあれば1〜2GB程度RAMディスクにまわしても大丈夫でしょうし.
# メモリをそれほど消費しない用途のクライアントPCの話ね
仮想メモリとディスクキャッシュを混同してません？また、RAMディスクはディスクに書き込まないデータを明示的に決定しますがライトバックなディスクキャッシュでの書き込みは、すべてのデータがディスクに書き込まれる保証はありません。
>細かい書き込みを頻繁に行うのはSSDが比較的苦手とする処理で寿命にも影響するしHDDに比べればSSDの方が得意でSSDを使う理由の一つでもあるけどな。
>細かい書き込みを頻繁に行うのはSSDが比較的苦手とする処理で寿命にも影響するし HDDに比べればSSDの方が得意でSSDを使う理由の一つでもあるけどな。
いえ, 現在のSSDの主流であるFlashメモリでは, 内部的な書き込みの単位はハードディスクなどの512バイトや4096バイトといったレベルではなく, 数10kB(おそらくは64kB以上)から1MB単位のブロックで行われます. また, Flashメモリでの書き込み処理は, 既存のデータを保持した状態から別のデータを書き込むのではなく, 一旦ブロック全体を消去して, そこに新しいデータを書き込むという手順になります. この時, ブロックを消去するのにかかる時間はブロックに書き込む時間よりもはるかに長いため, 多くのSSDではあらかじめ消去しておいたブロックに変更後のデータを書き込むことにより, 見かけ上の書き込み速度を上げています.
そのため, SSDで小さなデータを多く書き込む処理を行った場合, インターフェイス側から見るデータ量よりもはるかに多くのデータ量に対応するブロックを書き換えなければならないことになり, 事前に消去しておいたブロックの底がついた場合にはプチフリというような形で急激な速度低下が発生することになります.
# このあたりの挙動はコントローラやファームの出来で大きく変わりますが
一般的なSSDという話で, バッテリーバックアップRAMディスク(エンタープライズ向けデータベースサーバなんかで使われるやつ)を考えるのなら, 確かにその通り.
動作はその通りだと思うのですが、4000MB分の4KB Random Write (CrystalDiskMark)だとSSDがHDDより圧倒的に速いようです。
SSDの例として、PCWatchにの記事にあるIntel Solid-State Drive 520/320でのCrystalDiskMark 4000MBの結果を見るとhttp://pc.watch.impress.co.jp/docs/column/hirasawa/20120207_510153.html [impress.co.jp]
Intel Solid-State Drive 520 [intel.com]のランダムライト4KBは81.70MB/sなので81.70*1024/4=20915IOPS
Intel Solid-State Drive 320 [intel.co.jp]のランダムライト4KBは39.01MB/sなので39.01*1024/4=9987IOPS
これに対して7200rpmのハードディスクだとMARSHAL MAL2500SA-T72のランダムライト4KBは0.973MB/s [thinkpad-t.net]なので0.968*1024/4=248IOPS
条件にもよりますが、上記の例ではSSDがそれぞれ、40倍、84倍速い様です。
ところで、FlashメモリのBlock Eraseは単位が大きいので、スループットとしてはPage Writeとそれほど変わらなかった筈ですよ。
数年前の知識で止まってるようですが、いまどきのSSDでプチフリなんてもはや死語です。その辺お店で売ってる、コンシューマ用の1-2万円のSSDであっても、そういう現象は起きない。
SSDの物理的はデータ配置と、論理的なアドレスはまったく異なります。小さなデータをランダムなアドレスに書き込む場合、論理的なアドレスはばらばらですが、物理的には連続したメモリブロックに書き込まれます。書き込んだ後に、アドレス変換テーブルを書き換えておく。こういう動作なので、小さいデータをランダムに書き込んでも、急激に寿命が低下するということも起きません。
逆に小さなデータをランダムに読み出す場合には、物理的に非連続なメモリブロックから読み出す必要があるので、少し遅くなります。大抵のSSDで、4kランダムリード/ライトでライトのほうが早いのはこのためです。
OSの仮想メモリが過去のアクセスパターンからキャッシュの取捨選択を判断せざるを得ないのに対して、RAMディスクではこれからの使い方を考えながらユーザが内容を取捨選択できるので、仮想メモリでは不可能なチューニングも可能。無意味ではないと思うよ。たとえば、高頻度で使用していたデータを以後使わなくなる場合とか、1回限りのデータ使用をOSのレイヤーで判断するのは困難なので、ユーザがRAMディスクに入れるデータをきちんと管理できればより高いパフォーマンスを期待できる。
自分の例だけど、先日複数のISOファイルを使用してVMにOSを入れるという作業を何回か行ったんだけど、もう使わないISOファイルもOSはキャッシュし続けてしまう。そのISOファイルをもう使わないというユーザ側の事情をOSは判断できないから当然なのだけど、ユーザ自身はもう使わないことを知っているから、RAMディスクであれば必要な期間だけISOファイルを入れておくということができる。
まぁ、割と極端なケースだとは思うけどRAMディスクのほうが有利なケースもあるということで。
メモリを潤沢に積んで動画編集の一時保存先なんてどうでしょう？＞RAMディスク
（停電したらチーンｗ）
64ｂｉｔ ＯＳにしたほうがはるかにマシ
64bitOSはRAMディスク使えないのか。
＃インメモリDBってのもあったね。一般用とちゃうけどｗ
＞1回限りのデータ使用をOSのレイヤーで判断するのは困難なので
1回しか使わないにしても、RAMディスクへ転送するための1回と、直接ディスクから読み込む1回でたいした違いなんかない気がするんだけど。まあ、シーケンシャルアクセスでRAMディスクへ転送、その後ランダムアクセスするのと、ディスクに対して直接ランダムアクセスする場合は違いが出てくるのかも知れないけど。
＞もう使わないISOファイルもOSはキャッシュし続けてしまう。＞RAMディスクであれば必要な期間だけISOファイルを入れておくということができる。
使わなきゃそのうち破棄されるでしょ。使うならキャッシュし続けられるでしょ。
RAMディスクを設定するほど潤沢にメモリを積んでるなら、十分にキャッシュされると思うんだけどね。OSが扱い切れない領域のメモリを有効利用するためのRAMディスクってのなら分かるけど。
キャッシュに入ってる頻繁に使われるデータが、1回しか使わないデカいデータで押し出されるのが問題だというなら理解できるがRAMディスクには関係がない話だし。
一時ファイルを作らずに全部オンメモリで持ってくれるアプリしか使わないんだ？すごいねぇ。
「俺はどうしても一時ファイルを%TEMP%に書きたいんだ！」と力説する困ったアプリのために32GB中4GBをRAMディスクに割いてるのでAC。
OSの起動モジュール部をSSDにして、それ以外をHDDに…ってするのが一番良さそう何ですよね。現状 Windows は難しいのかなぁ。Linux は頑張ればなんとかなりそうなのかな。iOS (OS X)はどうなんだろう?
#Windows はいい加減ユーザフォルダを別バーティションに入れる仕組みを用意して欲しい。
プロファイル領域全体でも、各ユーザーごとの個人領域を個別にでも変更できますが ＞ Windowsのユーザープロファイルプロファイル全体ならばインストールまたはアップデート時に最初から指定しておく事も出来ますし、また個人のプロファイル領域全体ではなくドキュメント領域だけでよければ各ユーザーが自分の物を個別に変更する事も出来ます。
Linuxはできるみたいですね。やったことないですけど。マウントポイントの移動 [google.com]
Ubuntuのインストーラでもそういう項目があったような気がします。
キャッシュはISRTじゃダメなん？
フォルダへドライブ割り当てならジャンクションがあるじゃない
# いずれも標準では使えんけど
お前が知らないだけ
こんな感じでどうでしょう<ProfilesDirectory>D:\Users</ProfilesDirectory>
もう面倒だから、ディスク上のコードを直接実行できる技術開発してよ
メインフレームでは、メインメモリのアドレス空間＝ストレージ、は昔からできたから。でも、PC向けは今までずっと、CPUアドレス空間＜平均的ストレージ容量、だったから。
メモリマップドファイルとは違うの？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
現状だと (スコア:3, 参考になる)
Re:現状だと (スコア:1)
OSをSSDにすれば、起動やシャットダウン、サスペンドがは速くなると思うんですが、OS起動後はメモリにOSが乗るのであまりSSDの恩恵はなさそうな気がする・・・
ファイルを頻繁に更新するような作業をする場合はOSよりも作業領域をSSDにした方が快適な気がする
Re:現状だと (スコア:1)
WindowsNTだとカーネルコードもページアウトするよ
Re:現状だと (スコア:1)
そうさせないためのレジストリ設定がありますよ
Re: (スコア:0)
Re:現状だと (スコア:1)
それに加えて, 各アプリケーションプログラムが使用する細かいワークファイルやローカルキャッシュファイルをRAMディスクに置いて, 適当なタイミングでバッチ的に退避・同期させるのがいいんじゃないかと.
細かい書き込みを頻繁に行うのはSSDが比較的苦手とする処理で寿命にも影響するし, それに主記憶が8GBほどあれば1〜2GB程度RAMディスクにまわしても大丈夫でしょうし.
# メモリをそれほど消費しない用途のクライアントPCの話ね
Re: (スコア:0)
RAMディスクで効率が良くなるようだったら、それは、仮想メモリのチューニングで同じ事が出来るわけで・・・。
Re: (スコア:0)
仮想メモリとディスクキャッシュを混同してません？
また、RAMディスクはディスクに書き込まないデータを明示的に決定しますが
ライトバックなディスクキャッシュでの書き込みは、すべてのデータがディスクに書き込まれる保証はありません。
>細かい書き込みを頻繁に行うのはSSDが比較的苦手とする処理で寿命にも影響するし
HDDに比べればSSDの方が得意でSSDを使う理由の一つでもあるけどな。
Re:現状だと (スコア:2)
いえ, 現在のSSDの主流であるFlashメモリでは, 内部的な書き込みの単位はハードディスクなどの512バイトや4096バイトといったレベルではなく, 数10kB(おそらくは64kB以上)から1MB単位のブロックで行われます. また, Flashメモリでの書き込み処理は, 既存のデータを保持した状態から別のデータを書き込むのではなく, 一旦ブロック全体を消去して, そこに新しいデータを書き込むという手順になります. この時, ブロックを消去するのにかかる時間はブロックに書き込む時間よりもはるかに長いため, 多くのSSDではあらかじめ消去しておいたブロックに変更後のデータを書き込むことにより, 見かけ上の書き込み速度を上げています.
そのため, SSDで小さなデータを多く書き込む処理を行った場合, インターフェイス側から見るデータ量よりもはるかに多くのデータ量に対応するブロックを書き換えなければならないことになり, 事前に消去しておいたブロックの底がついた場合にはプチフリというような形で急激な速度低下が発生することになります.
# このあたりの挙動はコントローラやファームの出来で大きく変わりますが
一般的なSSDという話で, バッテリーバックアップRAMディスク(エンタープライズ向けデータベースサーバなんかで使われるやつ)を考えるのなら, 確かにその通り.
Re:現状だと (スコア:2)
そのため, SSDで小さなデータを多く書き込む処理を行った場合, インターフェイス側から見るデータ量よりもはるかに多くのデータ量に対応するブロックを書き換えなければならないことになり, 事前に消去しておいたブロックの底がついた場合にはプチフリというような形で急激な速度低下が発生することになります.
動作はその通りだと思うのですが、4000MB分の4KB Random Write (CrystalDiskMark)だとSSDがHDDより圧倒的に速いようです。
SSDの例として、PCWatchにの記事にあるIntel Solid-State Drive 520/320でのCrystalDiskMark 4000MBの結果を見ると
http://pc.watch.impress.co.jp/docs/column/hirasawa/20120207_510153.html [impress.co.jp]
Intel Solid-State Drive 520 [intel.com]のランダムライト4KBは81.70MB/sなので
81.70*1024/4=20915IOPS
Intel Solid-State Drive 320 [intel.co.jp]のランダムライト4KBは39.01MB/sなので
39.01*1024/4=9987IOPS
これに対して7200rpmのハードディスクだと
MARSHAL MAL2500SA-T72のランダムライト4KBは0.973MB/s [thinkpad-t.net]なので
0.968*1024/4=248IOPS
条件にもよりますが、上記の例ではSSDがそれぞれ、40倍、84倍速い様です。
ところで、FlashメモリのBlock Eraseは単位が大きいので、スループットとしてはPage Writeとそれほど変わらなかった筈ですよ。
Re: (スコア:0)
数年前の知識で止まってるようですが、いまどきのSSDでプチフリなんてもはや死語です。
その辺お店で売ってる、コンシューマ用の1-2万円のSSDであっても、そういう現象は起きない。
SSDの物理的はデータ配置と、論理的なアドレスはまったく異なります。
小さなデータをランダムなアドレスに書き込む場合、論理的なアドレスはばらばらですが、物理的には連続したメモリブロックに書き込まれます。
書き込んだ後に、アドレス変換テーブルを書き換えておく。
こういう動作なので、小さいデータをランダムに書き込んでも、急激に寿命が低下するということも起きません。
逆に小さなデータをランダムに読み出す場合には、物理的に非連続なメモリブロックから読み出す必要があるので、少し遅くなります。
大抵のSSDで、4kランダムリード/ライトでライトのほうが早いのはこのためです。
Re: (スコア:0)
OSの仮想メモリが過去のアクセスパターンからキャッシュの取捨選択を判断せざるを得ないのに対して、RAMディスクではこれからの使い方を考えながらユーザが内容を取捨選択できるので、仮想メモリでは不可能なチューニングも可能。無意味ではないと思うよ。
たとえば、高頻度で使用していたデータを以後使わなくなる場合とか、1回限りのデータ使用をOSのレイヤーで判断するのは困難なので、ユーザがRAMディスクに入れるデータをきちんと管理できればより高いパフォーマンスを期待できる。
自分の例だけど、先日複数のISOファイルを使用してVMにOSを入れるという作業を何回か行ったんだけど、もう使わないISOファイルもOSはキャッシュし続けてしまう。
そのISOファイルをもう使わないというユーザ側の事情をOSは判断できないから当然なのだけど、ユーザ自身はもう使わないことを知っているから、RAMディスクであれば必要な期間だけISOファイルを入れておくということができる。
まぁ、割と極端なケースだとは思うけどRAMディスクのほうが有利なケースもあるということで。
Re:現状だと (スコア:2)
メモリを潤沢に積んで動画編集の一時保存先なんてどうでしょう？＞RAMディスク
（停電したらチーンｗ）
Re: (スコア:0)
64ｂｉｔ ＯＳにしたほうがはるかにマシ
Re:現状だと (スコア:2)
64bitOSはRAMディスク使えないのか。
＃インメモリDBってのもあったね。一般用とちゃうけどｗ
Re: (スコア:0)
インメモリDBも一般的なものもあります（Redisとか）。
# Accessと比べたら一般的ではないけれど。
Re: (スコア:0)
＞1回限りのデータ使用をOSのレイヤーで判断するのは困難なので
1回しか使わないにしても、RAMディスクへ転送するための1回と、直接ディスクから読み込む1回でたいした違いなんかない気がするんだけど。まあ、シーケンシャルアクセスでRAMディスクへ転送、その後ランダムアクセスするのと、ディスクに対して直接ランダムアクセスする場合は違いが出てくるのかも知れないけど。
＞もう使わないISOファイルもOSはキャッシュし続けてしまう。
＞RAMディスクであれば必要な期間だけISOファイルを入れておくということができる。
使わなきゃそのうち破棄されるでしょ。
使うならキャッシュし続けられるでしょ。
RAMディスクを設定するほど潤沢にメモリを積んでるなら、十分にキャッシュされると思うんだけどね。
OSが扱い切れない領域のメモリを有効利用するためのRAMディスクってのなら分かるけど。
キャッシュに入ってる頻繁に使われるデータが、1回しか使わないデカいデータで押し出されるのが問題だというなら理解できるがRAMディスクには関係がない話だし。
Re: (スコア:0)
一時ファイルを作らずに全部オンメモリで持ってくれるアプリしか使わないんだ？すごいねぇ。
「俺はどうしても一時ファイルを%TEMP%に書きたいんだ！」と力説する困ったアプリのために32GB中4GBをRAMディスクに割いてるのでAC。
Re:現状だと (スコア:1)
OSの起動モジュール部をSSDにして、それ以外をHDDに…ってするのが一番良さそう何ですよね。
現状 Windows は難しいのかなぁ。
Linux は頑張ればなんとかなりそうなのかな。
iOS (OS X)はどうなんだろう?
#Windows はいい加減ユーザフォルダを別バーティションに入れる仕組みを用意して欲しい。
Re:現状だと (スコア:2)
プロファイル領域全体でも、各ユーザーごとの個人領域を個別にでも変更できますが ＞ Windowsのユーザープロファイル
プロファイル全体ならばインストールまたはアップデート時に最初から指定しておく事も出来ますし、また個人のプロファイル領域全体ではなくドキュメント領域だけでよければ各ユーザーが自分の物を個別に変更する事も出来ます。
Re:現状だと (スコア:1)
Linuxはできるみたいですね。やったことないですけど。
マウントポイントの移動 [google.com]
Ubuntuのインストーラでもそういう項目があったような気がします。
640GBはすべての人にとって未来永劫充分なメモリだ。
Re:現状だと (スコア:1)
Re: (スコア:0)
キャッシュはISRTじゃダメなん？
フォルダへドライブ割り当てなら
ジャンクションがあるじゃない
# いずれも標準では使えんけど
Re: (スコア:0)
お前が知らないだけ
Re: (スコア:0)
こんな感じでどうでしょう
<ProfilesDirectory>D:\Users</ProfilesDirectory>
Re: (スコア:0)
もう面倒だから、ディスク上のコードを直接実行できる技術開発してよ
Re: (スコア:0)
メインフレームでは、メインメモリのアドレス空間＝ストレージ、は昔からできたから。
でも、PC向けは今までずっと、CPUアドレス空間＜平均的ストレージ容量、だったから。
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
メモリマップドファイルとは違うの？