Why is SSD loaded at 100% on INSERT in Mysql?

Question

linux

Good day!
There is a server (ram 64GB) with an SSD disk (500gb samsung), the server is not loaded.
As soon as I start to INSERT into mysql tables via PHP, the disk simply "dies" - 100% IO is loaded by the process [jbd2/sda3-8], while on SELECT everything works fine with many sites.
What to look for and where to look?
This is what the recorded output looks like iotop
https://drive.google.com/file/d/13xa80U9DvCjGxAu5z...

mysql config

[client]
port=3306
socket=/var/run/mysqld/mysqld.sock

[mysqld_safe]
socket=/var/run/mysqld/mysqld.sock

[mysqld]
user=mysql
pid-file=/var/run/mysqld/mysqld.pid
socket=/var/run/mysqld/mysqld.sock
port=3306
basedir=/usr
datadir=/var/lib/mysql
tmpdir=/tmp
lc-messages-dir=/usr/share/mysql
log_error=/var/log/mysql/error.log

symbolic-links=0

skip-external-locking
key_buffer_size = 128M
max_allowed_packet = 32M
#table_open_cache = 256
#sort_buffer_size = 1M
#read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
#query_cache_size= 16M
query_cache_size = 0 #tuner
query_cache_type = 0 #tuner
query_cache_limit = 1M #tuner
join_buffer_size = 128M #tuner
sort_buffer_size = 128M #my initiative
read_rnd_buffer_size = 128M #my initiative
tmp_table_size = 4GB #tuner
max_heap_table_size = 4GB #tuner

innodb_buffer_pool_instances = 8 #my initiative  https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_buffer_pool_instances рекомендуют устанавливать не больше чем физических ядер
# Должно высчитываться по формуле ( innodb_log_file_size * innodb_log_files_in_group should be equals to 1/4 of buffer pool size)
innodb_buffer_pool_size = 48GB # tuner
innodb_log_files_in_group = 2 #tuner
innodb_log_file_size = 6GB #tuner
#innodb_additional_mem_pool_size = 128MB #my initiative - DEPRECATED
innodb_log_buffer_size = 1GB #my initiative можно и до 15% размера журналов  A large log buffer enables large transactions to run without the need to write the log to disk before the transactions commit. Thus, if you have transactions that update, insert, or delete many rows, making the log buffer larger saves disk I/O. 
#innodb_use_native_aio = 0
innodb_file_per_table

#The open_files_limit should typically be set to at least 2x-3x
#that of table_cache if you have heavy MyISAM usage.
#FORMULA : 10 + max_connections + (table_open_cache * 2)
table_open_cache = 5000 #tuner
open_files_limit = 5000 #tuner

#max_connections=200
max_connections=100
max_user_connections=50
wait_timeout=10
interactive_timeout=28800 # for Scripts and Scrapers! (Was 10)
long_query_time=5

!includedir /etc/mysql/conf.d/

PS On a local computer on an SSD, everything works much faster for writing.

Answer 1

0. I would not switch from innodb to myisam, they usually do the opposite. Myisam has a lot of problems solved in innodb.
1. Making multiple single inserts = evil. Transactions and pieces on 1/10/20/etc lines are more correct.
2. What is the value of innodb_flush_log_at_trx_commit ? try to set the value to 2, see the link about risks.
3. There is also innodb_doublewrite . To reduce the load on the disk, you can try to disable it, but then again at your own peril and risk.

Answer 2

wtfowned you may have too many indexes in this table and the INSERT query starts updating the indexes, and this process is very resource intensive.

Answer 3

Is caching on ssd disabled?
see manuals for cache and frames
https://dev.mysql.com/doc/