maria-discuss team mailing list archive

[Reindl Harald <h.reindl@xxxxxxxxxxxxx>]

Am 07.09.19 um 21:38 schrieb Jure Sah:
> On 7. 09. 19 21:03, Jan Steinman wrote:
>> I’m using an inexpensive Mac Mini, maxed out with RAM, and a 2GB SSD,
>> running NOTHING but MariaDB. I even run it headless, which means all
>> the UI processes stay in sleep(3). When I was having web server
>> performance issues, that was the one thing that improved things the
>> most. And that was after wasting a lot of time trying to tweak MariaDB
>> variables.
> 
> I work for an ISP. The system they use is connected to a dedicated SSD
> RAID array on SAN. On the particular virtual machine the MariaDB is on
> the same server as the Apache webserver.  The main issue is that the
> website gets a lot of traffic. It has some CMS-based website on it and
> the session table is grinding away constantly.
> 
> Normally it's not a problem, but once when a malfunction on the SAN
> network caused degraded performance (not downtime mind you!), with the
> usual traffic the website was simply down with Gateway timeout from
> memcached. The workaround was to temporarily move the database to a
> ramdisk (tmpfs).
> 
> My employer considers stepping outside the recommendations of the open
> source community to be not worth the risk, and the issue was resolved
> since.  However I know that I shouldn't have had to make the workaround
> with the ramdisk, because the kernel page cache was supposed to take
> care of that by itself. The reason this doesn't work is the fsyncs used
> by MariaDB, which effectively disables any advantage offered by the page
> cache. I think that is a great shame so I am trying to see if there is
> anything I can do about that.

that's how are databsed are supposed to work and a proper storage with
battery backed write cahce should have no issue

whatever you do or dirty< hacks you want, they belong to the storage,
there is even software outhere rendering fsync a NOOP