Q&A
ご回答ありがとうございます。
> サーバ本体の電源モジュールは２つインストールし、電源は、系統の異なる電源系統1、電源系統2からそれぞれ供給すれば信頼性はあがります。
は実施済みです。電源断の表現が不完全でした。カーネルパニック等を想定しています。
また運用の煩雑への課題が残ってしまいます。
Linux (RHEL 7.2)上に16[GByte]のファイルシステムを構築しました。
このファイルシステムの内容をメモリに常駐させたいと考えております。
物理メモリはこのファイシステムの情報をすべて保持するだけの十分な容量があります。
当初考えていたのは、OS 起動時にファイルシステムに格納されているファイルを全て読み込み /dev/null に捨てると言う方法です。これにより、ファイルシステムの内容は、一旦はメモリ上にキャッシュとして読み込まれ、次回以降、物理ディスクにアクセスを行うことなくファイルの読みこみができます。
しかし、この方法ですと、他のファイルシステムの読み込みが行われた場合、そのファイルシステムの情報がメモリ上にキャッシュとして読み込ま、最初に格納された目的のファイルシステムの情報がキャッシュから追い出されてしまいます。
これを防ぎたいと考えておりますが、何か良い方法はございますでしょうか?
特定のファイルシステム「専用」に、メモリ上にキャッシュを確保できるれば良いのですが。
これ以外の方法として tmpfs を使用する方法も考えましたが、ファイルシステムに書き込まれた情報を不揮発性の記録媒体に退避する運用が煩雑になるのと、不意の電源断等の障害が発生した際の信頼性に影響が出るため、この案の採用は難しい状況です。
(追記)
mmap()でファイルの内容をプロセスメモリにマッピングし、当該領域をスワップアウト禁止とする方法はありませんでしょうか?
最悪、このようなデーモンを作成し、常駐させることにより、バッファからの追い出しを防ぐことが出来るかと考えています。(検証は必要ですが、まずはできるかどうか)
(追記1)
mlock()が使えそうです。引き続き調査中。
(追記2)
open(), mmap(), mlock()を使用したアプリを作って検証。
dd文で直接デバイスファイルの読み取りを行う分には効果あり。
しかしながら、デバイスファイル上に作成したファイルシステム上での読み取りでは効果なく、それぞれ別にキャッシュされる。(free, iostatコマンドで確認)。
なんでだろ・・・。
回答3件
0
自己解決
出来ました。デバイスファイルを直接open(), mmap(), mlock()するのではなく、1クッション置いたファイルシステムに対して実行するようにしました。以下。
- 既存のファイルシステム上にメモリ常駐させたいファイルシステム用の通常ファイルを作成。
(ddコマンドで)
0. 作成した通常ファイルをファイルシステムとしてフォーマット
(mkfsコマンドで)
0. 通常ファイルを指定してマウント
(mountコマンドで)
0. 通常ファイルをopen(), mmap(), mlock()したまま起動し続けるアプリを実行。
投稿2016/10/22 14:18
総合スコア125
0
これ以外の方法として tmpfs を使用する方法も考えましたが、ファイルシステムに書き込まれた情報を不揮発性の記録媒体に退避する運用が煩雑になるのと、不意の電源断等の障害が発生した際の信頼性に影響が出るため、この案の採用は難しい状況です。
クラスタを組んだり、横に並べれば信頼性への対応は可能です。
また、サーバ本体の電源モジュールは２つインストールし、電源は、系統の異なる電源系統1、電源系統2からそれぞれ供給すれば信頼性はあがります。
投稿2016/10/22 07:56
総合スコア6621
実施済なんですね。
運用の煩雑というのはどこまで許容できるか決めの問題ですしね。
ikedasさんの回答している通り、ディスクに何を導入するか見直せば運用の煩雑は減らせると思いますよ。障害時はベンダーが対応、これにまさる運用の楽さはありません。
SSD以外ですと、FusionIO社のioDrive等いかがでしょうか。
ご回答ありがとうございます。
やはり、ハード増強が必要なのでしょうか・・・。
色々工夫して上のレイヤーであれこれやるのと、ハード増強で解決するのでどちらがTCOが低くすむかって話にたどり着くと思います。
運用が煩雑になると障害時の対応にコストがかかり、更に機会損失も大きくなると思います。それならお金で解決したほうがハッピーだと思います。
0
「ファイルシステムの内容をメモリに常駐させたい」とのことですが、RAMディスク (tmpfsもこれです) を使ってメモリに常駐させると
ファイルシステムに書き込まれた情報を不揮発性の記録媒体に退避する運用が煩雑になるのと、不意の電源断等の障害が発生した際の信頼性に影響が出る
ということは避けられないと思います。
Linuxカーネルでは、空きメモリ領域は優先的にディスクキャッシュに割り当てられます。ですので当初検討された方法であれば実質的に「メモリに常駐」を実現できているとも言えます。同時に、ライトバックが常時行われているため、障害対策もできていると言えます。
投稿2016/10/22 07:39
総合スコア4443
ご回答ありがとうございます。
>当初検討された方法であれば実質的に「メモリに常駐」を実現できているとも言えます。同時に、ライトバックが常時行われているため、障害対策もできていると言えます。
はい。私も、これがベストだと考えています。
しかしながら、本文中にも記載しましたが、このOSには複数のファイルシステムが存在します。
ファイルシステムAとファイルシステムBがあったとして、ファイルシステムAのみをメモリに常駐させたいと考えています。
何もしなければファイルシステムAへの読み書きがしばらく行われない状態で、ファイルシステムBへの読み込みが発生した場合、ファイルシステムAのキャッシュが追い出されてしまいます。
ファイルシステムA専用のキャッシュ領域を作成し、他のファイルシステムへのアクセスに影響を受けることなく常にメモリに常駐させたいのです。
LinuxであればダイレクトI/O http://itpro.nikkeibp.co.jp/article/Keyword/20070207/261244/ を使ってキャッシュを経由**せずに**アクセスすることが可能です。アプリやミドルウェア毎の対応になりますが。MySQLなどが対応しています。
なお、使われていないキャッシュがメモリから追い出されても、パフォーマンスへの影響はほぼないと考えられます。そもそも、メモリキャッシュを増やすことによって本当にパフォーマンスが上がるのかどうかは、実運用環境に近い環境で検証しないと確定できないことだと思います。
あと、キャッシュのためにメモリに投資するより、ディスクドライブ自体を大容量キャッシュのものやSSDにするという手もあると思います。
ご回答ありがとうございます。
> メモリキャッシュを増やすことによって本当にパフォーマンスが上がるのかどうかは、実運用環境に近い環境で検証
環境を専有した状態で検証を行い、実運用環境で効果があることは検証済みです。ただし、先述の「ファイルシステムB」へのアクセスによる追い出しが問題となっております。ファイルシステムBもUNIXファイルシステムで通常運用に使われています。
> メモリに投資
メモリに余裕がある現実でこれを活用する方法を検討しております。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/10/22 16:10
2016/10/22 16:31