7月の終わりに盛大に転んで左足と右肩に感じている痛みがまだちゃんと治らない。整形外科でレントゲンを撮ってもらって受診した。特に異常はないからできることは痛み止めシップぐらいとのこと。
ここへきてやっと最近痛くて動きたくない感じは無くなってきたなあ、と思って意識してみると、やっぱりまだちょっと痛い。なかなか治らないなあ。
ちょっと違うところが痛い気がしてきた。こうやって病院通いを始めるのかもしれない。この痛みは無視しておく。
投稿者「eight」のアーカイブ
転びやすくなった
50年以上生きているせいか、最近転びやすい。酔っぱらいやすいのもあって、非常に危ない。気をつけなければいけない。あと10年は生きないと、早逝したはずの父親を超えられない。若干不安。
石川県七尾市の赤崎温泉が出てくる小説
船戸与一だったような気がするんだけどなあ。松本清張だったかもな気がするのは「砂の器」に引きずられているせいだと思うんだけど…
インターネットを検索しても出てこない。自分のメモを検索しても出てこない。で、読んだはずの船戸与一の本は手元にない。誰か教えてください。
赤浦じゃなくて、赤崎だった。記憶ってひどいなあ。まあ見つからないのは同じ。巌門の赤崎は違う。
諷諭
遠回しにそれとなく教えさとすこと。
諷喩／風諭（ふうゆ）の意味・使い方をわかりやすく解説 – goo国語辞書
少し前に帰省したときに、蔵の書庫をあさっていると岩波書店の新日本古典文学大系がズラッと並んでいるのに目がいった。
古今和歌集など５冊を選んで持ってきた。さすがに全部持ってくるのは無理。源氏物語を持ってこようなとパラパラみたけどこれもハードルが高い。和歌は比較的読めそうだ。
帰宅して、中１女子とふたりで古今和歌集を読み始めた。わからない言葉も多いけれど、おおむね意味は取れる。脚注も豊富なので意外と読みすすめられる。
その中で出てきた言葉が”諷諭”。
1年前に下書きに書いていた文章を見つける。この書庫は2024年1月1日の能登半島地震でガタガタに崩れて今どうしようかなあ、という状況。
村上春樹「螢」
先日ちょっと帰省したときに、書庫になっている納屋をなにかないかなあと捜索してきた。なかなか良い本が見つかって20冊ほど持ち帰ってきたなかに、村上春樹の「螢・納屋を焼く・その他の短編」（新潮文庫）があった。
奥付を見ると昭和63年（1988年）3月25日の四刷。1987年が「ノルウェイの森」発売だからヒットを受けて文庫化されたんだろう。確か単行本も持っていたはずだけど売ってしまったのかもしれない。
1987年に二十歳で駒込に住む大学生だった自分がどんな気持ちで読んだのかなあと考えながら「螢」を読んでみた。結構覚えていて、国旗を掲揚する寮の話や、お茶の水本郷駒込を通る長い長い散歩をする場面も覚えがある。二十歳ぐらいで読んだものは、けっこう記憶に定着しているのだな。
最初のページに、
寮は見晴らしの良い文京区の高台にあった。敷地は広く、まわりを高いコンクリートの塀に囲まれていた。
とある。”村上春樹 螢 文京区”で検索すると、阿部公彦さんという方が紀伊國屋書店のウェブに書かれた文章がすぐに見つかる。
阿部公彦 2008-03-24 『螢・納屋を焼く・その他の短編』村上春樹(新潮文庫) ー 書評空間::紀伊國屋書店 KINOKUNIYA::BOOKLOG プロの読み手による書評ブログ
この方は目白の田中角栄邸の隣にあった螢の寮のモデルらしい寮にお住まいになっていたという。僕の1歳年上なので、僕の読んだ頃にそこで暮らしていたことになる。
この文章を書き始めたのは、文庫版の44ページにある文章に引っかかって、あれこれ検索してみたから。
主人公が寮の屋上に上ったときの描写、
狭い空間に腰を下ろし手すりにもたれかかると、ほんの少しだけ欠けた白い月が目の前に浮かんでいた。右手には新宿の街が、左手には池袋の街が見えた。
文京区から右手に新宿、左手に池袋が見える場所があるかな？文京区が北に出っ張っている場所がないかと念のためにGoogleマップでみてみたけど、やはりみあたらない。
新潮社校正部がこんなの見逃すはずがないから作者に確認済みだろう。つまりわざとそう書いていることになる。
どういう意図だったのかなあ。
MariaDBからRedisへ一部の機能を移行したこと
記録しておかないとなんで移行したのか忘れてしまいそうだから書いておく。
MySQL5.6からMariaDBへ移行
だいたい毎月100万PVほどあるWEBサイトのデータベースをMySQL5.6からMariaDBへの移行と同時に見直して、一部の機能をRedisへ移行した。
MySQL5.7の5.6からの変更がうちには合わないし、もうMySQLは見限って良さそうだし、MariaDBへ移行することにした。やってみると、インストールと設定の移行はいろいろ細かい調整は必要だったけれど特に問題なく移行できた。
ただ、MariaDBへの移行で同時に解消しないかなあと思っていた問題も引きずってしまった。
DB接続の断続的な切断問題
問題というのは、高負荷になるとDBアクセスが断続的に切れてしまってアプリケーションでの接続し直しが頻発して結果的にWEBサイトのレスポンスが悪くなってしまうこと。MySQL Server goneとかなんとか。
当該サイトは11月ごろからアクセスが増えて12月から1月がピークを迎える。10月中にはなんとかしたかった。
どのSQLで接続が切れるかは特定できない。同じSQLでも切れることもあれば切れないこともある。SQLのログをとりつつどこで起きているのかをリストアップするとだいたい傾向がわかってきた。あれじゃないかなあと予想はしてたところだった。
テーブル定義: CREATE TABLE kvs(k int NOT NULL PRIMARY KEY, v text)
切断が起きる前後のSQLで80％程度をしめていたのが、このテーブルへのこういうSQL： SELECT v FROM kvs WHERE k in (1, 2, … 256)
SQLで柔軟に検索して集めてきたkvsテーブルのキーの値（kvs.v）を最終的にドンと持ってくる部分。inで指定されるキーの数は10個未満が90％だけどたまに256個とかもある。最大512個までに制限しているけど本当は8192個ぐらいはいけるようにしたい。
こういう感じのkvsテーブルへのクエリーが60クエリー/秒程度を超えてくると結構きつく切断と再接続が頻発する。inで指定されるキーの個数は関係あるような気がするけどないような気もする（ちゃんと調べてない）。
アプリケーションではローカルディスクでのキャッシュもしているし、MySQLのクエリーキャッシュも設定しているけど、WHERE句のバリエーションの方が多くてあまりキャッシュにヒットしない。
マシンの性能アップでも解消する部分はあると思うけれど、売り上げを考えるとこれ以上のメモリー増設やCPUアップグレードもやりにくい。RDB的な使い方でもないしなんだかなあと思ってはいたので、いよいよKVSを試してみることにした。
Redisで解決
キーの値をまとめてもってくるkvsテーブルへのアクセス部分だけをRedisに移行することにした。この部分はシンプルだし、アプリケーションの手直しも容易（容易ならなぜ早くやらなかった）。
SELECT v FROM kvs WHERE k in (1, 2, … 256)的なSQL発行をRedisのMGET 1 2 … 256に置き換えるだけでMariaDBの負荷は半分以下になるし、100クエリー/秒を発行してみたけれどRedisはなんでもない。RedisとMariaDBの合計で使うメモリー量はほぼ変わらないか、MariaDBへの接続数が減ったのでその分トータルのメモリ使用量は減っているように見える。いいことばかり。
適材適所ってこと。おわり。