- Community Home
- >
- HPE Community, Japan
- >
- HP-UX
- >
- System Management
- >
- キャッシュヒット率について
system management
1753716
メンバー
4786
オンライン
108799
解決策
フォーラム
カテゴリ
Company
Local Language
戻る
フォーラム
ディスカッションボード
フォーラム
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
ディスカッションボード
ディスカッションボード
ディスカッションボード
フォーラム
ディスカッションボード
戻る
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
ブログ
情報
コミュニティ言語
言語
フォーラム
ブログ
トピックオプション
- RSS フィードを購読する
- トピックを新着としてマーク
- トピックを既読としてマーク
- このトピックを現在のユーザーにフロートします
- ブックマーク
- 購読
- 印刷用ページ
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
01-29-2004 03:34 PM
01-29-2004 03:34 PM
キャッシュヒット率について
どうもです。
HP-UX11を使用しているのですが、
キャッシュヒット率が低いのです。
確認は"sar -d"を使いました。
これが低いというのはどういう
状況なのでしょうか?
あとどうすれば良いのでしょうか?
カーネルとかを変更するのですかね?
だれか詳しい方教えて下さい。
宜しくお願い致します。
HP-UX11を使用しているのですが、
キャッシュヒット率が低いのです。
確認は"sar -d"を使いました。
これが低いというのはどういう
状況なのでしょうか?
あとどうすれば良いのでしょうか?
カーネルとかを変更するのですかね?
だれか詳しい方教えて下さい。
宜しくお願い致します。
3件の返信3
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
01-29-2004 03:56 PM
01-29-2004 03:56 PM
キャッシュヒット率について
バッファキャッシュヒット率なら、sar -b ではないでしょうか?
バッファキャッシュヒット率ですが、read で常に 80% を割り、write で常に 60% を割るのであれば、低いと言えるかもしれません。これも一つの指標で、ファイルシステムの IO性能に問題がでていないのであれば、別に大丈夫だとは思いますが。
対処としては、バッファキャッシュを大きくすることです。しかし、バッファキャッシュを大きくすると、user プログラムで使用できるメモリが減ってしまうので、その辺りのトレードオフが難しいと思います。
もし sar -d ということであれば、具体的にどこを見ているのか教えていただけませんか?
バッファキャッシュヒット率ですが、read で常に 80% を割り、write で常に 60% を割るのであれば、低いと言えるかもしれません。これも一つの指標で、ファイルシステムの IO性能に問題がでていないのであれば、別に大丈夫だとは思いますが。
対処としては、バッファキャッシュを大きくすることです。しかし、バッファキャッシュを大きくすると、user プログラムで使用できるメモリが減ってしまうので、その辺りのトレードオフが難しいと思います。
もし sar -d ということであれば、具体的にどこを見ているのか教えていただけませんか?
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
01-29-2004 04:25 PM
01-29-2004 04:25 PM
キャッシュヒット率について
早速の返信ありがとうございました。
&申し訳ございません。
"sar -b"の間違いです。
ちなみにリードキャッシュの
アベレージは40%前後です。
カーネルは何を変えてあげれば
良いのでしょうか?
あとそれによるデメリットを
具体例に教えて下さい。
宜しくお願いします。
&申し訳ございません。
"sar -b"の間違いです。
ちなみにリードキャッシュの
アベレージは40%前後です。
カーネルは何を変えてあげれば
良いのでしょうか?
あとそれによるデメリットを
具体例に教えて下さい。
宜しくお願いします。
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
01-29-2004 05:00 PM
01-29-2004 05:00 PM
キャッシュヒット率について
カーネルパラメータについての説明(11.00)は以下のURLになります。各リリースごとにあるので、該当リリースのものを見るといいと思います。
http://docs.hp.com/ja/4434/html/KCparams.OverviewAll.html
ここの"ファイル・システム・バッファ・キャッシュに関する構成可能パラメータ"を見てください。default では DBC(Dynamic Buffer Cache)になっていると思いますので、通常 dbc_min_pct と dbc_max_pct というパラメータでチューニングすると思います。この範囲外になる場合は、bufpages を使って固定にするしかないでしょう。nbuf は使わない方がいいです。上記している URL でもそう書いてあります。
現在の buffer cache や物理メモリのサイズですが、glance とかを使われているのであれば、簡単にわかりますが、もしglance を購入されていないのであれば、以下のように調べるしかないと思います。
参考に実行結果をのせておきます。
物理メモリサイズの確認方法は ITRC の技術情報ベース(KBRC00001146)にあります。
# echo "phys_mem_pages/D" | adb64 -k /stand/vmunix /dev/mem
phys_mem_pages:
phys_mem_pages: 1048576
1048576x4KB=4GBです。
# sysdef | grep dbc
dbc_max_pct 15 - - -
dbc_min_pct 5 - - -
この場合、buffer cache の最小は物理メモリの 5%、最大は物理メモリの 15% の間で可変で、4GB の物理メモリであれば、256MB〜2GB いうことになります。
で、現在のサイズがどれくらいかというと、
# sysdef | grep bufpages
bufpages 157286 - 0- Pages -
(この bufpages はチューナブルパラメータの bufpages とは違います。)
157286*4KB=614MB になります。
バッファキャッシュを大きくすることによるデメリットですが、物理メモリを動的な視点でみると、以下のように表せます。
物理メモリ = user で使用するメモリ + system(カーネル)で使用するメモリ + バッファキャッシュ + freeメモリ
したがって、先にも書いたように、バッファキャッシュを大きくすると、user プログラムやカーネルで使用できるメモリが減ってしまうということです。これにより、キャッシュヒット率があがって、ファイルシステムIOの性能があがっても、user プログラムが使用できるメモリリソースが減ってしまうことで、結局は性能が落ちてしまうことも考えられます。この辺りのトレードオフをどうするかが、チューニングの最も難しいところです。物理メモリサイズや空きメモリサイズとともに、ファイルシステムIO依存なアプリなのか、メモリ依存なアプリなのかということも考えて、値を決める必要があります。
システムパフォーマンスチューニングに関する書籍はたくさん出ているので、じっくり読まれたほうがいいと思います。私は O'Reilly の System Performance Tuning という書籍を愛用しています。
http://docs.hp.com/ja/4434/html/KCparams.OverviewAll.html
ここの"ファイル・システム・バッファ・キャッシュに関する構成可能パラメータ"を見てください。default では DBC(Dynamic Buffer Cache)になっていると思いますので、通常 dbc_min_pct と dbc_max_pct というパラメータでチューニングすると思います。この範囲外になる場合は、bufpages を使って固定にするしかないでしょう。nbuf は使わない方がいいです。上記している URL でもそう書いてあります。
現在の buffer cache や物理メモリのサイズですが、glance とかを使われているのであれば、簡単にわかりますが、もしglance を購入されていないのであれば、以下のように調べるしかないと思います。
参考に実行結果をのせておきます。
物理メモリサイズの確認方法は ITRC の技術情報ベース(KBRC00001146)にあります。
# echo "phys_mem_pages/D" | adb64 -k /stand/vmunix /dev/mem
phys_mem_pages:
phys_mem_pages: 1048576
1048576x4KB=4GBです。
# sysdef | grep dbc
dbc_max_pct 15 - - -
dbc_min_pct 5 - - -
この場合、buffer cache の最小は物理メモリの 5%、最大は物理メモリの 15% の間で可変で、4GB の物理メモリであれば、256MB〜2GB いうことになります。
で、現在のサイズがどれくらいかというと、
# sysdef | grep bufpages
bufpages 157286 - 0- Pages -
(この bufpages はチューナブルパラメータの bufpages とは違います。)
157286*4KB=614MB になります。
バッファキャッシュを大きくすることによるデメリットですが、物理メモリを動的な視点でみると、以下のように表せます。
物理メモリ = user で使用するメモリ + system(カーネル)で使用するメモリ + バッファキャッシュ + freeメモリ
したがって、先にも書いたように、バッファキャッシュを大きくすると、user プログラムやカーネルで使用できるメモリが減ってしまうということです。これにより、キャッシュヒット率があがって、ファイルシステムIOの性能があがっても、user プログラムが使用できるメモリリソースが減ってしまうことで、結局は性能が落ちてしまうことも考えられます。この辺りのトレードオフをどうするかが、チューニングの最も難しいところです。物理メモリサイズや空きメモリサイズとともに、ファイルシステムIO依存なアプリなのか、メモリ依存なアプリなのかということも考えて、値を決める必要があります。
システムパフォーマンスチューニングに関する書籍はたくさん出ているので、じっくり読まれたほうがいいと思います。私は O'Reilly の System Performance Tuning という書籍を愛用しています。
上記の意見は、Hewlett Packard Enterpriseではなく、著者の個人的な意見です。 このサイトを使用することで、利用規約と参加規約に同意したことになります 。
© Copyright 2024 Hewlett Packard Enterprise Development LP