行数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度目の正直で成功。

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)

MySQL for Excelアドインをインストールしていると、xlsxファイルを保存時にExcel 4.0 function stored in defined names.とメッセージが出て、xlsm形式で保存を求められることがあるようです。私はアドインをアンインストールしました。

参照

• Excel issue “excel 4.0 function stored in defined names” (stackoverflow.com)

書くネタ無いのでお馬鹿な失敗談を。

プログラムのコードをSVNで管理していて、ローカルではこんなファイル構成に。

~/project
  +- .svn
  +- File1
  +- File2
  +- ...

予想外に規模が大きくなってきたので「サーバ上で」trunk/branchsとフォルダを切り、File1, File2,...などをtrunkに移動。ローカルではFile1, File2, ...を削除、

~/project
  +- .svn

そのフォルダにtrunkサブフォルダを作り、(この時点で分かっている人からは「馬鹿たれ」と言われるはず)

~/project
  +- .svn
  +- trunk

改めてtrunkに対し、サーバからCheck out。

~/project
  +- .svn
  +- trunk
    +- .svn
    +- File1
    +- File2
    +- ...

サーバ上でtrunkからbranchs/branch1に複製。

[サーバ上]
project
  +- .svn
  +- trunk
    +- .svn
    +- File1
    +- File2
    +- ...
  +- branchs
    +- branch1
      +- .svn
      +- File1
      +- File2
      +- ...

ローカルではprojectフォルダの下にbranch1を作成、先ほどのbranchs/branch1をCheck out。

~/project
  +- .svn
  +- trunk
    +- .svn
    +- File1
    +- File2
    +- ...
  +- branch1
    +- .svn
    +- File1
    +- File2
    +- ...

branch1で変更を加えてcommitというのを繰り返して、いざbranch1をtrunkにマージしようとすると画像のようにTree conflict。逆にtrunkからbranch1にマージでもTree conflict。気を取り直してtrunkからbranch2を複製するも、branch2をちょっと変更してcommitしただけでマージ時にTree conflict。

何がいけないのかというと、~/project直下の.svnを削除してなかったこと。焦っていると気づかないもので。

FreeBSD をベースとしたFreeNAS を運用していますが、故(Foltia とかFoltiaとかFoltiaなど)あってat系のコマンドを多用しています。(2015/1/21 追記：正確にはFreeNASで作成したjail内でのFreeBSDがatを多用)

が、どうもキューの登録に失敗するとか、登録したキューが実行されないとかいった問題が不定期で発生。syslogを見るとこんなものが。

Jan 16 01:40:01 foltia atrun[34960]: cannot open input file 'c2729a01697728': No such file or directory
Jan 17 02:05:00 foltia atrun[34946]: cannot create output file: File exists
Jan 17 02:35:00 foltia atrun[41622]: cannot create output file: File exists
Jan 17 02:40:01 foltia atrun[41800]: cannot stat in /var/at/jobs/: No such file or directory
Jan 17 10:00:00 foltia atrun[38582]: cannot stat in /var/at/jobs/: No such file or directory
Jan 17 22:30:00 foltia atrun[59238]: cannot stat in /var/at/jobs/: No such file or directory
Jan 18 00:00:00 foltia atrun[72840]: cannot stat in /var/at/jobs/: No such file or directory
Jan 18 00:30:01 foltia atrun[76644]: cannot stat in /var/at/jobs/: No such file or directory
Jan 18 10:00:00 foltia atrun[24497]: cannot stat in /var/at/jobs/: No such file or directory
Jan 18 10:30:00 foltia atrun[26414]: cannot stat in /var/at/jobs/: No such file or directory
Jan 19 01:00:01 foltia atrun[78312]: cannot open input file: No such file or directory
Jan 19 16:55:03 foltia atrun[38395]: cannot open input file 'c28cf201698b9b': No such file or directory
Jan 19 18:30:01 foltia atrun[44437]: cannot stat in /var/at/jobs/: No such file or directory

この手のメッセージで検索すると古くはFreeBSD 6の頃から同じような症状を訴える人が少なくないのですが、どれも解決には至っていない模様。これがOSのバグだとしても、こんな基本機能の不具合が長期間放置されるとも考えづらいし…

ただ調べていくとどうもこの症状を訴える人はrootのcrontabに以下の設定をしている模様。

* * * * * /usr/libexec/atrun

/usr/libexec/atrunというのは時間が来たキューをまとめて実行するコマンド。OSの初期設定は5分毎にこれを実行しますが、上の設定だと毎分実行して時間が来たキューはなるべく早く処理するということになります。

私もこの設定にしてたので、ダメ元で3分毎に実行と頻度を落として様子を見ることに。さて、どうなるやら。

[2015/1/21 追記] 3分毎の実行は7:30にエラーを出しあえなく失敗(-_-;) ログの時刻を見るとエラーは5の倍数の分の時のみに発生している。5の倍数の分を外すようにcrontabを設定、様子見を開始。