1. TOPTOP
  2. Webサービス
  3. Google

PageSpeed Insights の最適化提案 「サーバーの応答時間を短縮する」について解決する 〜 その5(slab_casheを解放する)

|

reduce_server_response_time_page_insights_0

前回の記事(新しいタブで開く)で仮想ディスクの容量を増加させることで、swapとslab_casheを抑えることについて記事を書きました。ところが引き続きMuninでメモリの様子を確認していると、ふたたびslab_casheの容量が増大してきました。

増え続けるslab_cashe

reduce_server_response_time_pagespeed_insights_5_1

どうやら増加した仮想ディスクの容量を認識させただけでは、slab_casheの肥大化を止めることはできない様子です。slab_casheの肥大化を止めるためには、直接slab_casheに作用する対策が必要です。以下の文章ではそのslab_casheを抑制するために取った対策についてご紹介します。

なお、今回の記事は上記のページを参考にさせていただきました。関係者のみなさまありがとうございます。

slab_casheの解放について

ググっていろいろと調べていると、slab_casheを解放する方法として3つの方法があるようです。個人的には1と2の方法は上手く行きませんでしたが、3の方法でslab_casheを解放することができました。

1.tmpfsを揮発性メモリに保存させる

# cd /etc/sysconfig/httpd
# export TMPDIR=/dev/shm

tmpfs(新しいタブで開く)とはUnix系OSにおける一時ファイルのための仕組みの共通名のことを指します。tmpfsはファイルシステムにマウントされることを意図されています、そのマウント先をRAMディスクの”dev/shm”に変更します。

reduce_server_response_time_pagespeed_insights_5_2

具体的には環境変数を使ってパスを通しますが、自分がやるとなぜかパスが通ってません。失敗していると思います。

2.NSS_SDB_USE_CACHEの活用

export NSS_SDB_USE_CACHE=YES

“NSS_SDB_USE_CACHE”の”NSS”は”Network Security Service(新しいタブで開く)“のことを指します(ただNSSがメモリとどう関係あるのかは分かりません)。

reduce_server_response_time_pagespeed_insights_5_3

NSS_SDB_USE_CACHEについてもパスが通っているかどうかはっきりしません。たぶん失敗していると思います。

3.ページキャッシュ・dentry・inodeのクリア

crontab -e
0 * * * * sync; echo 3 > /proc/sys/vm/drop_caches

ディスク上のデータをメモリと同期させ、ページキャッシュ・dentry・inodeをまとめてクリアします。そのコマンドを使ってcronを使って毎時0分に定期実行します。

reduce_server_response_time_pagespeed_insights_5_4

このやり方でじわじわと増えていたslab_casheの容量を一気に減らすことに成功しました。

PageSpeed Insightの確認

slab_casheを解放することで、GoogleのPageSpeed Insightsにどれぐらい影響を与えることができるでしょうか。結果は以下の通りです。

モバイル

optimize_images_page_insights_2

パソコン

optimize_images_page_insights_3

残念ながらPageSpeed Insightによる評価は、EWWW Image Optimizerを活用したとき(新しいタブで開く)と比べ、モバイル・パソコンともにほとんど変化がみられませんでした。またGoogleが提案する最適化項目の一つである「サーバーの応答速度を速くする」という項目についても、その速度を改善することはできませんでした。