いろいろメール送ったりしてみました。
結局、materiaの動作があまりにも奇怪なバグを含む、ということで、シンクロナイズドセクション中の挙動については、旧SSP仕様にて統一する方向になりそうです。(CROW・SSP)
つまり、ボトルに関係するところでは、
\0\_s\1\_sあ」で、\1側が「あ」と喋る。という仕様になります。(結局SSSBやS-Vの現仕様と同一)
ただ、既存のCROWは\1や\0でシンクロナイズドセクションが終了する仕様でした。また既存の偽林檎ではサーフィス変更はシンクロナイズドセクションの適用を受けない仕様になってましたし、materiaではシンクロナイズドセクション終了後のスコープが全く不定である、というバグが存在していました。
しかし結局、materiaの内部のコードがどうなっているのかさっぱり分からないですね(汗)
この辺が一応の解決を見そうだ、ということで、新ボトルクライアントの公開もできそうです。機能的にはあんまり変わってませんが…(見た目のアイコンだけ)
materiaの場合はいろいろバグがあって、それの修正もあまり望めない感じなので、「\_s中でサーフィスを切り替えてもいいが、スコープを切り替えてはいけない(それやったとたんにいろいろ不可解な挙動をする)」というのがレギュレーションになりそう。まぁ上記の仕様で望んでそんなことをする人がいるとは思えませんが。
\t\u\s[10]\h\s[6]シンクロナイズドセッションの話、勿体無いような気がするのう。\w9\w9\n\uなにが勿体無いんや？\w9\w9\n\h\n表情独立して変えられるほうが、表現能力としては上やろ。\w9\w9\n\u\nむぅ･･･\w9\w9\e
これは、\_sの中では常に独立サーフィス指定可能にするべき、ということでしょうか。\_sの中で\1や\0が来た場合のみ独立指定も可能にするべき、ということでしょうか。
前者なら、結局、そういう動作で実装していた処理系は過去に偽林檎(と古いS-V)しか存在しなかったということで…。後者なら、そういう実装を考えていた処理系は結局1つもなかったことになります(materiaはバグで偶然そういう仕様に見えていただけ)。
プログラム組む方としては、「セリフはシンクロ・サーフィスシンクロ状態」「セリフはシンクロ・サーフィス独立変更状態」とかいうのを分けて考える実装しないといけないのは、それだけのために追加フラグ1個必要なので結構イヤだったりもします。スコープが2種類あるみたいですっきりしないですし。
まぁこの辺はmateriaの仕様に合わせるのが鉄則になっちゃってるので、ちょっと変えられないかも…
…と、そんな感じの言い訳で。
AとCが混同されると話が全然分からなくなるので、とりあえず上のように名前付けておきます。(この2週間でSSPやCROWやらでいろいろ変わりましたが、まぁそれ以前のそれぞれの伝統的な仕様で分類)
\t\u\s[10]\h\s[4]\_sシンクロセッションっちゅうのは、本来同じせりふを同期して喋らせるのが目的なんやから、\w9本来サーフィスの表示とは独立しているべきもんやろな。\n\w9\w9materiaで妙なことになってるのは、\w9おそらく実装上いったんサーフィス指定まで含めてシンクロしてしまったのを、\w9スコープ指定の直後だけ解除して切り抜けようとしたためやろ？\n\w9\w9サーフィス･･･\_s\u\n\s[11]メモの更新がきたで。\w9\w9\h\s[6]\n･･･\w9\s[4]\_s\n･･･要するに、\w9サーフィスのシンクロってのは、本来の目的ではないと思うんや。\w9いわば、こっちが～\w9サーフィスまで同期するのが～\w9バグや。\w9１本のスクリプトに書かなならん仕様上どうしょうもないんやけど、\w9本来、\w9\\h、\\u別のキャラクターなんやから、\w9同時に喋る時だけサーフィス変更できん。変えると同じサーフィスしか出なくなるのは可笑しいやろ。\w9\w9\w9\n新たに仕様をまとめようとするなら、\w9実装側の都合やなくて、\w9表現する者にとっての都合を考えたほうがエエ思うね。\w9その辺、偽補完さくらにもう言われとるけど･･･\w9\_s\u\s[11]\n\n長いわっ！！\n\w9長ゼリフは独りで喋らんかい！\w9\w9\e
仮にこの意見の前半部が正しい場合、「materiaの基本思想はサーフィスをシンクロしないことだ」ということになって、今までの前提が全部ひっくり返ってA案になると思います。
でも、materiaが「おそらく実装上いったんサーフィス指定まで含めてシンクロしてしまったのを、スコープ指定の直後だけ解除して切り抜けようとした」に関しては、「\_sあ\hい」というスクリプトのバグを見た限り、「それは違う」と言っていいと思います。いくら想像を絶する実装をする人だといっても、そういうつもりで、スコープ直後を無視するコードを意図的に入れたのなら、\sタグかどうかくらい判別するに決まっているので。
そもそも 「\_s\s[1]あ\_s」という一番シンプルなスクリプトにおいて、materiaでは分身は発生します(分身がおこらないのは、それこそセリフ本体すら正しく扱えない、妙なバグの部分だけです)
以上から、「materiaの基本動作は、サーフィスもシンクロすることだ」というのは間違いがないと思います。
…という時点でほぼ最終的な結論については決まってしまう気もするんですが、勿論、「偽林檎仕様」である、「\_s内であろうとなかろうと、一切同時にサーフィスが変わる、なんていう動作は認めない」というA案方式は、同じくらいシンプルで、同じくらい説得力のある、同じくらい誤解の発生する可能性の少ない仕様だ、とは思っています(materiaがそうなっていない、というのが結局一番大きいわけで)
でも結局、どどめうにゅうさんの主張としては、AでもなくBでもなく、「materiaはこの際無視して、ややこしいけど、分かってしまえばAのようにもBのようにも使用できる、C案というものを新たに実装して欲しい」ということでしょうか。それとも、「\_s中でサーフィスが変わってしまうのは既にすべからくバグなので、A案に統一しよう」とうことでしょうか。
ちなみにスクリプトが少々短くて済む、とか、そういう話は、僕は今のところ全然考えていません。まぁ意図的に分身したいならB案が短くなる(例えばhttp://bottle.mikage.to/viewlog2.cgi?around=3eb6587c00000001)でしょうし、あくまでキャラごとにサーフィス変えたいならA案が短くなるのは明らかで、C案は「\_s中の\1や\0に特別な意味を持たせる」ことで、どっちでもある程度短くできます…が。
さっきのグレイスフルは、DoS攻撃に繋がりかねないちょっと不安なものだったので調査します。とりあえずそれだけ…
ごめんなさい何度も。前後しますが、同意が10も来てるのでこれ
\t\h\s[0]そもそもシンクロ中にsurface指定するなんて状況は想定されてないと思われ。\u\s[10]\w9恐らくは短文で使用されることを想定しとるやろからな。\e
とりあえず、本当に全く想定してないならどっちかが切り替わって終わるわけで、「materiaで分身ができる」＝「materiaもシンクロナイズドセクション中にサーフィス指定がやってくる想定はしている」ということだと思います。9割方。基本的には、敢えて組まなきゃ、同時にサーフィスが変わる、なんてことはやれません。
もちろん、設計当初からシンクロナイズドセクションを考慮して、CROWのような抽象的なプログラミングをしていれば「偶然(バグで)分身してしまった」ということが起きえるとは思います。でも、シンクロセクション中で喋るセリフが交錯するようなバグが存在しているということは、つまり\0側\1側が分離しきっていないわけで。それにバグで想定外に分身するデザインを採用しているのなら、それこそバグで「\w9」で2倍分ウェイトする、とか、バグで選択肢が両方のバルーンに出てハングする、とか、そんなのが出ても不思議ではないですが、何だかんだでそういうのはなく、その辺考慮しながら作っていく中で、いずれにせよ「セリフと\sはシンクロする」という意識はどこかで必要です。
その他、あの人の文字列処理関係のバグや対処法をいろいろ見てきた「勘」も含めて、「materiaは、現状の動作、という意味でも、作者がそれを意図していたかどうか、という意味でも、分身が発生するように作られている」のだと、自分には思えます。
\t\u\s[10]\h\s[4]やっぱり答えなならん？\w9\w9\u言いっ放しのつもりやったんか？\w9\w9\n\h\nまぁ、いまさら言ってもしょーないような気もするんやけど、理念としてはＡ案、\w9そのための仕様としてはＣ案ってことやろか。\w9\w9\n\u\n\s[11]また中途半端なこと言う気やないやろな。\w9\w9\n\h\n\c\_qセリフの同期の要求とサーフィス変更は独立。いっしょの喋りの間にも、\\u,\\hそれぞれ異なるサーフィス・姿態の再生をしたい。これは決して異常な要求ではないからエラーにすべきでない。この要求を満たすために、シンクロ中の\\s指定についてスコープ制御が必要。つまり \\0, \\1 により、直後の\\sのスコープを指定する。それ以外の\\0, \\1 の使用は想定外と思うが、直後の１文字についても同様の制御は可能だろう。サーフィスのシンクロにはあまり意義を感じないが、 \\0,\\1による指定が無い以上、両スコープを選択中という解釈が自然。\_q\u\c\w9\w9･･･ってあたりやな。\w9\n\nワイのバルーン勝手に使うんやない！\w9\w9\w9\w9\e
どうやら、「\_s中の\1とかの直後の1文字」というのに意味を見いだしているみたいですが…。「\u\_sあ\hいう」を試してみましたか? これで、\u側は「あう」だけ喋って、\h側は「あいいう」と、「い」を繰り返して喋ります。これは、「\u直後の1パース分だけを指定されたスコープに変える、エスケープみたいな意味がある指定」ではなく、単純に「\u直後の1パース分は、指定されたスコープ側で2回繰り返されてしまうというバグ」と解釈するほうが自然かと。
もちろんmateriaのそういう挙動と全く関係なく、「セリフを同時に喋りながらキャラクタは別々にサーフィスが変わっていく、という自然な流れについての要求を、短いバイト数で表現したい」という要求がある、という話は理解できますし、理想論としての「シンクロナイズドセッションがこうあるべきだ」という話はだいたい分かります。
ただそのための6バイトの節約が、現行のSSTP関連プログラムを全部変えて行かなきゃいけないコストや、それによってmateriaと違う動作を敢えて全員で実装していく、というリスク(自分はともかく、SSPやCROWにとっては相当なコストなんだと想像)、さらにはA案はともかくC案になった場合の実装や理解の複雑さというリスク、に、見合うだけのものなのか、といった部分から検討したときにどうなるか、という。
\t\h\s[0]サーフェイスがどう処理されてるのかわからんからあれやけど。\u\s[10]\w9メモにここで反応すんなや。\h\w9\nわざわざ分身させるﾙｰﾁｿを書いておいて、\\h、\\uが来た時におかしな動きするっちゅーのは明らかに片手落ちやと思うねや。\n\w9\\h、\\uがオブジェクトでそれぞれサーフェイス変更を自分自身でやっとるとすれば分身するのは仕様ってことになる。\n\w6\\h、\\uも恐らくフラグで処理されてることを考えると、if文追加で済むしな。\u\w9\n厨房プログラマやな、藻前。\h\w9\n\\h、\\u、\\_sがフラグ処理だと考えると、なぜシンクロ終了後にフォーカスが移動するのかが説明できんのやが‥\w9‥\w9\e
はっきり言ってこの辺のmateriaの実際のソースコードはさっぱり想像できません。ただ、\hと\uが別のオブジェクトとして等しくサーフィス変更命令を受け取っている、という構造(さっき「抽象的」と表現した)で「ない」可能性は非常に高いような。バグの出方からして。
ちなみに
\t\u\_s\s[4]\e
\t\h\_s\s[4]\e
\t\u\_s\s[4]あ\e
\t\h\_s\s[4]あ\e
これら4つのスクリプトをmateriaで実行してみると、これも何が起こっているのか予想できないことが起こります。
うちのクライアントの設定↓
ゴーストが 「空」 か 「びい」 か 「裏子」 のとき「DEBUG」タブにログを残す。さらにこれ以降の1個のルールの処理をスキップする。
スクリプト文字列に 「\_qデバッグ」 か 「SSSB」 か 「SSP」 か 「CROW」 か 「materia」 か 「クライアント」 か 「Client」 か 「TalkShow」 か 「TSG」 か 「SVG」 か 「SSTPViewer」 か 「SSTP-Viewer」 か 「S-V」 か 「ToDo」 か 「なるはん」 か 「なるさん」 か 「SDH」 か 「SAR」 が含まれているとき「DEBUG」タブにログを残す。
…。
\t\u\s[10]\h\s[5]期待されてた？\w9\w9\uはあ･･･\w9\w9\n\h\s[6]\nそれじゃ、これが最後の記録。\w9\w9\n20:23 06/01 106,716 194 173,088 13865\u\nさすがに限界ですね。\w9\w9OS、XPの問題のような気もするんですけど･･･\n\h\s[3]\nでも、機種の違う2台とも同じ挙動だからねー。\w9\w9\e
一応、ボトルのログ1本に割り当てられるメモリは、せいぜい平均1K行かないくらいなので、1万本のボトルをためていたとしても、10MB程度のはずです、本来。100MB行くことはないはずですし、実際に過去ログダウンロードで1万本ダウンロードしてきたら、10MBもいかないでしょう。(ただしログ用に記憶されているのと配送バッファ用のは完全に別なので、例えばスリープしっぱなし状態で1万本ためたなら、その2倍は行きます)
今回のテストにつかっていたという2.56には、「配送バッファから取り出しておきながら、配送先が見つからなかったボトルを解放し忘れる」という問題があります。これが結構酷いやつで、2秒ごとにボトル1本分のメモリリークが起こります。2Kの長文ボトルが再生待ちになっている状況で、ゴーストを立ち上げないままに1時間放置していたら、2KB x 1800回で、3.6MB以上のリークが生じることに。
…ってこれでも説明つかないか、100MB以上、となると。
プラグイン関係も画像たくさん扱うので疑わしいんですが、とりあえずこちらでは、TSG.dll、SVG.dll、sss.dllの最新版をそれぞれ入れた状態で、24時間分のスクリプトをずらーっと順番に表示させてみて、コンスタントにメモリを食いつぶしていくような雰囲気は見られませんでした。
というわけでこれ以上どうしようもないので、かな～り大きいですがテスト版クライアント
終了時に、ボトルクライアントが解放し忘れているメモリを指摘してくれます。XMLロード時に凄まじいリークが生じているのが見え見えなのでちょっと恥ずかしい版。あと、タスクトレイ関係で88バイト常に漏れてますが、まぁこれはどうせプロセス終了時に解放されるので、とりあえずは害はないということで(気持ち悪いので何とかしたいですが)。
\t\u\s[10]いつのまにか、メモが更新されてましたね。\w9\h\s[3]えっと･･･\w9\w9\_qデバッグ\_qでいいのかな？\w8\w8\n\u\n先頭でなくていいんですか？\w9\w9\n\h\s[0]Clientの設定なんだけど、プラグインの類はいっさい入ってなくて、\w9スリープ状態でもないんだよね。\w9\w9全部、SSSBで再生状態で放置。\w9\n過去ログのダウンロードはなし、もしくは1日分まで。\w9共通してるアクションは、評価順に\nカレントログタブ、チャネルごとログ、非存在ゴーストタブ、特定ゴーストのときメッセージ転送無し。\w9\w9\n\u\n何も特別なことはしていないと思うんですが、かえって謎ですね。\w9\w9\e
今のところは、全く謎です。
とりあえず、設定やアクションの微妙な違いでおかしくなっている場合には、上のテスト版で起動してみて、10分ほどいろいろ受信してみた後に終了して、出てきた怪しいテキストファイル(MemCheck.log)を見せて頂けると、何か掴めるかもしれません。
ちなみにうちのところは、少なくともハンドルの数に関しては、OSの調子が悪いと1万とか2万とか行く、とかいう現象が起きたりします。でもこれはひとたび起きると、クライアントだけじゃなくて他のありとあらゆるアプリケーションで起きているので、OSのせいだなーということで放置してたり(笑)
一応何とかしたほうがいいのかな、と思っていろいろ見てたところ、ちょっと気づいたことが。
…とりあえず自分がフォローしようとすると話がややこしくなるなぁこれ。(それも多分普通の予想を超えてややこしくなる)
というわけで今回の特定の件に関しては、僕は積極的に放置する方向ですし誰でも歓迎です(笑)
# と、こんな変化球で収めようとしてみるテスト
\t\u\s[10]\h\s[20]ところで全然関係ないけど、\w3７０万瓶目の公式発表、\w3結局無かったね。\w9\w9\uそういえばそうやな。\w9\nちゅうか、\w3公式発表があるモンなのかどうか知らんが。\e
それ特定しようと思うとボトルサーバが止まるんです(笑) コレの確定だけのためにサーバ止めるわけにも…
んで例のお話については、自分のとるべき最良の行動を選択中みたいなところで。システム側でどうこう、という話があれば積極的に変えられますけど、初心者チャンネルやら何やらのアイディアは一通り却下されちゃってますし。
6月4日のメンテは上手くいってなかったので、今日中にやり直しをしたいと思います。
…でも失敗した原因がよく分かってないという。
\t\u\s[10]\h\s[104]やっぱり天の声は正規表現エラーがでるね。\w9\w9\u何が反応しとるんやろ。\e
そもそもダイアログによるメッセージは(表示場所がスクリプトと同じ場所であるだけで)スクリプトではないので、空文字をチェックすることになってしまうかと思います。
とりあえず正規表現でチェックする場合にはメッセージのタイプを「通常ボトル」に限る方向でどうでしょう…
現在、きっと1年ぶりくらいにテーブルの最適化中。
ただ、これやるとトップページとか全ログページまで見えなくなってしまう上に、見ての通り異様に時間がかかっているので、毎月やるわけにはいかないですねこれ。
ボトルサーバの場合はデータは追加する一方で、既存のレコードの変更はほとんどないので、やらなくても問題ないと思いますが。
ちなみに今11:47分現在、一番大きいスクリプト本体が入ってるテーブルの最適化中。これがいつ終わるのか見当付きません。ごめんなさい。
11:56に終わり。一応全経過は30分くらいかな…
\t\u\s[10]\h\s[119]けど、\w9一月に一時間程度のメンテ時間があっても構わないような気がするけど。\w9\w9\uそれで普段500やら出んで使えるんなら、そっちの方がエエ気がするな。\w9\w9\n勿論、事前に告知しとく必要はあるやろが。\e
アレは相変わらず出ます(笑) 昔出ていたのは、ボトル投票の部分で酷いことになっていたのが原因ですが、今たまに出ているのは全部別の原因ですし。
70万瓶目…駅前フッサール
\t\h\s[0]さて問題です。\w9\w9\n今までの中に犬は何匹いたでしょうか。\u\s[10]\w9知るか。\e
80万瓶目…公園どどめ
\t\u\s[10]\h\s[4]あは～んって何やろ？\w9\w9\w9\u\s[13]あは～ん。\w9\w9これやな。\w9\w9\h\n滅多に使わんな･･･\w9\w9\e
にて確定、ということでお願いします。
\t\h\s[4]ところで、\w9\w9雑誌に載せる許可をとった後には１部送るとか、\w4そういうルールってないの？\w9\w9\u少なくともボトラーは紹介ページくらいは見る権利があると思うんやが。\w9\w9\h\n\n\s[8]ま。\w9\w9\nネトランがサイト管理者達に許可とってるとは、私はちー\w4っとも思っちゃいないけどね。\e
とりあえず来てません。…まぁメアドが壊れてたんですけど。コンプティーク? 何それ(笑)
ごめんなさい修正
70万瓶目…駅前みきか
\t\h\s[0]ﾀﾞﾊﾞﾀﾞﾊﾞ\w9\w9\u\s[10]ﾀﾞﾊﾞﾀﾞﾊﾞ\w9\e
80万瓶目…学園どどめ
\t\h\s[1]\u\s[11]\_sぷっぷくぷ～。\e
かも。(かもって…)
月ごとの、ボトルを送信しているユニークなLUIDの数。
これはほぼ、ボトルを送信した人間の数と一致するはずの値です。ただしバイアスとして、
複数のUIDを使い分けて数か所で受信・送信している人がいる場合、この数はダブります。特に接続方法が多様化している最近は、その傾向が強くなり、全体のLUIDの数が多くなる傾向となります。
過去の一部の互換クライアントソフトは、起動するごとにLUIDを取得するように組まれていたため、その場合には、全体のLUIDの数は多くなり、薄い水色の部分の面積が相対的に大きくなるような傾向になっていきます。
過去にUIDが公開されていた時期、個人特定防止のためにLUIDを個人が複数取得しようとする傾向がありました。
特にまゆらが、ボトルクライアント起動するごとにLUID取得し直すツールを2003年2月頭まで毎日のように使っていたそうです。(2月以降突然100近く減ったの、明らかにそれ…)
太い線の部分が1瓶以上流したUIDの数。オレンジは、その中でも月に500瓶以上流した人の数。
毎月で100瓶以上流す人の数はコンスタントに増加しています。特に1人で毎月500瓶以上流す、という人の数は、グラフでは目立ちませんが、2002年は15～20人程度だったのが、2003年には25～35人まで増えています。
まゆらの件も勘案すると、最近のボトルの送信が少数による寡占状態になりつつある、とは必ずしも言えず、単純にたくさん流す人の比率が増えてきただけ、と評価する方がよさそうです。
ボトラーが初心者に居心地がいい/悪い場所になったかどうかを数値化するのは難しいです。
一応、Prospectiveに、ある月に取得したUIDが、2か月後以降も使われているかどうかを調べた結果がこれ。
おおざっぱに見ると、「新規LUIDで投稿した人の6割～8割が2か月以上後にもそのLUIDを使って投稿しており、3割～6割が、4か月以上後にもそのLUIDを使って投稿している」ということになります。「黄色の面積が相対的に広い＝すぐにそのLUIDは使われてなくなっている」という意味になるわけですが、それが明らかに広がっているような兆候はなさそうです。
もっとも、ボトルの新規参加者が毎月40人ずつ増えているわけはなく、むしろ投稿している人の数は減っているわけですから、このグラフのうちかなりの部分は、「既存ユーザが何らかの理由でLUIDを再取得した」系のものだという気もしますが。
※2003/03以降の新規参加者は「4か月後(赤)」のデータがありませんし、2003/04以降の新規参加者については「2か月後(橙)」のデータが不正確ですので留意してください。また、「2か月だけ投稿した後、1年ぶりにボトル復帰」とかいう人が出てくると、このグラフの真ん中あたりの期間についてもこれから増えてくる可能性があります。
逆に、Retrospectiveに、5月に送信に使われた225のUIDについて、それらがいつ取得されたものかを調査してみると、こんな感じ。
全体の半分近くのLUIDは、その月のうちに取得されたものであり、半年以上使われているIDは多くない、という感じでしょうか。
ちなみに、「取得されているLUIDの数」となると、2003年5月で371件、4月で470件、など。
以上から、だいたいの予想にしかなりませんが、「今も昔も、3～5割の人はつないだまま、何も喋らずに去っていく」「一旦はじめての送瓶まで行ったら、約半分は数ヶ月以上続ける」といった感じの動向があるように思えます。
2003年5月に、ボトルを送信した、もしくは1票以上投票した人について、横軸に「送信したボトルが投票された数」縦軸に「流れてきたボトルに投票した数」をとって散布図にしたものです。対角線より右下に行くほど「投票するよりされるほうが多い人」、左上に行くほど「投票されるよりする方が多い人」ということになります。
1人で4476票投じている人は、1日平均150票近く投じている凄まじい応援団。逆に1日平均60票以上もらっている凄いネタ師も…。
ちなみに原点付近を拡大してみると、
縦軸にずらーーーっと重なっているのは、「投票はするけど自分は投稿しない/駄瓶しか投げない」人たち。横軸に重なっているのは「相当票をもらっていても自分では他のメッセージに投票しない」人たち。結構両極端に分かれているようです。
さらに上記のグラフに「合計投瓶数」をバブルの大きさで表現してみたバブルチャート。大量生産大量得票の人がいたり、壮絶な得票稼いでおきながら瓶数は極端に少ない人がいたり(勿論あの人です)。
なんかみんな気になるらしいのでツール。LUID放り込んでください。負荷の関係で過去2か月のみ。
サーバ負荷高いのでほどほどでお願いします。
経路問題ではなくて、何らかのクエリが遅いせいでその間テーブルがロックされ、投稿をログに書き込むためにロック解除待ちとなっていた瓶が、10とか溜まっていた、という状況のようです(あともう少し待ち時間が長ければ、待ちきれなかったりプロセスが増えすぎたりで、500やらGracefulが出るんじゃないかと)
遅いクエリの正体、まぁもちろん昨日の↑かもしれませんが、以前からたまにこういう問題が出ているので別の問題である可能性が高いです。(一応上のは、一番強烈に流している人でも数秒以内に応答が戻るのを前提にしているので)
調べてみます。
(試さないでいいですが)過去ログダウンロードでとある条件を選ぶ、とか、サイトの投票ページでとある条件を選ぶ、とか、そういう人がいたらその瞬間に遅くなっている可能性が高そう。
誰か試したな…しょうがないので身に覚えのある人はToDoに報告しといてくださいw
\t\u\s[1005]\h\s[4]今、\w3試しに例のＣＧＩやってみたんだけど。\w9\w9\u\s[1004]３秒ほどかかったな。\w9\nワイらのせいやったら本当に申し訳ない。\e
いやあり得ないかと…どうせ、Multi-Read Exclusive-Writeなロックなので、誰かが重たい検索(読み取り)をしている状況で、別の人が3秒程度の検索(読み取り)をしても、微々たる影響だと思います。問題になっているクエリは、3秒どころか、瓶が詰まっていた時間、つまり1分以上かかって、1分以上誰もDBに書けない、という状況を作っているクエリだと思われます。
こういう話出しちゃった以上重大なセキュリティ問題なので、超特急で解決しないとヤバい(笑)
特性として、「同時に検索(読み込み)はできる」「誰かが書いている最中に読み込みは出来ない(不整合起きるので)」「誰かが読み込みしている最中に書き込みは出来ない(同じ理由)」というのがあります。
なので、誰かが1分かかる検索をしていると、その1分間、投稿や投票(いずれもログをテーブルに書き込む)は出来なくなってしまいます。誰かが1分かかる検索をしている最中に、別の人が普段1秒かかる検索をした場合、マシンが忙しいので3秒かかってしまうかもしれませんが、それはそれで問題なくやれます。
書き込みで1分かかることは決してないので、どっかの読み込みプロセスが1分近くかかっているんだと思いますが…
\t\u\s[10]\h\s[0]しかし、そんな爆裂に負荷かかる検索なんてあるんやろか？\u\w9さあ。\e
ありました。概ね原因判明。
4.0.4の新機能
http://www.mysql.com/documentation/mysql/bychapter/manual_News.html
Added some more optimisation to use index for
SELECT ... FROM many_tables .. ORDER BY key limit #
など、今回の場合に該当するかもしれない雰囲気なので、テストサーバ構築して検証してみます。取りあえず、LIMIT関係の今のMySQLのサーバの最適化がかなり馬鹿なんですよ、という話があって、4.xではいろいろ調整されている雰囲気なので。
ただ今週は普通に本気で忙しいのでちょっと遅れがちになるかもです。