カテゴリー: ITめいたこと (11ページ目 (32ページ中))

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

2015年9月30日 / 管理人 / 1件のコメント

運用している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に対応したらしいので…

2015年9月25日 / 管理人 / 0件のコメント

どうやら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にアップロードしようとしたらコケた

2015年9月15日 / 管理人 / 0件のコメント

とあるサーバのバックアップデータを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のリリースノートを見てみたけど、それっぽい記述もなくて…なかなか悩ましい。

Linode TokyoにはKVMが来ていない

2015年8月14日 / 管理人 / 0件のコメント

Linodeのブログを読んでいたら、こんな記事があった。「Linode turns 12! Here’s some KVM!」

To celebrate, we’re kicking off the next phase of Linode’s transition from Xen to KVM by making KVM Linodes generally available, starting today.

どうやら、Linodeが仮想化基盤をXenからKVMに切り替えるらしい。KVMだと準仮想化ドライバが使えるようになるけど、一旦は完全仮想化から始めるらしい。とはいえ、起動とか速くなるぜとのことではあったんだけど。

いざ、XenのLinodeをKVMに切り替えるためにはダッシュボードからクリックするだけで…と書いてあるけれど、dashboardにそんなリンクが見当たらない。んで、試しにカリフォルニアのfremontで動かしてるLinodeのDashboardを覗いてみると…そのリンクが出てきた。ということは、Linode TokyoではKVMが使えないのかも…と思ったけれど、ブログの記事にはそんなこと書いてないのでどうなっているんだろうと思っていたが、forumを覗いてみたら、こんな記事があった。「Linode KVM (beta)」んで、そこにはこんな記載があった…。

The Linode KVM beta is now in all DCs except for Tokyo.

まぁ、つまるところ、Betaリリースしてたときから、TokyoにはKVMのサーバが用意されていなかったようだ。そりゃ、本番投入もないだろうなぁ…いやはや。Tokyoのラックは値段が高いから、なかなか余剰なサーバ(ユーザーのクリックをトリガーによって移行を可能にさせるなら、ある程度の余剰サーバを設置するしかなさそうだし、設備の稼働率の低下は覚悟しなきゃならないだろうな)を突っ込んでおくのが難しいってことだろうか。

そのうち、TokyoにもKVMのサーバが設置されることを首を長くして待っておこう。

シンガポールが遠かった…。

2015年8月14日 / 管理人 / 0件のコメント

うーむ、やっぱり東京からはシンガポールよりカリフォルニアの方が近かったか…。

東京からシンガポールのLinodeまでのpingのRTTが270msくらい。んで、東京からカリフォルニアのサンノゼ近くのfremont(たぶんHurricane Electricだな)のLinodeまでのpingのRTTが170msほど。日本からアジア各国向けの海底ケーブルが増設されているとは思うけど、日米間の海底ケーブルに比べるとまだまだ規模が小さいんだろうか…。それともネットワーク的に迂回しているとかか。それとも、シンガポールのLinodeのネットワークが混んでるとか…？うーむ。

ec2のt2.microインスタンスを起動してみたら。

2015年7月8日 / 管理人 / 0件のコメント

ちょっとt2.microインスタンスを起動してみたら、「Intel(R) Xeon(R) CPU E5-2676 v3」でインスタンスが起動してきた。これって、m4インスタンスに導入されたAWS特注のCPUじゃなかったっけ…。

うーむ、t2インスタンスって、いろんな物理サーバで起動するんだろうか、ということで。

