Minor technical issues

[Q]

Thank you for the appreciation ^_^

[Q]

Downtime on 2026-05-21


So I was adjusting the Database server, changing database table engines. Then I set the innodb pool size to a too high value, and our database server went to eat up all the RAM. That caused the Linux Swap Daemon to start swapping RAM to disk (in order to extend RAM slightly). This slowed down the server to a stand still.

We got the server restarted and I reduced the setting again, to request less RAM. Perhaps in another week, we can consider increasing the RAM, so our database server can do more caching, speeding up fulltext search. But maybe at a later date.


So it's fixed now.

[Graciela L]

again, thanks for the update

[Q]

Denial of Service on 2026-05-27

Unfortunately setting both MemHigh and MemMax in our Databases' systemd Service definition file, made our database lock up, when -- after like 6 days -- it exceeded the MemHigh value (despite MemHigh being much higher set than innodb_pool_size). Thus making Futanaripalace unresponsive.

The good news is, this time not the whole server crashed down, so I could still log in to the server, and simply restart the database server. The bad news is, well Futanaripalace Forum was unresponsive.

You live and learn...

[Q]

Downtime on 2026-06-05

Unfortunately our webserver went down at 2 AM UTC tonight. Apparently there were too many parallel connections to the server. I restarted it, and changed the allowed parallel connections to a higher number. So this shouldn't happen again, at least not in the same way.

The server restart fixed it.

[Keahi19]

Wondering what was going on.

[Q]

Downtime on 2026-07-06

So our MariaDB's systemd .service file was restricting RAM usage too much. I restarted it, and adjusted the MemHigh setting to now be just 2 MB below the MemMax setting. So the OOM killer (out of memory) will cause a restart more rapidly now.

[Q]

Sporadic Downtimes

• on 2026-07-14 19:35 UTC
  
• on 2026-07-16 17:05 UTC
  
• on 2026-07-17 21:11 UTC.
  
• on 2026-07-17 22:04 UTC
  
• on 2026-07-18 00:07 UTC
  
• on 2026-07-20 00:10 UTC
  
• on 2026-07-22 02:56 UTC
  
• on 2026-07-22 23:16 UTC
  
• on 2026-07-23 06:01 UTC
  
• on 2026-07-23 21:21 UTC
  
• on 2026-07-27 17:01 UTC
  

Were self-healing. I.e. our systemd service files restarted our webserver and database automatically, repairing the downtime by itself.
The reason for these downtimes is, that the database server seems to eat up too much RAM.
So the recent changes to our servers' systemd service files proofed to be successful.

Regarding any desire to improve thr status quo, e.g. through increasing our RAM, I am sad to report that a previously announced Server Moving fell flat, I can only do as much as state the current state.