行数150M、サイズ550GBなんていう一枚テーブルをinnodbで作ってしまいました。4TB HDD使ってるのでまだまだ溜め込めますが、こんな量のデータを1つのテーブルに入れることが何か間違っているような気がする。

こうなるとインデックス無しではまともにデータは取り出せませんので、まだテーブルが小さかった頃に数個作ってありました。で、恐れていた事態、インデックスの追加。幸いにもMySQL 5.6ではテーブルをロックせずにインデックスを追加・削除できる ようになったので、何日かかるかわからないけどcreate index文を実行。翌朝見ると異常終了orz

そういえば昨日の帰り際、MySQLのCPU使用率が10%前半に落ちてたな(コマンド開始時は30～50%)、メモリが足りないのかと思い、innodb_buffer_pool_size を2GB→6GBに増やして再挑戦。mysqldは順調に実メモリは消費しましたが、仮想メモリに手を出す様子はなし。

しばらく様子を見ていると、/の入っているHDD残量が少しずつ減っているのを発見。ですが前述の通り仮想メモリは増えてない。はて?

ネットで情報を探していると、たどり着いたのがこれ 。

tmpdirについて少し補足します。MySQLがtmpdirに作成した一時ファイルはlsなどのコマンドでは見ることができません。これはMySQLが一時ファイルを作成したあと、すぐに削除してしまうためです。 LinuxなどのOSでは、ファイルを削除してもそのファイルをオープンしているプロセスがある限り実際の削除は行われません。逆に言えば、こうしておくことでプロセス終了時に一時ファイルが自動的にクリーンアップされるというわけです。lsofコマンドであればMySQLが作成した一時ファイルを確認することができます。

書かれている通りにlsofをやってみると

# lsof -p 2249
COMMAND  PID  USER   FD   TYPE             DEVICE     SIZE/OFF   NODE NAME
(省略)
mysqld  2249 mysql   39u   REG               0,39   5445255168   3534 /var/tmp/mysql.zUtW7u/ibDLGxdb (deleted)

たすかに～。/var/tmpにディレクトリを作っていてサイズが増えていっているけど、lsで/var/tmp/mysql.zUtW7uを見ても空っぽ。増える速度はおおよそ20GB/日(画像参照)。/の容量からして昨晩使い果たして落ちたという理由は合点がいく。

応急策としてiSCSIサーバから800GB融通してもらって/に追加。btrfsなのでインデックス作成終わったら外そうと思ってますが、今考えたら追加800GB単独でフォーマットして/var/tmpにマウントした方が安全だったな…

そのほかの環境

• CPU: Haswell Xeon 3.5GHz
• OS: OpenSUSE 13.2 (VMware ESXi 5.5上)
• DBMS: MySQL 5.6.17-2.1.12 (yastにてインストール)
• ファイルシステム: btrfs (OS用に10GB、MySQL用に4TB)
• VMのメモリ: 4GB→8GB

[参考]

• MySQL 5.6における大量データロード時の考慮点 (SH2の日記)
• Optimizing MySQL Indexes (sitepoint)
• The InnoDB Buffer Pool (MySQL)

[2015/6/26 追記]/var/tmp増量後に再挑戦も翌朝失敗。忘れたころにやってくるOOM Killer 。topで見るとメモリを12GBほど要求しているらしい。swap増量、/proc/(mysqldのPID)/oom_adjに-17を書き込んで応戦、9時間後に3度目の正直で成功。

14年所有していたプジョー206 XT(AT)ですが、青空駐車がたたりクリア層は崩壊(これはもう見慣れたw)、シフトレバーを覆う合皮が剥がれ落ちるなど樹脂系の経時劣化が進んでました。劣化は目に見える所だけにあらず、油圧系のパッキンやベルトなど見えないところの劣化も進んでいるようで、前回の車検で「次は高くつきますよ」と言われた次第。来年から重量税が値上げ されることもあり、そろそろ買い替えかなと。

今日は候補の一つ、新型NDロードスター に試乗してきました。お断りしておきますが、

• 私の車人生でまともに乗ったのは右ハンドル仕様206 XTだけ、必然的に感想はこいつとの比較
• 法律順守の観点から(素直にAT限定免許と言え)、試乗したのはAT車
• あくまで私の主観

ですのでご承知のほどを。

座り心地

ホンダS660の展示車に腰かけた時は「低っ!」と思った座席ですが、それで慣れたのか特に低いとは感じず。ネットで圧迫感を感じると言われていたAピラー も全く気にならず。幌開けてたからかもしれませんが。

ペダル

３度ほどアクセルと間違えてブレーキを踏む。206より外側にペダルがあるのか、ロードスターのシートが体を包み込むタイプなので、いつもと体の向きが違うからか。まぁ、慣れるでしょう。

ハンドル

206よりちょっとだけ重いかなと感じた。

加速

206 XTより車体が軽く馬力のある車ですから、加速が悪いわけがない。半分くらい踏んだだけで206では感じたことのない加速感(体が後ろに引っ張られる感覚)。206と同じようなアクセルの踏み方だとすぐに60km/h超えそうになるので、抑える方に気を使ってしまった。これで206より50%以上燃費良いんだもんなぁ…。帰り際に次の人が乗った試乗車が前を走ってたのでしばらく206をスポーツモードにして後を追いましたが、信号青からの加速で結構踏んだのに離されました。

サスペンション

ごつごつとした感じはなし。少なくとも昔乗せてもらったVW GolfやスカイラインGT-Rに比べれば。個人的にはごつごつ好きなんですが。

曲がり

試乗コースに曲がりくねった道を入れてくれていたため、あとでどうでしたと聞かれ良いですねと答えたのですが、本音を言うと「違いが分からない」でした。これは私が206の経験しかないのが災いしている。206も猫足と呼ばれる旋回性能を売りとしていたため、違いが分からないというのは、ロードスターが良いということなのか私が鈍いのか。初めて通る道かつ反対車線からトラックが来ていなければ、もうちょっとアクセル踏んだのだけどなぁ。

ブレーキ

営業さんが横に座っているときに急ブレーキ踏むような根性は、私にはありませんでした(^_^;) 206ではいまだにうまく行かない停止直前のカックンがロードスターではなかった気がする。

幌の開閉

座ったままの開閉はちょっと練習すればスムーズにできそう。

収納スペース

2リットルPETボトルくらいのショルダーバッグを持っていたのですが、シートに二人腰かけると「このバッグ、どこに置きましょう?」「…トランクですかね」となりました。1リットルくらいの収納スペースなら後部にあったのですけどね。S660に比べればトランクあるだけまし。

車体色

ネットを見ていて一番わからなかったのがこれ。マツダのHP見てると黒は2色、白は3色もあるように見えるし、赤も落ち着いた赤の写真もあれば原色の赤みたいな写真も見る。そもそもマツダHP のはCGで描いてあるのが多いから、ほとんど参考にならず。この辺営業さんに聞いたところ、

• クリスタルホワイトパールマイカ: この記事の写真がこの色。うん、白です。アークティックホワイトが白なら、こちらはオフホワイトでしょうか。
• セラミックメタリック: 営業さんはシルバーの車を指してあれに近いですよとのこと。色見本を見せてもらいましたが、なるほど明るいシルバー。でもネット上でこの色だと言われる写真はシルバーさのかけらもない白。営業さん、本当ですか～?
• ジェットブラックマイカ: 黒。以上でも以下でもなし。黄砂が目立ちそうだけど、かっこいい。
• メテオグレーマイカ: 色見本だと、黒とシルバーの間かなぁ
• ソウルレッド: スマホのSH-06Eみたいな上品な赤だったらいいなぁと思ってましたが、近いです。テールランプを車体のアクセントと考える私にはそれが目立たなくしてしまう色なのですが、それを差し置いてもかっこいい色。営業さんも一番売れていると言ってました。と聞くと、興味が失せるひねくれ者の私ｗ

営業さんの話だと、売れているのは

• 色: 赤。半分以上だとか。
• グレード: 最廉価のSは1割程度で、残りの2グレードで半々。液晶ディスプレイ有無が決め手らしい。
• ミッション: 7割がMT。ま、この車選ぶなら当然か。

最後に失敗談。日本仕様206XTは左ハンドルの欧州仕様からハンドルをそのまま右に持ってきましたというもの。ワイパーは運転席右上を拭いてくれないし、ハンドブレーキはセンターから助手席側にある。最大の違いはウィンカーレバーが左、ワイパーが右。ロードスターは逆だぞと何度も自分に言い聞かせたはずなのに、晴天下のワイパー２回。これは笑いで済みますが、ウィンカーレバーを倒す方向(上下という意味で)も逆だというのは盲点でした。これはロードスターに限らず次の車では気を付けないとなぁ。

EF6.1.3&MySql.Data.Entity 6.9.6&MySQL Server 5.6でマイグレーションを追加したところ、実行時に

MySql.Data.MySqlClient.MySqlException was unhandled
  HResult=-2147467259
  Message=Table 'myschema.dbo.mydatafield' doesn't exist
  Source=MySql.Data
  ErrorCode=-2147467259
  Number=1146

といったエラーが出る。どうやらマイグレーション用コードに'dbo.'が入っているとダメな処理があるようです。

public partial class ChangeMyClassStructure : DbMigration
{
    public override void Up()
    {
        DropForeignKey("dbo.MyTable", "MyTable2_Id", "dbo.MyTable");

手編集で'dbo.'を削除すると、動作しました。

DropForeignKey("MyTable", "MyTable2_Id", "MyTable");

CreateTableなど作成系は'dbo.'が入っていてもうまくやってくれるようですが、少なくとも以下の削除系・変更系はダメな時がある模様(問題無しの時もあって、よく分からんのです、これが)。MySql.Data.Entityの問題かな?

• DropForeignKey
• DropIndex
• DropColumn
• RenameTable

ここ の話だと、EF5からdbo.が付くようになったようで。

[参照]

• How can I stop Entity Framework 5 migrations adding dbo. into key names? (stackoverflow)