ただのにっき。

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

11ページ目 (40ページ中)

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のリリースノートを見てみたけど、それっぽい記述もなくて…なかなか悩ましい。

Linode TokyoにはKVMが来ていない

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のサーバが設置されることを首を長くして待っておこう。

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

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

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

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

ちょっと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:

Eclipse自体のアップデートのダウンロードが遅いとき

Eclipseのアップデートをインストールしようと思ったら、download.eclipse.orgが…遅い。なんとなく、アメリカのどこかにありそうなサーバなのでネットワークのレイテンシーが大きそうなのと、さすがにEclipseの更新となるとデータが大きいせいか重い。

まぁ、そんなわけで、国内のサーバを参照するように設定を変えてみた。Eclipseに登録してあるレポジトリを更新する必要があるので、「ヘルプ」から「新規ソフトウェアのインストール」をクリックして、「使用可能なソフトウェア・サイト」を開くと、ずらっとレポジトリが出てくるので、そこのURLを山形大学とかJAISTとか、国内でEclipseのレポジトリをミラーしているサーバーを参照するようにすると、ファイルのダウンロードがかなり速くなった。

…と、この辺のグローバルでの負荷分散がデフォルトで実現するのは、Eclipseクラスのプロダクトでも難しいものだろうか。いやはや。

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

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の接続情報を作成する必要があるらしく…。うーむ、かなりややこしい。

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

ちょっと安いからっていろんな拠点に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への移行を試みる予定。いやはや…なかなか面倒だな。

CloudSearchのインスタンスとか

AWSのCloudSearchを使ってみているけれども、これで使われているインスタンスって、m1.smallとかm3.mediumなんだよなぁ。どうせなら、コストパフォーマンスよさげなt2インスタンスとか使えるようにならないかなぁと思うけど、t2インスタンスのCPUクレジットを使い切って性能がガクッと落ちたら切ないか。うん、それは切ない。…みたいなアホなエントリーを書いているけれど、一向にindexingが終わらない…。うーむ、とりあえず安いsearch.m1.smallインスタンスだと、何やらせても時間かかるなぁ(遠い目)

«過去の 投稿 新しい 投稿 »