[ec2-user@ip-XX-XX-XX-XX ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz
stepping : 2
microcode : 0x25
cpu MHz : 2394.542
cache size : 30720 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm xsaveopt fsgsbase bmi1 avx2 smep bmi2 erms invpcid
bogomips : 4789.08
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:

64bitなWindowsで動くAccessからODBCでMySQLに接続するとか

2015年6月5日 / 管理人 / 0件のコメント

64bitなWindowsの上で動く、Office2013のAccessからMySQLにODBCで接続したいときに、ODBCドライバーをどうしたらいいもんだろうかということで、ちょっと調べてみたのでメモ。

結論から書けば、Accessは32bitなアプリケーション(もしかして、64bitなOfficeって…どっかでダウンロードできるんだろうか)なので、ODBCドライバーは32bitのものが必要。…ま、そりゃ当然か。ただし、32bitなODBCドライバーを入れても、コンパネの管理ツールの中にある「データソース(ODBC)」からは、32bitなODBCドライバーに対する設定はできないようだ。実際、確認してみたが、インストールしたはずなのに、MySQLのODBCドライバーが見えない。

…ひっそりと、32bitなODBCドライバー向けの設定プログラム(odbcad32.exe)が「C:\Windows\SysWOW64」に隠されているので、それを使って接続したいMySQLの接続情報を作成する必要があるらしく…。うーむ、かなりややこしい。

MySQL ODBCが接続できない！？Windows7 64bitの落とし穴?

livedoorプロバイダ、サービス終了…

2015年4月1日 / 管理人 / 0件のコメント

ちょっと安いからっていろんな拠点にlivedoorプロバイダを導入しまくって、VPNを張って喜んで早2年。さすがに儲からないのか、サービス終了のお知らせがエイプリルフールに…。

【重要なお知らせ】livedoorプロバイダサービス終了のお知らせ:
http://blog.livedoor.jp/connect_staff/archives/1804038.html

誠に勝手ながら本サービスは、2015年6月30日をもちましてサービスを終了させていただくこととなりました。ご利用のお客様には大変ご迷惑をお掛けしますが、何卒ご理解の程よろしくお願い致します。長きにわたりlivedoorプロバイダをご愛顧いただき誠にありがとうございました。

今回終了する、このサービスのユーザーを救済するのは、livedoorプロバイダサービスのバックボーンのVectant系のQitってサービスらしいんだけど…サービス終了が6月末で、救済サービスの申し込みが6月アタマからってなかなかドキドキするので、Interlinkとか別の固定IPくれるISPへの移行を試みる予定。いやはや…なかなか面倒だな。

zabbixでphp-fpmを監視するためのテンプレートがあった。

2015年2月10日 / 管理人 / 0件のコメント

zabbixのagentでphp-fpmの監視をどうするかなぁと思ったけど、Google先生に聞いてみたら、テンプレートがあった。php-fpmでステータスを吐き出させるようにしておいて、zabbixエージェントとphp-fpmのステータス表示をつなげるシェルを置いておく、という方式のようで。

Template php-fpm：
https://github.com/jizhang/zabbix-templates/tree/master/php-fpm

サイト全体をSSL化してみた。

2015年2月6日 / 管理人 / 0件のコメント

SPDYに対応させるとどうなるか試してみたかったので、このサイトのコモンネームでSSL証明書を買ってきて、nginxのspdyモジュールを使ってspdyを利用可能にしてみた。

ブラウザにSPDY Indicatorとかのアドオンを入れると、SPDYを使っていることが確認できる。まぁ、このサーバは米国の西海岸にある物理サーバで動いているVPSなので、通信部分のレイテンシーが大きいせいか、「多少は早くなったかなぁ…」という印象。まぁ、いっか(遠い目)

WordPressをSSL化するときには、とりあえず、「設定」から「一般」を開いて、「WordPress アドレス (URL)」と「サイトアドレス (URL)」のsheme部分をhttpsに変更すると基本的には対応が完了しそうな雰囲気ではあるけれど、過去に貼っちゃった画像なんかはhttpで参照されそう。うーむ、まぁ、SSL化は最初からやった方がいいんだなと思いつつも、WordPressもschemeなしのURLで画像のURLを書いておいてもらえると便利なんだけどなぁと。

あとは、nginxでHSTSを返すようにしてみた。検索エンジンなんかも、HSTSを参照してSSLで参照してくれたりするんだろうか。ちょっと試してみるか。