SuttaCentral
When I try to access SuttaCentral today, I get a blank screen (beneath the standard SuttaCentral header). When I pop open the developer’s tool bar, I see:
7877.js:2961 GET https://suttacentral.net/api/bilarasuttas/mn137/sujato?lang=en 500 (Internal Server Error)
Perhaps it’s me, my browser, my side of the world. Just thought I’d mention it in case it impacts others. Thanks for all you do! The site is beyond awesome!
I have the same problem. @HongDa ?
There is a group of MN suttas that are failing to load. I was trying to access MN 147 this morning and had to go back to MN 94 to find a sutta that loads.
Yes, it’s a problem with the API. so https://sc.readingfaithfully.org/?q=MN147 isn’t going to work either.
Bhante @Sujato, I know that we can’t set up tests for every single sutta, but since the database is constantly having to be rebuilt as part of regular updating, could we invest time on setting up tests so HongDa isn’t having to race around putting out fires like this?
I have fixed this problem.
If delete all data directories each time when load data, then create a new data directory and load it, I guess this problem can be solved completely. I will load data in this way next time.
Automating the deployment would be a good idea. Instead of having several manual steps to get a new instance of SC up and running, you instead have a big green button that makes those steps happen.
Aspirationally, something like this:
There’s quite a bit of learning material out there:
OK, good luck! 
By the way, are there logs for when we crash out like this?
Wonderful & excellent! Thank you so much, HongDa! You’re a genius! Best, Larry
Thanks, I’ll see how to apply it to SC deployment.
There have been no issues with deployments being terminated due to errors in the last few deployments.
I am currently unable to locate the source of this error.
Sorry to hear that. I know this sort of thing can be stressful.
Are these software updates or data?
It pulls data from GitHub, processes it, and writes it to ArangoDB.
OK, that makes more sense. I have very little experience with database administration, but perhaps our ArangoDB instance isn’t in a healthy state.
I believe @HongDa has mentioned that the search queries often overload the DB, so even normal requests that hit the DB during those times error. Compounding this is the problem that the website (I believe) caches those error responses, so that even when the DB calms down, the site will continue to return the cached error until the server is restarted.
Bhante, You said what I wanted to say.
Now we occasionally receive information that the server’s CPU usage is too high. Currently, the highest CPU usage should be full-text search. The current server configuration is dual-core, 4GB memory. If the number of people using the search is slightly more, it will cause a high CPU usage problem.
Do we think that this is caused by a flaw in the code, or is it time to upgrade the servers? Two cores and 4gb doesn’t seem like very much.
Why not both.jpeg
With smarter caching the server could heal itself from problems and need less restarting and the search code is far from optimized.
But upgrading the server may be a reasonably easy and cheap fix, as hardware is usually cheaper than engineers
Oh yeah, totally want to rewrite it in Rust. (Joke!)
Bhante @Sujato, what do you think about upgrading the server?
Indeed, there are many things that need to be optimized.
