-
-
Notifications
You must be signed in to change notification settings - Fork 235
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
SQL Error: 90098, SQLState: 90098 The database has been closed #49
Comments
I also get heap space errors:
|
Hi, database code Would you be able to provide the complete log file in a gist? I have ~320gb of books, and Komga goes through that in about 1h30m. What kind of hardware/os do you run it on ? |
I zipped up and put the logs online at http://www.qoob.duckdns.org/komga_logs.7z I'm running this on a Debian NAS with 16GB of RAM and an Athlon 200GE CPU. I changed the container to have a max of 2GB of RAM, but am now running it with no usage limit. It seems like the scanning thread takes over and locks up, because after the first minute or so of uptime, I can no longer access the web UI and only get 504s. |
Could you try running the container without memory limit, add only one library, and let it run until it finishes? You can Once finished (if it does!), could you also check this endpoint: |
Yeah, I'm starting over with a new database and a smaller share of only magazine PDFs this time (I believe my comics share with CBZs and CBRs triggers the problem). Web UI seems responsive now. Unrelated, but I'm seeing a lot of
messages - maybe a good idea to include JAI? Not sure how easy that is. Here's the current output of the metrics endpoint (still running the scan)
|
Thanks for the report. As long as the file descriptor count remains under 200 that should be good, if it sky rockets then there's an issue. Please let me know what you find out about your cbz and cbr shares. About the jpeg2000 error could you open a new issue, and if possible specify what symptom you observe (cannot generate cover, cannot access pages) and also provide the impacted file? You can send the url via pm to my reddit if you don't want to share publicly (u/redpantshk). Indeed I read something about JAI in the documentation of Apache pdfbox, but I didn't pay for it 🙄 |
It seems to be working fine now, consuming 4.9GB of RAM (which is a bit steep :D) I do see a lot of
anything I can configure to help? |
By "a lot" I mean 6527 lines on a 54k lines log file. |
Well, spoke too soon - I added my comics folder as a library and all hell broke loose:
Lots of these :| I guess I'll just use Komga for magazines and books. |
And also:
|
And the first instance of the DB error on the logs comes from:
|
And finally
|
The memory footprint seems irrelevant in Java, from what i have seen. Apparently the garbage collection is not triggered if no one else needs the memory. You can have a look also at this issue #17.
I need to investigate this, i have never seen it before.
It seems there are no image files in your
Seems the rar is damaged. Some archive utility may be able to parse it, but the rar implementation in java may not be. Do you have many of those ? Can you check the files to see if they are proper? Also, do you know how many of those files have this error?
It might be caused by the other errors that are not properly managed, resulting in a broken state of the relationship in the db :( |
It seems there is an issue with some of my comics files. I've tested two of the ones Komga complains about, and for both of them one of the JPGs inside has a CRC error. The files are too big to upload here, but here's an example output from
My comics reading app just shows a blank page with an error icon and keeps going. Maybe Komga can be a bit more tolerant in these cases? |
Yeah, no dice. Even with the scanner running, I still get
and the web UI stops working. I guess Komga needs more than 16GB of RAM to analyze my comics :D |
I could try, but I'll need one of the files to understand where is the problem and how to get around. Can you post it somewhere else? |
I don't know how many of those other errors like crc issues you have, but that could cause memory leaks (maybe). I still need to use a proper profiler on Komga to see how performance could be improved. |
@gotson I confirm that on the |
@gotson is it possible to add extra resiliency to the web UI code? Having it die while the scanner is still working is a bit annoying. |
I found out why this was the case. I had a 3.0GB PDF :D with an equivalent 65MB |
What do you mean by resiliency? The front-end is loaded as a Single Page Application in your browser, then it's displaying data from the REST API. If the backend is dying, the REST API won't serve any data, and the UI won't display anything. I would need to find a way to make the long running tasks (analyzing) less taxing on the system. |
Indeed i think Komga will load most of the file in memory, not sure exactly how much. Komga uses Apache PdfBox to handle PDF, but even a few pages of that massive PDF would be quite big! |
I mean maybe respawning the web UI worker if it dies? Not sure how easy that would be. But anyway, the original issue has been fixed (or at least, I now know big PDFs are a big no-no) so closing this for now. Thanks for your help, and the new releases! |
Trying to run Komga inside Docker and it all seems to work fine, but after a few minutes of using up 100% of the CPU and ~4.5GB of RAM, it starts showing
in the logs, and all I get is 504 timeouts from that point on. It's still using up a lot of CPU, but the logs have a lot of exceptions about the database being closed.
I have around 600GB of PDFs and CBZ/CBRs.
The text was updated successfully, but these errors were encountered: