[AWS] WordPressが重い/遅い件への対策 [MySQL]
CPUを喰いツクしているのか、メティアクティア重い/遅い、WordPress@t2.micro@AWS(Amazon Web Services)。
月額250円のレンタル鯖(ロリポップ!のライトプラン)内にあるWordPress(普通に使える)より重いというか、重杉流wwwww
月額10円の鯖か!と思われるクライ(CRY)、激重である。
関連:重巡航管制機要撃 哀骸怨
最初はゴツ軽かッた(Calcutta)ンですが、タッタ数日で激重にw
WordPress@t2.microを用意→コンテンツをインポート→軽い!AWS最高!→(数日後)→激重→小林!
なンなン、コレ?
はヅかシ~で、生きてクァルェ変デwwwwwwwwww
WordPressの管理画面にも入れないので、記事を投稿するコトすら不可能wwwww
ローカルのメモ帳(大爆笑)に書くか(郭嘉)、手元のノートにエンピツで書いた方がマシwwwww
字も上達スルし、汚ヅィー惨のヴォケ防止にもイーンチャウン(茶運)?
# ネットに初期から触れてゐる、自称「情強」の上端は、スデに老境に入ッてル、2017年の秋ヅァル。
CPUクレジットも使い切ったので、バーストができず、10%以上のチカラを出セヅ、完全にオイコマレタ状態wwwww
関連:[AWS] CPUの使用率とCPUクレジットの消費と回復,有効期限 [T2インスタンス]
WP Super Cacheなどのキャッシュプラグインを入れると、静的ファイルが書き出され、毎度DBにアクセスするコトがなくなるので軽くなるのは知っているが、有効にしても重いか、逆に悪化するシマツwwwww
ンな小手先の対策ではダメのようだ。
で、WordPress@AWSが重い件で調べていると、メモリ不足のハナシが多い。
AWSのt2.microインスタンスのメモリ(RAM)は、下記の通り1GBである。
RAMが不足する上に、swap(スワップ,RAM不足時の退避先)がナイのでダメ!作れ!という情報があるので、鯖を調べてみる。
Tera Termで接続し、以下を実行。
grep Mem /proc/meminfo
grep Swap /proc/meminfo
結果…
メモリに(まだ)空きはあり、swapもある。
自力で環境を構築した場合はswapは作らないとないだろうが、アマゾンのチュートリアルに従ってBitNamiでインストールしたりすると、swapが自動で作成されるようだ。
なので、メモリには問題ないというコト。
やはりCPUに着手するしかない。
DBに問い合わせ→引き出しにCPUを喰うので、これを改良する。
<MySQLの設定を見直す>
FileZillaで接続し、以下を開く。
/opt/bitnami/mysql/bitnami/my-micro.cnf
(t2.micro and WordPress powered by BitNamiの場合)
<デフォルト状態>
[mysqld]
#wait_timeout = 120
long_query_time = 1
query_cache_limit=2M
query_cache_type=1
query_cache_size=8M
innodb_buffer_pool_size=16M
#innodb_log_file_size=128M
#tmp_table_size=64M
#max_connections = 2500
#max_user_connections = 2500
#innodb_flush_method=O_DIRECT
#key_buffer_size=64M
これを以下に書き換えて送る。
<変更後>
[mysqld]
#wait_timeout = 120
long_query_time = 1
query_cache_limit=8M
query_cache_type=1
query_cache_size=64M
innodb_buffer_pool_size=16M
#innodb_log_file_size=128M
#tmp_table_size=64M
#max_connections = 2500
#max_user_connections = 2500
#innodb_flush_method=O_DIRECT
#key_buffer_size=64M
そして再起動する。
AWSの管理画面(ダッシュボード)でインスタンスを選択して再起動してヤレばイーwww
再起動が終り、サイトが表示されることを確認したら、先の変更が反映されているかを、phpMyAdminで確認する。
phpMyAdmin(http://IP/phpmyadmin/)にアクセスしログイン、変数タブを選択し、フィルタに「query」と入れると、以下が確認できる。
query_cache_size=8M
query_cache_size=64M
となっているのが分かるだろう。
なお、この画面で、項目の左にある「編集」をクリックすると値を変更できるが、権限でエラーとなる。
で、この変更後、表示が速くなり(WordPressの管理画面も実投稿も問題ナシ)、大幅改善となったが、CloudWatchを見てみると…
ゐッたゐドーなッてシマウのカーッ!
<プラグインの見直し>
なお、プラグインが重いとかの対策であるが、P3(Plugin Performance Profiler)で調べても、重いプラグインはなく、P3自体が重いという、アレな結果にwww
コードを表示する「SyntaxHighlighter」が原因という情報もあったが、無効化しても重い。
<謎杉流点>
t2.microを2つ用意し、各々に別のサイトをWordPressで立ち上げてある。
立ち上げ手順は同じで、プラグインも同じ、異なるのは内容(コンテンツ)とドメインくらい。
だが、
・サイトA:アクセス多、負荷小
・サイトB:アクセス小、負荷大 ← 問題のサイト
というコトである。
サイトAのCPU使用率は4%程度なのに対して、サイトBは上述のアリサマ。
なンなン、コレ?
アクセスと逆とユーン(YUNE)は、どういうコト?
<今後>
上記対策後、30分くらい様子を見たが、十分に軽くなった。
テクァ、単にインスタンスを再起動したから軽くなった(=時期に重くなる)だけチャウン?
が、引き続きCPU使用率が20-30%前後と高く(ブースト状態)、CPUクレジットを常時喰いツクしている状態では、記事が増え、アクセスが増えるとアウトになるのは明白。
インスタンスの上位モデル(t2.smallやt2.medium、t2.large)に移行スルと、CPUのベースラインが増加、CPUクレジットの回復値増加、メモリ増加などで余裕が出るだろうが、
価格が格段に増加し、金銭(ゼニ,カネ)的にアウトである(笑)
EC2だけの金額は予期できるとしても、転送量/転送料が高すぎるので、オンデマンド(使った分だけ後払い)であっても、定額制でないAWSは危険杉流!
白黒ケータイの時にノートパソコンと接続して「モバイル通信や!」とか言ッてヨロコンでたら、翌月の請求にスィンだ小僧(コヅォー)の様ヤロ?セヤロ?
ムァ、アクセスの少ないサイトなのにCPU使用が多い点の解明が第一だが、ンなン面倒!という場合(ソレが普通)は、エックスサーバーなどの、定額制かつWordPressに最適化された鯖に移行した方がハヤいからw
転送料が含まれており、前払いの定額制なので、AWSの請求にドキ!土器!する、精神的な不安、ストレスからも解放される!
ミナサン、最高デスクァ~!最高ッ!!
サイトが重いと閲覧者が去るし(華堕魔猿氏)、検索エンジン(Googleなど)からも嫌われて来訪者激減、カネも名誉も全てを失い、神之國と運命を共にシテしまうサカイ、即時対応、即時移行や!
関連:AWSが1年間無料→軽く手を出す→請求にビビる!高い!!
関連:[AWS] CPUの使用率とCPUクレジットの消費と回復,有効期限 [T2インスタンス]
月額900円(税抜)から、高速・多機能・高安定レンタルサーバー『エックスサーバー』
さくらのレンタルサーバ スタンダードのお申込みはこちら(公式ページ)
WordPressを使うならロリポップ!簡単インストール完備で楽々スタート!
売り上げランキング: 15,083
技術評論社
売り上げランキング: 17,320
技術評論社
売り上げランキング: 213,095