-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Discussion][Dev] node-sqlite3 does not support worker_threads #574
Comments
👍🏻 for using I noticed the longer my instance of uptime-kuma runs, the slower it gets. We have over 200 monitors. |
I actually tried to switch to better-sqlite3, because node-sqlite3 seems to be not maintained anymore. (TryGhost/node-sqlite3#1483) Since Uptime Kuma is using knex.js as the db wrapper, I wrote a better-sqlite3 driver for knex.js in Unfortunately, I faced more problems with better-sqlite3:
I eventually switched back to node-sqlite3 with my own fork. The ultimate solutions should be supporting MySQL in my opinion, but yeah, it is another big task. Another direction is that if you have any clue on how to add back the worker_threads support of node-sqlite3, you can take a look of my own fork of node-sqlite3 and make a pull request. |
Just read some history in their repo. TryGhost/node-sqlite3#1365 (comment) The big change between v4.2.0 and v5.0.0 is that they upgraded NAN to N-API (TryGhost/node-sqlite3#1304) But they are using N-API version 3 Which is not support for worker_threads according to this comment: TryGhost/node-sqlite3#1365 (comment) So either downgrading node-sqlite3 to 4.2.0 or upgrading N-API to 6 could probably solve the issue. |
22/12/2023 in worker |
@allgloryforrobots you are necroposing on an issue which has been closed a long time ago as resolved. |
While trying to implement scheduled jobs (for auto clear old statistics), I ran into an issue with sqlite crashing in native code. Turns out sqlite3 > 5.0 breaks when running in worker_threads (see node-sqlite3#1381). So here are my options:
worker_threads
. For me this isn't ideal. Although there isn't a strong need for running background jobs in another thread for now, any future CPU-intensive work (like generating reports) would benefit greatly from it. It also helps with modularization since we can ensure each background job acquire it's own db connection. But not using threading does have benefit of a more simple implementation.better-sqlite3
, since I tested it seems to work fine on a worker. From the READMEs it also looks like an all-round better library. Searching the repo I see that the project briefly switched to better-sqlite3 before switching back, but I don't know the reasoning behind. Is there any specific issues users encountered?The text was updated successfully, but these errors were encountered: