リダイレクトするときにfile descriptor out of range: Permission denied
crontabにタスク書いたのに実行されなかったときのメモ。
エラー内容をコピペしてググっても全く出てこないので。
PHPで作ったタスクに
*/5 * * * /usr/bin/php test.php 12345>>/var/log/test.log 2>>/var/log/test_error.log
みたいな感じでcrontabに書いたんですが全く実行されませんでした。
ログとか確認しても何も出ないので何でかなーと思ってたんですが、これをこのままコピペして貼り付けたらエラーが出ました
$ /usr/bin/php test.php 12345>>/var/log/test.log 2>>/var/log/test_error.log file descriptor out of range: Permission denied
直訳すると範囲外の数字です的なエラーですね。
原因
標準ストリームのファイル記述子として認識された。
標準出力は1、標準エラー出力は2みたいな感じで12345もストリームと認識されたんだと思います。
解決法
引数とリダイレクトの間にスペースを入れる。
$ /usr/bin/php test.php 12345>>/var/log/test.log 2>>/var/log/test_error.log
これを
$ /usr/bin/php test.php 12345 >>/var/log/test.log 2>>/var/log/test_error.log
こうする。わかりづらいですね。
もしくは文字列とする
$ /usr/bin/php test.php "12345">>/var/log/test.log 2>>/var/log/test_error.log
文字列の場合はストリームのファイル記述子とは認識されませんでした。
9ヶ月で月間1000万PVにスケールするまでに躓いたこと
2月にベータ版を公開してから、9ヶ月（2014年11月）でPVが1000万を超えた記念。
サービスがスケールするにつれて、ググっても同じ悩みを持つ人が少なくなっていって問題解決に時間がかかった。
参考になるかは分からないけどメモ。
そんなの当たり前だろ！ってことも多いですが初めはそういうもんだということで。
お仕事で作ったサービスなのでサービス名は伏せときます。
時系列で躓いた点を上げていきます。まずはスペック
スペック
・クラウド ： AWS, さくらクラウド
・言語 ： PHP, javascript
・フレームワーク ： FulePHP
・Webサーバー ： Apache（EC2）
・DBサーバー ： Mysql（RDS）
・キャッシュサーバー： Redis（EC2）
俺スペック
・PHPer歴2年
・Linux歴2年
躓いたところ
画像の動的作成は非常に重い処理（2014年3月ごろ）
そんなに重い処理だとはつゆ知らず、URLに幅を指定してやれば動的に画像をリサイズする処理を入れてたんですが、すぐサーバー落ちました。
同時アクセス5くらいで落ちてましたｗ
対策：画像をアップロードするときにリサイズするようにした。
デザインが毎週コロコロ変わるとかで無ければアップロード時にリサイズした方がいいです。
計測してみたらHTMLをレンダリングするまでの時間が300ms位だったのに対し、画像1枚に300〜500ms（デカイ画像だと1秒）とかかかってた。
画像1枚の処理に、URLパースしてDB接続して色々計算してみたいな処理を全部終えるのと同じかそれ以上かかるわけです。
20枚画像あったら20倍ですよ、やばい。
webサーバー1台の限界（2014年4月ごろ）
この頃からグノシーさんとかに補足され始めてちらほらアクセスが集まって来ました。
それまではwebサーバー1台DBサーバー1台でやってて、アクセスが上がるたびに一回サービス止めてインスタンスを良い奴にして再起動みたいな事してました。
ですがある程度のスペックまで上げると、それ以上良いインスタンス使ってもアクセスが捌けなくなりました。
対策：負荷分散しました
このへんは4回に分けて記事書きました。
ネットワーク素人が、さくらクラウドで負荷分散構築した時のメモ１【準備編】 - なりせなるてず
転送量が多すぎる（2014年9月ごろ）
PHPなどの処理はAWSで、画像などの静的ファイルは転送量課金が無いさくらクラウドから配信していたのですが、アクセスが集まると画像だけ非常に遅く表示されるようになりました。
ISDNの古き良き時代を思い出させるサービスとして、これはこれでいいかという気の持ちようで居たのですが上司からダメ出しをくらいました。
さくらクラウドの標準ネットワーク速度は100Mbpsなのでそれをぶっちぎってたわけです。
対策：サーバーの追加と静的ファイルの圧縮
単純に1台サーバーを追加すれば200Mbpsになるので、サーバーを追加しました。
それでは根本的な解決ではないので、静的ファイルを圧縮しました。
javascriptとcssはGruntを使いminifyします。
静的な画像はPNGならtinypngで、JPEGはoptimizillaで極限まで圧縮しました。
転送量が3分の1位まで減りました。サーバー費も浮きますね。
瞬間的アクセスで落ちる（2014年11月ごろから現在）
これはまだ解決しきれてない問題ですが一応。
iPhoneアプリのユーザーが増えてきてアプリでPUSHを送ると瞬間的（5秒間位）に秒間100アクセス以上あり、いつもは秒間5〜10アクセス位なので当然捌ききれず2,3分サービスがほぼ停止状態に陥る。
対策：データの持たせ方の変更と、サーバーの追加
この問題には複数の原因がありました。
・原因1
瞬間的アクセスがあるとすぐにDBが息しなくなるので原因調査したらデータの持たせ方に問題がありました。
アクセス数をページ毎に持たせていたのですが、1ページ1レコードでした。
Update文を発行すると対象行はロックされます。秒間100アクセスなのでロック待ちの処理が大量発生しレスポンスが返ってこなかったのです。
アクセス数を1ページ30レコード位に増やし、ランダムでインクリメントし、表示時は足して表示するようにしました。
これでロック待ちの処理は30分の1になりました。
・原因2
タイムアウトまでの時間が短すぎました。
タイムアウトを5秒に設定していたので高負荷時はレスポンスを返せませんでした。
・原因3
単純にWebサーバーの力不足。
平常時の秒間5アクセス位に合わせてサーバーを建ててるので瞬間的なアクセスには耐えられません。
オートスケールでは秒単位のアクセス増加には間に合いません。
サーバーをずっと建てとけばいいんですが、サーバー費がガッツリかかるのでそれも出来ません。
ここの折り合いがつかず、まだ解決しきれてません。
おわりに
元々プログラマとしてしか仕事してなかったのでサーバー構築・管理は未だに分からない事だらけです。
月間1000万PVとか昔は信じられなかったですが、意外と一人でもなんとかなるもんですね
3ヶ月AWS使ってでハマったこと
EC2とRDSとElastiCache位しか使ってないのでそんなにありませんけども、一応メモ。
RDS
Storage TypeにGeneral Purpose (SSD)というのがあるが、これは気をつけたい。
これを選択した状態でAllocated Storageを100GB未満の数値にすると性能が著しく落ちる時があります。
青文字で書いてある部分に詳細が載っているですけどね。
英語分からないし、青文字で重要そうじゃないので読まずにハマっただけです、ハイ。
Redis on ElastiCache
リクエスト毎の性能差が凄いです。
これはRedisのせいみたいなんですが、EC2から同じデータをGETするのに早い時で10msec位、遅い時で200msec位でした。
AWS Redis on Elastic Cache のBenchmark をしてみた - tech.guitarrapc.cóm
上記の記事で非常に詳しくベンチマークされてて、とても参考になりました。
構造化データを追加したらGoogleさんがいっぱいクロールしてくれた
構造化データってのはschema.orgとかmicrodataとかってやつです。
リッチ スニペットと構造化データについて - ウェブマスター ツール ヘルプ
schema.org に関するよくある質問 - ウェブマスター ツール ヘルプ
色々小難しいことが書いてますが、僕は「HTMLに機械が理解出来る意味を持たせる」って言う風に認識してます。
例えば記事があったとして「このHTMLは記事だよー」って教えてあげることが出来ます。
実装
<div class="article"> <a href="/article/123"> <h1>記事のタイトル</h1> </a> <div class="article-body"> 記事の中身 </div> </div>
とても簡単ですが、こんな感じの記事があった場合
<div class="article-link" itemscope itemtype="http://schema.org/Article"> <a href="/article/123" itemprop="url"> <h1 itemprop="name">記事のタイトル</h1> </a> <div class="article-body" itemprop="articleBody"> 記事の中身 </div> </div>
こんな感じに追加します。
・itemscopeはスコープを定義します。divで定義しているので、このdivが閉じるまでがスコープです。
・itemtypeは何を表しているかを定義します。"http://schema.org/Article"を指定してるので記事であると言っています。
・itemscopeとitemtypeはセットで定義します。
・itempropはプロパティを定義します。リンクならurl、タイトルならname、記事の本文でアレばarticleBodyなどです。
詳しくはhttp://schema.org/を見てください。
どの位クロールしてくれたか
定義する前は１日辺り１万ページくらいのクロールだったのが、記事とかリンクとかに構造化データを定義して２日目くらいに９万ページくらいになりました。
Googleさんにいっぱい見られてる・・・しゅごぉい・・・！
実際のページの数は２万ページも無いので、重複でクロールされまくってるわけです。
おすすめ記事とか関連記事とかで同じ記事へのリンクを構造化データで定義してるので当然といえば当然ですが。
この後ずっと毎日９万ページクロールされたのか？というとそんなわけなく、ほぼ元通りに落ち着きました。
yum updateしたらtwitteroauthがエラーになる
CentOSでtwitteroauthを利用してる方は注意が必要かも。
これを書いてる時点で最新？のnss (3.16.1-7.el6_5)にアップデートすると、twitteroauthがエラーになります。
twitteroauthに限った話しじゃ無いと思いますが、調べてないのでとりあえず。
経緯
TwitterからAPIで検索するという処理が突然死んでて、原因調査してました。
Twitterの仕様変更か？とか最近話題になったTwiccaが弾かれるなど、色々想像しましたが、
実際にエラーメッセージを取得して見ると全然関係ないエラーが出てました
Problem with the SSL CA cert (path? access rights?)
調べてみるとnssってのが原因らしい。
TwitterのOAuthが動かなくなった件。curl_error()でキャッチすると Problem with the SSL CA cert (path? ...) と出る。これはTwitterの仕様変更ではなく、サーバのnss更新が原因。証明書を更新すると解決する。
— =^_^= まぉー (@iso800cc) 2014, 9月 27ことの始まりはBashの脆弱性です。
先週末にパッチが公開されてアップデートして安心！！って思ってたんですが、どうもまだ脆弱性が残ってたらしく、再びパッチが出てました。
そんでもっていつもどおり気にせず
# yum update
と、やっていました。
NSSの脆弱性
このアップデートを実行した時に実は別にNSS脆弱性に関するパッチも公開されており、それも一緒にアップデートしたのが原因でした。
cURLを実行するときにCentOSではOpenSSLの代わりにnssを使っているようで、そのせいでアップデートするとエラーになったのでした。
ただ修正方法が分からず、結局このへんを見てyumでアンドゥしました。
しかしこれだと公開済みの脆弱性を思いっきり放置してる状態なので大変危険です。
対策方法がわかったら追記します。
追記（2014/09/29 17:52）：
とてつもなくあっけないオチですが、アパッチをリスタートしたら大丈夫でした。
一応手順としては
$ sudo yum update
を実行したあと
$ sudo service httpd restart
これだけで正常に動きました。ハイ。
ただ、AWSでエラーが出た状態と同じインスタンスを立ち上げてみたら同じ現象は再現出来ませんでした。
俺の３時間は一体何だったのか・・・。
