WordPressとRailsで遅くなったサーバーのメモリ状況を改善しようと見直した3つの項目

サーバーのメモリが逼迫して大変になった話

WordPressが動いているサーバーでRailsを動かしたらメモリを圧迫したみたい

周辺環境

まずはサーバーのスペックです。

  • CPU: 2コア
  • メモリ: 1GB
  • CentOS6.5

WordPressは、Apacheではなく、Nginx+PHP-FPMというお馴染み(?)の環境下で動かしてます。

  • Nginx
  • PHP-FPM
  • MySQL

それにこれをのっけてみました。

  • Rails
  • Unicorn
  • PostgreSQL

しばらくすると、今までの快適さがウソのように遅い、重い事案が発生。タイムアウトが頻発しました。
なるほど、これが噂のSWAPか。と、いうことで、諸々の設定を見直してみることにしました。

メモリを節約する必要にせまられてやった調整たち

PHP-FPM

色々と調べると、PHP-FPMは、設定である程度起動プロセス数を制限しておかないとメモリをバクバク食いつぶすという案件が結構発生しているようです。
早速、設定ファイルを開いてプロセスに制限をかけます。

/etc/php-fpm.d/www.conf

;'static'と'dynamic'
;staticはプロセス数を固定するので処理速度は高いがメモリを常に消費する。dynamicは状況に応じて変化。
;メモリが多く取れないのでdynamicに。
pm = dynamic

;起動できる最大プロセス数
pm.max_children = 10

;php-fpm初回起動時のプロセス数
pm.start_servers = 4

;待機状態時に起動しておくプロセス数
pm.min_spare_servers = 2
;待機時のプロセス数上限。この値を越えるプロセスは停止させられる。
pm.max_spare_servers = 6
;プロセスを再起動させるリクエスト数の設定。500回リクエストを受け付けたら再起動。
pm.max_requests = 500

Unicorn

Railsを動かすために用いてるUnicornも放っておくと徐々に肥大化していきます。 これは、定期的にunicornを再起動してくれる「unicorn-worker-killer」というGemを入れて対処しました。

github: unicorn-worker-killer
Unicorn-worker-killerが便利だった件

// Gemfile
gem 'unicorn-worker-killer'

MySQL

データベースはメモリをよく消費しますので、こちらも設定ファイルをいじりました。
バッファープールと呼ばれる、頻繁にアクセスされるデータを保持しておくメモリ領域の上限を指定やることでパフォーマンスが大きく変わるようです。

/etc/my.cnf

# バッファーをプールする領域のサイズを指定。この値が大きいほどパフォーマンスは上がる
inno_buffer_db_pool_size = 256M

# 大きくした方がパフォーマンスが上がる。
innodb_log_file_size = 64M

# 以下の設定は大きくしすぎない。大きくても4Mくらいまでか。
# インデックスを用いない時に使用されるメモリ領域
read_buffer_size = 1M

# ORDER BY や GROUP BYなどのソート時に使われるメモリ領域
sort_buffer_size = 1M

# ソート後のレコードがキャッシュされるメモリ領域
read_rnd_buffer_size = 2M

なお、inno_buffer_db_pool_sizeは、一度、128Mに設定してみたら、少なすぎたようでかなり遅かったです。

メモリに少し余裕ができたみたい

WordPressもRailsも順調

サーバーメモリ使用状況
快適に動くようになりました(いまのところ)。ただもうこれ以上は無理かな。。。
結論としては、ケチらずサーバー増やせ。と、いうところです。

(Visited 141 times, 1 visits today)

“WordPressとRailsで遅くなったサーバーのメモリ状況を改善しようと見直した3つの項目” への1件の返信

コメントは受け付けていません。