Heavy memory use of MySQL

タテログの開発のために、Windows7 PC に MySQL 5.6.10 を入れているわけだが、そのサービスがやたらメモリを食う。500 ~ 600MB くらい常に確保している。このくらいのメモリはかなり微妙なラインだ。これが 1G に近づくと「やべえな! 即なんとかしたい!」という気分になるのだが、「まあこのくらいならいいかな…暇な時にやる気があればなんとかする…」ラインのぎりぎりの限界くらいだ。個人的に。

というわけで暇というわけでもないのだがやる気を出してなんとかしてみる。

このバージョンの my.ini は C:\ProgramData\MySQL\MySQL Server 5.6\my.ini というパスにある。これをいじって各項目のサイズを減らせばいいのだ。ちなみに古い MySQL だと大メモリ・中メモリ・少メモリ環境用の my.ini のテンプレートが用意されてたような気がするのだが、最近のはないようだ。

とりあえず my.ini 中のいろんなバッファサイズを単純に半分にしてみた。…変化なし。んん?

ぐぐってみると、こういうことらしい。つまり table_definition_cache=1400 なる行自体をコメントアウトする。そうすることで、ワーキングサイズは 20MB 程度、コミットサイズは 60MB 程度にまで縮小した。って桁が違う…。

funnIEst browser

Windows7 上の IE で localhost のアドレスをブラウズすると、名前解決に妙に時間がかかることがある。

というのはわりと FAQ らしく、ググるとすぐに解決法が出てくる。たとえば hosts で 127.0.0.1 だけを有効にし、::1 はコメントアウトするとか。あるいは、IPv4 の優先度を上げるとか。

ところがうちの環境の IE はさらに輪をかけておかしいのか、そういった回避法を施してもなお localhost をブラウズできないのだった。

まず localhost の名前解決がまったくできない。いくら待ってもできない。もしかしたら、1 時間くらい待てばできるのかもしれないが試してない。また名前解決待ちの間、IE 以外のブラウザの動作もなぜかブロックが発生する。IE 側で読み込みを中止するとブロックは解除される。ちなみに localhost の名前解決の問題なので、127.0.0.1 でアクセスすればいい気もするが、変わらなかったり、変わったり、よくわからない。ただし、別のマシンからアクセスすればこのような変なウェイトは発生しない。

さらに名前解決とはあまり関係ないのだが、前にも書いた気がするが、かならずページが互換モードになる。正確には、明示的にレスポンスヘッダで X-UA-Compatible: IE=Edge 的なものを送られて来ない限り、文書モードが IE8 になってしまう。html 文書中の meta 要素の X-UA-Compatble は完全に無視される。

強制的に文書モードを固定するというのは、レジストリ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION あたりをごにょごにょする話だと思うが、ごにょごにょはしていない。

というわけでうちの IE は根本的にぶっ壊れているようなのだが、どうすれば直るのかさっぱりなのだった。たすけてー!

vertical development #3

暇を見つけてはちまちまとコードを書いているのだが、開発自体は難しいものは特にないので、特に書き記すこともない。困ったものだ。

基本的には設定されたインターバルで futaba.htm ~ 10.htm を読み込み、データベースを更新し、カタログを生成するだけの話だ。旧タテログから新しく増えた点として、ナチュラルな並び方以外にレス数の昇・降順、立った時間の昇・降順用のカタログも生成するくらい。

強いて旧タテログからの変更点を上げれば、データベース上のログの保存期間がある。ふたばの画像掲示板は、あらかじめ定められたログ保存数より古くなった書き込みは消去され、参照することができない。たとえば dat 鯖の二次元裏では最後の 4000 件の書き込みが残され、それ以前のスレッドも、レスも消去される(ただし、管理用のデータとしては残しているようである)。旧タテログではそれに倣い、データベース上のログも同じ保存期間としていたのだが、新タテログではこれを例えば 1 ヶ月といった期間にした。この間のログは自由に参照したり、検索することができる。

