ただつらつらと日記が書かれていくようです。

月: 2015年9月

WordPressのメモリー使用量上限値はデフォルトで256MBだった。

運用しているWordPressが吐き出すPHPのログに「PHP Fatal error: Allowed memory size of 268435456 bytes exhausted」みたいなエラーが出ていた。これが出ていたときには、管理画面が真っ白になっていた(遠い目)まぁ、256MBもメモリーを食ってる処理をどうにかしなきゃいけないとは思うけど、とりあえず、上限値を押し上げてみて動くようなら、それで乗り切ってしまおう…と思った(ま、ヒマが出来たら調べてみようかと)

何にも考えずにphp.iniをいじって「memory_limit = 512M」としてhttpdを再起動(Apache httpdとmod_phpで動いてる)を再起動してみたが、やはりどこかでメモリー制限がかかっているようで、php.iniの設定が有効にならない。で、仕方ないのでWordPressのソースコードを読んでみたり、プラグインのソースをチェックしたりぐぐってみたりしているうちに、「WP_MAX_MEMORY_LIMIT」って定数の存在に気がついた。→詳細はこちら

要するに、WordPressはデフォルトでメモリー使用量上限値を設定していて、そのデフォルトが256MBらしい。普通は、この上限値で問題ないと言われれば確かにそうだろうなぁと思うが、php.iniで設定しても反映されなかったときはプラグインのどれかで設定しているのかなぁ…と調べてしまった(All in One SEO Packは制限値を変更できる機能がありそうだったが、デフォルトは256MBだった)

というわけで、wp-config.phpにて「define( ‘WP_MAX_MEMORY_LIMIT’, ‘512M’ );」と追記したら、メモリーを使い切った系のエラーは出力されなくなった。とりあえず、一件落着ということで…原因調査はそのうちに…。

nginxがHTTP/2に対応したらしいので…

どうやらnginx1.9.5でHTTP/2に対応したらしい。→「Nginx 1.9.5登場 – HTTP/2モジュール搭載

このサイトのnginxをバージョンアップするついでにHTTP/2に対応させてみた。このサイトではSPDYに対応させていたので、まずはnginxのconfigureオプションから「–with-http_spdy_module」を削除した(nginx1.9.5からSPDYモジュールは削除されたらしいので)。その上で、オプションに「–with-http_v2_module」を追加。あとのオプションはそのままでビルドしてみた。

nginx1.9.5をインストールして再起動する前に、nginx.confを修正。spdyを有効にしてあったが、もうSPDYモジュールはいないのでspdyの記載を削除して、代わりにhttp2を追加した。

listen 443 default spdy ssl;

listen 443 default http2 ssl;

あとは、nginxを再起動してみたら、HTTP/2が有効になっていた…はずだがブラウザで表示させただけではわからないので、Chromeに「HTTP/2 and SPDY indicator」ってChrome拡張をインストールしてみたら、アドレスバーの脇にブルーの稲妻が表示されていたのでHTTP/2で通信しているんだろうってことで。…なんかWordPressのレスポンスが早くなった気がするようなしないような…(遠い目)

追記:
nginxのバージョンアップをした後で、nginxの「ngx_http_v2_module」モジュールのページを見てみると、パラメータがいくつか設定できるらしいので、あとで設定を追加してみようかなぁと。

aws cliで大きなファイルをS3にアップロードしようとしたらコケた

とあるサーバのバックアップデータをS3に格納しておこうと思って、サーバにAWS CLIをインストールした。

データをtarで固めて、「aws s3 cp –region ap-northeast-1 test.gz s3://(バケット名)/」みたいな感じでアップロードしようとしたら無慈悲にも下記のようなエラーメッセージが出て、何回もアップロードに失敗した。どうやら、大きいファイルは分割してアップロードするが、その欠片のアップロードがどこかでコケるらしい。数GBくらいはある大きなデータではあるけれど、S3のファイルサイズ制限はテラバイトオーダーなので、数GBくらいのfairは問題なくアップロード出来るはずだ。

upload failed: ./test.gz to s3://(バケット名)/test.gz
Unable to parse response (syntax error: line 1, column 0), invalid XML received:
x-amz-id-2: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
x-amz-request-id: XXXXXXXXXXXXXXXXXX
Date: Tue, 15 Sep 2015 10:35:40 GMT
ETag: “XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx”
x-amz-storage-class: REDUCED_REDUNDANCY
Content-Length: 0
Server: AmazonS3

エラーをざっくりと読む限りは、S3のサーバから不正なXMLが返っていてParseに失敗しているけれど、AWS CLIを使っているだけの私にとっては謎すぎて手が出ないので、途方に暮れていた。ふと気付いたのは、他の環境では同じくらいのサイズのファイルのアップロードに成功していて、AWS CLIのバージョンが1.8.2であること。…というわけで、失敗している環境のAWS CLIのバージョンを戻して、成功している環境と同じバージョンにしてみた。

# pip install awscli==1.8.2

バージョンを戻してみたところ、問題なくアップロードできてしまった。AWS CLIのリリースノートを見てみたけど、それっぽい記述もなくて…なかなか悩ましい。