Mysqld crashes periodically (errcode: 28), solution?

Question

linux

Hello! I have a 6-processor VPS (Intel Xeon 2666 MHz), 4 GB RAM. It has a site with active attendance of 1300-1500 uniques per day and an average online of 50-70 people.
Somewhere before the New Year holidays (end of December), the site began to periodically crash (one of the processors was 100% clogged, judging by htop), the server loaded mysqld the most (this was confirmed by studying the history of atop monitoring).
I turned to one knowledgeable person, he slightly optimized the server configuration, added query caching, but the problem with periodic drops was not resolved.
The following error occurs in the mysql log from time to time:
Disk is full writing './FALSE.000023' (Errcode: 28).
After that, the site stops working until I restart mysqld. Further, the site can work steadily for a day or two, and then fall unexpectedly. Or work for several hours, and then fall again.

In the screenshot, there is just an error, and then restarting mysql (I already did this to make the site work again).
I rummaged a lot in Google, especially in Western sources. Basically, people have a similar error like Disk is full writing './TMP something there' (Errcode: 28). And everyone says that this is because the memory limit in the temporary files folder that mysql creates is exceeded. Everywhere it is advised to change the folder to, for example, /home/mysql_tmp and give it the appropriate rights.
Well I changed the folder to /home/mysql_tmp :

It didn't help... the error also appears...
My mysql config:

Disk fullness:

I think the problem of the crash is precisely in this error, since it is the base that falls, exactly when this error appears. Please help me find a solution.

Answer 1

Here you can read to get started: Optimal MySQL setup

Answer 2

I would venture to ask - but the disk is not full? Under what user is the muscle running and what quotas for it are scored in the user for using the disk?
serverfault.com/questions/126461/mysql-disk-is-ful...
in short - "Although the MySQL user had unlimited quotas, when I disabled user quotas in general, the problem was resolved"

Answer 3

innodb_buffer_pool_size - 70% of total RAM is recommended. i.e. 2.8 GB and not 16 meg