参照というのは、具体的には新たにタイムマシンモードというものを設けた。これによりログが保存されている期間内の任意の時間(1 時間単位)のカタログを参照することができる。大体のユーザは深夜は寝ているのであるが、一部のユーザは深夜に活動し、いろいろと面白いことをしでかしているのだ。この深夜の全体的な板の流れを、後から参照できるということだ。加えてログからスレッドを再構成し、それもまた参照できるようにした。

検索も同様だが、MySQL の全文検索の機能をまっとうに使うようにしたので、ログの量が増えた分を十分補うほど検索の速度は速いようにした。とりあえずテスト環境では大体のクエリは 0.1 秒未満で取ってこれる。実際の環境に持ってきてどうなるかが楽しみだ。

さて特に書くこともないのでまた昔話をすると、実は似たようなシステム(一定期間のログをふたば外部で自動的に保存する仕組み)は以前にも作ったことがあった。それなりに動くものを実装し、img 鯖の二次元裏でちょっと公開してみたことがあった。ログを漁ってみたら 2006 年の 3 月頃なので、まさに 7 年前のことだ。このときの反応は、「これはこれで便利だけど、一期一会的な虹裏の使い方自体を変えてしまうかも」というものが大多数だった。そんなわけでいろいろと勘案して、作ったシステムはお蔵入りにしたのだった。

その後 2008 年に logch なるスレッド保存サイトができたり、それに続いて同じような保存機能・検索機能を提供するサイトが生まれて、それなり使われているようなので、そういう使い方もまあ受け入れられているのだろうと判断し、新しいタテログの仕様を決めている次第である。

vertical development #2

そんなわけで、タテログを公開したのが確か 2006 年の 1 月だったと思う。つまりもう 7 年も前のことなのだ。

tatelog-dat

そのころは PC の画面もだいたい 1024×768 だったし、ヘタすると 800×600 のノートすら現役だったので、タテログもそういうふうにレイアウトを決めた。800×600 の領域に、10 スレッドを縦に並べた 1 ページを横に 8 ページ分並べた。本来は 10.htm までの 11 ページ分あるのだが、隠れた分は横スクロールさせることにした。そのほか、ログの全文検索なんかや単純なログキャッシュ機能なんかも付け足した。

それから、当時のレンタルサーバは非常に弱かったので、3 種のサーバを借り、同じタテログを立て、さらにそれら 3 つがログを融通しあって負荷を分散するようにした。とまあだいたいこんなところだ。

さてこれを 2013 年の今見てみると、なかなかこじんまりしてスペースがもったいない。世の中すでに 16:9 の画面が溢れている。つまり横が余りまくる。それから全文検索の性能もかなり良くない。ログキャッシュの一覧機能がないので活用されてるとはいえない。またレンタルサーバの能力もずいぶん強まったので、負荷分散は冗長すぎる、かもしれない。

というわけで、その辺の不満を解消しつつ新しく作りなおしてみたい。

tatelog-extreme

画面サイズに応じて領域をまるまる使う。全文検索は MySQL の機能をちゃんと使う。ログキャッシュの一覧のために「タイムマシンモード」を設ける。

たぶんそんな感じになると思う。

vertical development

ここで公開しているアプリケーションにタテログというものがある。

タテログとは何かというのを説明するとかなり長くなる。タテログはふたば☆ちゃんねるのコンテンツに関わっている。ふたばでは当初、立ったスレッドの一覧的なものはなかった。ふたばの画像掲示板は「レス送信モード」と、スレッドを最後にコメントが書き込まれた日付の逆順に、その一部、つまりスレッドの本文・画像と最後の10レスを並べるモード(公式なモード名はない。便宜上サマリーモードと呼ぼう)しかなかったのだ。さすがに不便だと管理人さんも思ったのか、その後、といってももう 7 年か 8 年か、それくらい前の話だが、「カタログモード」なるものが新設された。これはその名の通り、立ったスレッドを表の形式で一覧するモードだ。

