センサーログのスクリプトを１０分単位で動かしていましたが、試しに１分単位に動かしてみたところ、意外なところで想定外になってしまったようでグラフの表示やら、日時でテンポラリからストレージに移動しているスクリプトが動いてなかったり。
単純にデータ量が１日当たり１４４件から１０倍の１４４０件になるので、どこかでおかしくなるかとは思っていましたが、それでも想定外でした。
Jul 1 02:03:01 rasp4b4g CRON[9173]: (root) CMD (/usr/local/sbin/savetosd.py)
Jul 1 02:03:01 rasp4b4g CRON[9164]: (CRON) info (No MTA installed, discarding output)
Jul 1 02:03:01 rasp4b4g CRON[9164]: (CRON) info (No MTA installed, discarding output)
cronのログはsyslogにキックしたログはありましたが、エラーの出力は無い様なので、実際に動かしてみました。（メール設定をしていればエラーがメールで飛んでいく設定を作れるから設定しておいた方が良いかも…）
pi@rasp4b4g:~ $ sudo python3 /usr/local/sbin/savetosd.py
cannot VACUUM from within a transaction
cannot VACUUM from within a transaction
VACUUMでエラーが出ているようです。
ググってみると、トランザクション中にVACUUMを行うとエラーが発生することがあるらしいのでスクリプトを確認してみると…
- テーブル間のデータコピー
- テンポラリテーブルのデータ削除
- VACUUM
- commit()
なんで、commitする前にVACUUMさせていたのかは謎ですが、今までVACUUMはトランザクションに影響しないというより、暗礁のcommitが行われてしまうものだとばかり思っていましたが、そうではなくトランザクションとして処理していてバッファが足りなくなったらしっかりエラーを吐き出すようですね。
- テーブル間のデータコピー
- テンポラリテーブルのデータ削除
- commit()
- VACUUM
という順序に入れ替えて実行してみると処理が通るようになりました。
グラフの表示が崩れていたのも、正常に戻ったので、グラフ表示させているスクリプトでテンポラリ内のデータが１日以上になってしまうと都合が悪い作りになってるようですね…
関係がありそうなインストール済みのパッケージ
libsqlite3-0:armhf 3.27.2-3 armhf SQLite 3 shared libraryスクリプトのpython3上でバージョンの確認
php-sqlite3 2:7.3+69 all SQLite3 module for PHP [default]
php7.3-sqlite3 7.3.14-1~deb10u1 armhf SQLite3 module for PHP
libaprutil1-dbd-sqlite3:armhf 1.6.1-4 armhf Apache Portable Runtime Utility Library - SQLite3 Driver
libqt5sql5-sqlite:armhf 5.11.3+dfsg1-1+rpi1+deb10u3 armhf Qt 5 SQLite 3 database driver
pi@rasp4b4g:~ $ python3
Python 3.7.3 (default, Dec 20 2019, 18:57:59)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> sqlite3.sqlite_version
'3.27.2'
>>> exit()
