Assuming you don't buy an rpi with more ram..
I suspect if you (say) moved the sqlite3 files onto your NAS with a mountpoint to your rpi the same thing will happen. It might not but that would be my expectation. If you're familiar with setting up NFS then it would be a quick test otherwise not worth the effort.
If you were to change from sqlite3 to a remote database (eg: mariadb) then I'd expect less buff/cache to be used because it would be going over the network. Obviously that would require code changes plus a remote db to talk to: substantial effort if you've not used "mysql" before.
Does sqlite3 have the notion of a db "transaction"? Basically you tell your db server every operation between "transaction start" and "transaction end" is an atomic operation. ie: it all succeeds (committed) or it all fails. It can be considered the db equivalent of a mutex.
I'd suggest looking into why things won't stop/start without manual intervention. The notion of a transaction might solve this. Have the sole "writing" service do it as a transaction. This will have the "reading" services either block or fail (may reveal the bug). It's possible the write transaction might free up buff/cache because it has to be written to disk. Dunno if sqlite3 will cheat on this.
You can have systemd bring up (and take down) services in the right order. I haven't bothered to learn much systemd. I tend to have it call one script which does it the old fashioned (/etc/init.d) way by calling other scripts.
I suspect if you (say) moved the sqlite3 files onto your NAS with a mountpoint to your rpi the same thing will happen. It might not but that would be my expectation. If you're familiar with setting up NFS then it would be a quick test otherwise not worth the effort.
If you were to change from sqlite3 to a remote database (eg: mariadb) then I'd expect less buff/cache to be used because it would be going over the network. Obviously that would require code changes plus a remote db to talk to: substantial effort if you've not used "mysql" before.
Does sqlite3 have the notion of a db "transaction"? Basically you tell your db server every operation between "transaction start" and "transaction end" is an atomic operation. ie: it all succeeds (committed) or it all fails. It can be considered the db equivalent of a mutex.
I'd suggest looking into why things won't stop/start without manual intervention. The notion of a transaction might solve this. Have the sole "writing" service do it as a transaction. This will have the "reading" services either block or fail (may reveal the bug). It's possible the write transaction might free up buff/cache because it has to be written to disk. Dunno if sqlite3 will cheat on this.
You can have systemd bring up (and take down) services in the right order. I haven't bothered to learn much systemd. I tend to have it call one script which does it the old fashioned (/etc/init.d) way by calling other scripts.
Statistics: Posted by swampdog — Sun Jun 15, 2025 12:03 am