さてその後、どういう訳か知らないが dat サーバにある虹裏のカタログが突然動かなくなったのである。当然自分を含むユーザは不便を強いられた。しかも一時的な不具合というわけではなく、なかなか治る気配を見せなかった。

不確かな記憶をたどれば、当時、純正のカタログに見た目を似せた「自分用」という外部サイトがあった。純正のそれとの違いは、存在しているスレッドすべてを対象にしていたという点である。純正カタログはせいぜい最後に更新された 50 やそこらのスレしか表示しなかったのだ。それに対して「自分用」は明らかに便利だった。そんなわけで多くのユーザは自分用を使い出したのであるが、当時のレンタルサーバのキャパシティである。はやくも 503 がちらほら出始めた。

そこで、カタログに相当するものを新しく自前で作ろうとしたものがタテログなのである。

しかし同様な外部の擬似カタログサイトを作るとして、「自分用」と同じにするのはあまり意味がない。そこで、サマリーモードの使い勝手の延長線として、スレッドを縦に並べるようにすることを思いついた。純正カタログ・自分用共にスレッドが Z 字形に並べられる形式なのだが、サマリーモードは縦に 10 スレッドが並び、さらに futaba.htm ~ 10.htm までの各サマリが横に並んでいるイメージなのである。それをそのまま 1 ページに構築するようにした。

とりあえず形になった所で公開してみたところ、意外とすんなりと受け入れられた。とりあえず新しいものは死なない程度に貶すふたばユーザにしては珍しいことだ。スレッドが縦に並んでいるので、カタログに対してタテログだ、というネーミングもふたばユーザによるものだ。

Mysterious Color #2

とりあえず ace のソースなんかを見てみる。バッファへの編集は edit_session.js でやっていて、色分けのトークンの切り出しは background_tokenizer.js でやっている。切り出しの処理は setTimeout で分割される。

ソースを見た感じ、再解析は編集の行われた行以降? それでいいのかな。

 * * *

ところでスクリプティングやシンタックスハイライティングについて下調べしているわけだが、すぐ実装するわけではない。0.5 での目標は、まず安定して編集できるようにすること。textarea の拡張として常用できるようにすること。いろんな機能があるけど不安定なエディタなんて誰も使わないのだ。

その後でまず、モデルとビューを分離させたい。今はバッファはすなわち DOM の要素群であり、したがってビューを兼ねている。これはよくない。バッファは単に 1 行を要素にとる配列にし、ビューは見えている部分だけを描画させるようにしないと、数万行のテキストを編集する際にメモリ消費がひどいことになる(はず)。

 * * *

Webkit Opera のデスクトップ版っていつお披露目されるのかな。Opera が Webkit ベースになれば、つまり Composition Events ももれなくついてくるということなので、今やってるような気持ちの悪いエミュレーションはまったく要らなくなる。そうすればいろいろとコードをスッキリさせられる。かなり楽しみだ。

Mysterious Color

Syntax Hilighting のことを考えるのだが、いまいち実装のイメージが湧かない。ところで “Syntax” というけれど、巷のテキストエディタって文法的なものまで見ているものなんだろうか? あるいは、単にキーワードを識別しているだけ? まずそこからが分からない。それから、テキストの編集が行われると当然その行の解析をやり直すことになるのだけど、その行だけではなく、場合によっては編集した行の周辺の影響を受けたり与えたりする。むしろそのケースが殆んどかもしれない。その場合、再解析を行う行はカーソル行ではなく n 行遡った行、ということになるのだが。その n はどーいう理屈で求めるのか? それとも編集が行われるたび先頭行から解析し直すのだろうか。

vim に限って言えば、仕組みは :help :syntax すればだいたい分かる。しかし再解析行を指定できたりするのは自由度が高いといえば聞こえはいいが、実装の都合が見えすぎてる気も……。もしかしたら参考にすべき実装とはちょっと言えないのかもしれない。

