PageSpeed Insights の最適化提案 「サーバーの応答時間を短縮する」について解決する 〜 その4(ディスクの拡張でメモリのswapとslab_casheが減少)

reduce_server_response_time_page_insights_0

スケールアップした「さくらのVPS 512MB → 2GB」をMuninで引き続き監視すると、Memory usageの”swap(赤)”と”slab_cashe(黄)”が肥大化していることが分かります。これらが肥大化する原因は分かりませんが、ディスクの拡張をすることによって抑えることに成功しました。

目次

仮想ディスク容量の認識について

さくらのVPSでは「スケールアップ機能」を使うとメモリとCPUは自動でスケールアップされます。ただし増量した仮想ディスク容量(SSD 20GB → SSD 50GB)をOSに認識させるためには、ユーザーが自分で作業をする必要があります。

必要なパッケージ(gdisk)をインストール
↓
ディスクの状態を確認
↓
パーティションをソート
↓
新しいパーティションを作成
↓
ファイルシステムの作成
↓
新しいディスクをマウント
↓
サーバの再起動

作業内容はおおむね上記の通りです。詳しいコマンドについては、さくらインターネットのページが参考にしましょう。

dfコマンドによるディスクの確認

reduce_server_response_time_pagespeed_insights_4

dfコマンドを使うと仮想ディスク容量は/dev/vda5で認識され、30GB分(50GB – 20GB)が増量されたことが分かります。なお増量したディスクにWordPressのファイルやデータベースなどの圧縮ファイルを保存したい場合、以下のディレクトリに保存します。

# pwd
/data

これはディスクの増量に伴い”/data”というディレクトリが、30GB分のディレクトリとして認識されたためです。「さくらのVPS」でディスクを増量した場合、”/”に新しいディレクトリが追加されていくというイメージになるのでしょう。

Memory Usageの確認

reduce_server_response_time_pagespeed_insights_4

MuninのMemory Usageを確認すると、肥大化していた”swap(赤)”と”slab_cashe(黄)”が抑えられたことが分かります。

なお、slab_cacheとはinodeやdentryなどカーネルが使うメモリを指します。このうちdentryはファイル名やディレクトリ階層構造の管理をしているキャッシュです。もしメモリ確保とメモリ解放が繰り返して発生すると、dentryはメモリを圧迫する要因になります。したがってslab_casheの領域は小さい方が良いと考えられます。

PageSpeed Insightの確認

モバイル

optimize_images_page_insights_2

パソコン

optimize_images_page_insights_3

PageSpeed Insightによる評価は、EWWW Image Optimizerを活用したときと比べ、モバイル・パソコンともにほとんど変化がみられませんでした。

MySQLの再起動について

以降はサーバーの運用状況によってまちまちですが、個人的にMySQLの運用で困ったことが発生したので追記しておきます。

エコテキブログではシェルスクリプトを使って、WordPressとそのデータベースを圧縮してバックアップを行なっています。仮想ディスクの容量が増加されるにともなって、圧縮ファイルも引き続きcrontabで設定した時刻にバックアップが実行されると思います。

# /usr/local/bin/backup.sh
tar: メンバ名から先頭の `/' を取り除きます

gzip: stdout: No space left on device
[ERROR]tar error.
Warning: Using a password on the command line interface can be insecure.
mysqldump: Error: 'Got error 28 from storage engine' when trying to dump tablespaces
mysqldump: Couldn't execute 'show fields from `wp_blc_filters`': Got error 28 from storage engine (1030)

gzip: stdout: No space left on device
[ERROR]mysqldump error.
e-yotafile_20180728-113941.tar.gz                                                  100% 1592MB   2.7MB/s   09:52    
e-yotadb_20180728-113941.sql.gz                                                    100%    0     0.0KB/s   00:00   

ですが自分の場合、そうならず手動で実行するとエラーが発生します。WordPressのファイル群は圧縮されてバックアップされるものの、データベースの圧縮ファイルは作成されません。

# systemctl restart mysqld.service

で、解決方法ですがMySQLを再起動させました。MySQLを再起動させると、なぜ圧縮ファイルが作成されてバックアップできるかは分かりません。「仮想ディスクの増量を認識させたに関わらずデータベースの圧縮ファイルが作成できない、バックアップができない」と困っている方の参考になれば幸いです。

reduce_server_response_time_page_insights_0

この記事が気に入ったら
フォローしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次