中央競馬の予想や購入したもののメモなどを書いて行こうかと。まあ、個人的なメモ的なブログです。
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
1レコードに1,700以上の項目があるテーブルの登録処理に時間が掛かってたんですが、このやり方を改善してみました。これまでは
cmd.Parameters.Add(new SQLiteParameter("@PARA", value));
って感じで毎回やってたんですが、事前に
cmd.Parameters.Add(new SQLiteParameter("@PARA", dummy));
とパラメーターは追加しておき、レコード追加時は値のみを
cmd.Parameters[0].Value = value;
として全てのパラメーターが準備出来たら
cmd.Prepare();
cmd.ExecuteNonQuery();
とする事でかなりの時短が出来ました。このテーブルは元ファイルから約2,500レコード分のデータを登録してまして80秒前後掛かってましたが、今回の修正で4秒とか劇的に早くなりました^^
で、全ての修正はまだなんですが、昨夜フルセットアップしてみた所、これまで13時間だったものが半分以下の6時間弱に改善しててほっとしてます。ただ、まだまだ項目数が少ないけど元ファイルから数万レコード分登録するテーブルがあるんですが、これが4万レコードとかだと30秒以上掛かっているのを何とかしなきゃです。接続文字列は今回はデフォルトに戻してフルセットアップしました。これはdatabase is busyのエラーがトラップ出来ずに延々とハマる時があるので、それを回避する為です。
今回の修正を全てに行った後にまたフルセットアップがどの程度まで短縮されるかは分かりませんが、今回程は期待出来ないので何か考えないとダメかも^^;
今朝起きてみると、フルセットアップが終了してました。13時間38分と1時間程度短縮されてました。ここまでの苦労に見合うかは別として、まだまだなのは確かです。ただ、今回の諸々の変更で、データベースファイルのサイズが60ギガ→40ギガにサイズダウン。ん?大丈夫か?って感じです。簡単に検証出来ないので、無事に全てのデータが問題なく登録出来ているかが心配なくらいです。単にこれがMicrosoft.EntityFrameworkCore系の悪事からの解放の結果なら良いのですがね。
データベースファイルサイズが落ちた副産物は最適化が4時間近く掛かってたと思うのが2時間弱で済んでました。まあ、最適化は頻繁にはやらないかとは思うけど、半減してるのはありがたい。
更なる改善と開発を進めるしかないですね。
まだまだ色々と分かってないとは思うけど、データベース新規作成時に指定しておくものと、毎回指定しなきゃなものがある気がする。毎回メモリの指定するとしばらくしてリソース不足のエラーが出始めるので、これは何となく作成時のみにしておく。ジャーナルモードは毎回メモリとかしないと気が付くとジャーナリストファイルが出来てるのを目視出来ます。
PRAGMA JOURNAL_MODE = MEMORY;
PRAGMA TEMP_STORE = MEMORY;
これらは毎回指定する様にしてみました。これで久しぶりにフルセットアップ開始してみたので明日の明け方には終わるのかな^^;
接続文字列指定で出ていたエラーは無くなりましたが、根本的なスピードアップにはなってませんのでまだまだ学習して改善して行くしかないかも。
取敢えず、何も指定しないデータベースのパスのみだと
2022/04/28 10:23:07 出走別着度数(2,445) [2022/03] >> Done! ...79.2959801秒
2022/04/28 10:24:26 出走別着度数(1,276) [2022/03] >> Done! ...41.2450401秒
PRAGMA TEMP_STORE = MEMORY;
2022/04/28 10:29:22 出走別着度数(2,445) [2022/03] >> Done! ...80.8131174秒
2022/04/28 10:30:42 出走別着度数(1,276) [2022/03] >> Done! ...41.9937788秒
PRAGMA JOURNAL_MODE = WAL;
2022/04/28 10:34:43 出走別着度数(2,445) [2022/03] >> Done! ...80.604067秒
2022/04/28 10:36:03 出走別着度数(1,276) [2022/03] >> Done! ...41.9658116秒
PRAGMA JOURNAL_MODE = OFF;
SQLite error (5): statement aborts at 1: [PRAGMA JOURNAL_MODE = OFF;] database is locked
PRAGMA JOURNAL_MODE = MEMORY;
SQLite error (5): statement aborts at 1: [PRAGMA JOURNAL_MODE = MEMORY;] database is locked
PRAGMA SYNCHRONOUS = OFF;
2022/04/28 10:46:05 出走別着度数(2,445) [2022/03] >> Done! ...81.065699秒
2022/04/28 10:47:26 出走別着度数(1,276) [2022/03] >> Done! ...42.1620051秒
PRAGMA LOCKING_MODE = EXCLUSIVE;
ちと、JOURNAL_MODE = OFF | MEMORY の場合はVisual Studioの出力タグに延々と上のメッセージが出るので強制終了させてるんですが、これは例外で止まる。しかも、随分と待たされた後にトランザクション開始で起きる^^;
PRAGMA MMAP_SIZE = 30000000000;
2022/04/28 11:01:39 出走別着度数(2,445) [2022/03] >> Done! ...78.8158052秒
2022/04/28 11:02:58 出走別着度数(1,276) [2022/03] >> Done! ...41.0700406秒
PRAGMA CACHE_SIZE = 500;
2022/04/28 11:15:15 出走別着度数(2,445) [2022/03] >> Done! ...80.738003秒
2022/04/28 11:16:36 出走別着度数(1,276) [2022/03] >> Done! ...42.4018137秒
PRAGMA PAGE_SIZE = 32768;
2022/04/28 11:19:52 出走別着度数(2,445) [2022/03] >> Done! ...80.382808秒
2022/04/28 11:21:12 出走別着度数(1,276) [2022/03] >> Done! ...41.6193615秒
個別指定ではどれも誤差レベルなんだけど、MMAP_SIZEだけ若干って感じ。これらをどんな感じで組み合わせると良くなるのか、それともエラーにならないもの全てなのか、database is lockedを解消して効果絶大ってLOCKING_MODE辺りを入れれる様にしなきゃなのかGW使って調べるかなぁorz
そもそも、データベースのパスだけしか指定はしてなかったんですが、あちこちで接続文字列で色々指定するとパフォーマンスが上がるって事で試してるんですがなかなか上手く行きません。
PRAGMA LOCKING_MODE = EXCLUSIVE;
DB Browser for SQLiteではエラー無く実行出来ましたってなるのは確認済みですが、これを指定すると
database is locked
ってなります。これ、
PRAGMA JOURNAL_MODE = MEMORY;
してもなるんだよね^^;データベースがロックされたのを解除するとかの話もいくつか見ましたが、な~んか違うんだよな。
PRAGMA SYNCHRONOUS = OFF;
PRAGMA JOURNAL_MODE = WAL;
の2つでもパフォーマンスが上がるって話も見かけましたが、今回の僕のデータベースには効果無しです。しばらく色々試してみる必要がありそうです。