もうちょっと色々なエディタのソースを見てみる必要があるかな。うーんめんどいなあ!

Opera migrates to WebKit

http://my.opera.com/ODIN/blog/300-million-users-and-move-to-webkit

Opera がレンダリングエンジンおよび javascript エンジンを Presto/Carakan から Webkit/V8 へ変更するそうです。ちょっと前から、Opera ICE という名で Webkit 版 Opera を開発していることは知られていたが、Presto との関係は明らかにされていなかった。今回、モバイル向け、PC 向けなどの Opera 全体のプロダクトの完全な Presto から Webkit への移行が発表された。

Extension は、Chromium ベースのものに移行させるためのチュートリアルやドキュメントを作成中だという。Extension の仕様自体が Chromium 準拠という形になるのか? はちょっと不明。

世の中びっくりすることばかりだね。

 * * *

Webkit に移行するとなると、Dragonfly はどうなるのかな。ディスコンするにはもったいないような。それを含めて、新しい Opera が Webkit Powered Opera になるのか、あるいは Opera flavored Chromium になるのかいまいちわからない。もちろん既存の Opera ユーザが望むのは前者のはずだが、より詳しい公式発表が待たれる。

 * * *

Opera の外の世界に目を向けると、現役のレンダリングエンジンから Presto が引退することで、Trident/Gecko/Webkit の 3 強時代になり、同時に Webkit 陣営の勢いがより増すことになる(Opera は Webkit への様々なコントリビューションを宣言している)。このような勢力地図の更新について、特に Mozilla がどのような意見を持っているのか、気になるところだ。

 * * *

Webkit の開発組織が、Opera が参入することでどう変質するのかも多少気になる。まあ間違っても、「蓋を開けたら Opera が Webkit を飲み込んだという構図になってた!」みたいなことは起こらないにしても。

Interception

ふたたび github の issue から。

  • Chrome で、オプションページから設定を変更しても既存のタブ上の textarea に反映されない?
  • github の issue がまさにそうなのだが、wasavi を起動するためのショートカットキーが textarea に結び付けれたページ固有のイベントリスナと競合することがある

後者について考えてみる。textarea 上でキー入力があった時、それが wasavi を起動させるためのものかを判断するために、あらゆるページで agent.js という小さなスクリプトを走らせている。この中で [cci]window.addEventListener(‘keydown’, …)[/cci] としてそこで判断している。

一方で、ページに付属するスクリプトが textarea や window や document に addEventListener() する場合もある。複数のイベントリスナは登録順に実行される。ここで [cci]Ctrl+Enter[/cci] を特別なキーバインドとして認識する複数のイベントリスナがあったとき、競合が起こる。github の issue では wasavi の起動とコメントの送信が同時に行われてしまう。

実は開発の初期の段階では、agent.js で window と document の addEventListener() のフックというなかなかの荒業をやっていた。addEventListener() を乗っ取り、wasavi が起動中なら wasavi に関連しないキー入力イベントは無効にしてしまうのだ。しかしたしかに荒業すぎるので、取り外していた。

とはいえ、やはりリスナの競合の回避はそういう方法を使わない限り難しい。ということで復活させた。フックの対象は window/document ではなく window.Node.prototype.addEventListener() にした。つまりあらゆるノードが影響を受ける。荒業どころではなく傍若無人なレベルに達している気がするが……。いや問題なく動くのなら別に傍若無人だろうといいと思うけど、似たようなエクステンションと共存させたとき、うまく動くのかな、とちょっと心配ではある。

wasavi 0.5.293 released

リリースした。

変更点
  • 可能なら限定的にブラウザのスペルチェッカが働くようにした
  • コンテキストメニューから起動できるようにした
  • 編集済みフラグが undo の状態に追従するようにした
  • en のメッセージを contrib されたもので更新した
  • ja のメッセージを en に合わせて更新した
ダウンロード