Changelog

[Q]

Updated MyBB-Plugins

So I updated the plugins pertaining to Profile Pictures, custom profile fields, user Mentions (with @) and the Mood. Setting your Mood should now work again.

[Q]

Updated Introductions Area

Abdicated the four old Stickies in the Introductions Area, to replace them with a new, consolidated text, given by our Owner Swammy.

[Q]

Increased file upload size limit

So I increased our file upload limits to 16 MB for images. Also added the file type ".webp", which as of now is also permitted to upload.

A note on failed Image Uploads: Please make sure your content's file type and your image file extension are the same. So if you upload a file that ends in ".png" it mus be encoded as a PNG file, or otherwise our Forum software will reject it, citing some general upload error. If you are unsure about this, and have too much time, see this post of mine, where I explain how to spot this issue.

[Q]

Updated the Forum Descriptions to use SVG icons (Bootstrap's "exclamation-circle-fill" and "info-circle").

[Q]

FullText Search sped up, with DB speeding up

     

So, I was googling around and found MyISAM as MySQL storage engine to be a speed killer. And what do you know? Our Forum software was using MyISAM for most tables.
So I converted some of the database tables from MyISAM to the newer InnoDB. The performance gains were small at first. But InnoDB allowed me in turn to set a big "innodb_buffer_pool_size" of about a Gigabyte of RAM with our MariaDB Server. Now after doing a first Search, successive searches are much much much faster, as the underlying database table gets cached by our database server now.

So....Despite our over 1 Million Posts, the Search now will return within 3 to 4 seconds in most cases.


Unfortunately, the Database Server eats too much RAM. Had to reduce it to a few hundred MB, so the machine doesn't grind to a halt again. The Search has become faster anyhow.

Additionally, thanks to using InnoDB now, the main page shouldn't get hung up any more, if someone else is doing a Search. How so? - Well the former Database engine MyISAM, was doing transactional locking on the whole table, freezing the Forum while a search was running. The InnoDB engine, in contrast has 'row locking'; so multiple read-accesses can be running on the same table at the same time. Thus fixing the hang-ups we have had.

[swammy]

FullText Search sped up, with DB speeding up

 

So, I was googling around and found MyISAM as MySQL storage engine to be a speed killer. And what do you know? Our Forum software was using MyISAM for most tables.

Good on you Q.  Thanks!

For everyone still here, Q's been doing awesome regular background work on the site.  While I keep the lights on, he's been maintaining it so that we can use it and more.  Sort of like the Bill payer and the Maint Manager.  I would never have taken over ownership of FP without Q on board, and he has now become a great friend because of this.

So, let's make sure to thank him properly as well as give proper feedback in the case of any needs.

[Q]

Oh thanks.

It's allright. A few years before joining Futanaripalace in 2014 I decided I do not want to be a person to stand in the foreground. So I feel comfortable, working and tinkering on background tasks and with the background machinery. Hence my title of Technical Advisor.

Thanks for the thanks.

[Q]

New upload type

Since there was a request for posting audio stories (Autio), I added ".mp3" as file type . To allow for some mp3 upload I increased the file upload limit to about 50 MB for .mp3 and. zip files.

[Q]

FullText Search sped up, with DB speeding up

...

So I was fiddling with our database for that issue.

When it comes down to search, this particular partial database query is what has to be optimized for search: MyBB source code.

To get that I worked with AI to determine a few more sensible settings on our database, in particular:

Code:

innodb_buffer_pool_size = 500M
#innodb_redo_log_capacity=200M
innodb_flush_method=O_DIRECT
innodb_io_capacity=1000
innodb_io_capacity_max=4000
innodb_ft_min_token_size=4
innodb_ft_max_token_size=84
innodb_ft_cache_size=16000000 # Per-table FULLTEXT index cache while creating/updating the index
innodb_ft_total_cache_size=160000000 # Global limit for FULLTEXT index cache memory
innodb_ft_sort_pll_degree=4 # Number of parallel tokenizer/sort threads when building FULLTEXT indexes
innodb_ft_result_cache_limit=200000000

Additionally I added a FULLTEXT index to the respective table (that ran yesterday for like half an hour, sorry for any inconvenience there).

Unfortunately this has actually made our search a bit slower ...


Yeah, we will eventually have to get a server with more RAM, than our current 1.9 GB RAM, since a large "innodb_buffer_pool_size" previously was very successful at producing search results within just a mere 3 seconds (beginning with the second query after server restart). Only, the server bogged up all of our precious little RAM within minutes there.

Speaking about RAM, I reconfigured our database server's Systemd service file, to use the OOMKiller (OOM=Linux Out-Of-Memory-Event) to restart the database server, should it reach it's RAM limit again.

After all this I am kind of happy, 'though we don't need to throw like an elasticsearch at our fulltext search issue, but simply having about 950 MB RAM dedicated just to the table of all the posts, with that innodb buffer pool size will be sufficient.

[Q]

So the Fulltext index would trigger a recalculation once a day or so, hanging up the database server each time for like half an hour. So we dropped it.

Also our database server exceeded 785 MB recently, and reached 800 MB of RAM usage ("MemoryMax" setting). Thereby it got killed and restarted, automatically, for the first time. So it is kind of self-recovering now, while also not grinding the whole server to a halt in any case anymore.