MariaDB Insert queries stuck frequently I am currently doing high insertions into my MariaDB 10.4.12 database via scripts.
However, sometimes the insertion queries just get stuck/piled up at what it seems to be at the Update or Commit state.

The above insertions that I am mostly doing (95% of the time) are INSERT IGNORE INTO table1 ('b1','c1','a1') VALUES (?,?,?)
Sometimes, they can even go up to 300+ seconds, until eventually all the insertions queries slowly get cleared up within 5-10 seconds (it seems like something is stuck)
I have thought of few things to improve the insert operations :

Do BULK insertions instead of many single insertions
Use transactions
Increase innodb_log_file_size

However, ontop of doing that, I would like to know if this is due to other reasons.
When I checked my iotop , half of the time it shows that mysqld is having 99.99% I/O
I am not sure if the disks are failing (2TB x4 in mirror setup) or is there some configuration settings that I did not tuned properly?
Table schema :
table1 (
  a1 bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  b1 char(64) DEFAULT NULL,
  c1 bigint(20) unsigned DEFAULT NULL,
  d1 datetime DEFAULT NULL,
  e1 tinyint(1) DEFAULT NULL,
  f1 int(11) DEFAULT NULL,
  LastUpdate timestamp NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(),
  PRIMARY KEY (a1),
  UNIQUE KEY idxc1b1 (c1,b1)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

my.cnf :
[mysqld]
symbolic-links=0

innodb_thread_concurrency=32
innodb_buffer_pool_size=240G
innodb_buffer_pool_instances=64
innodb_page_cleaners=32
innodb_purge_threads=1
innodb_read_io_threads=64
innodb_write_io_threads=64
innodb_use_native_aio=0
innodb_flush_log_at_trx_commit=2
innodb_doublewrite=0
innodb_autoinc_lock_mode=2
innodb_file_per_table=1

max_connections=10000
skip_name_resolve=1
tmp_table_size=134217728
max_heap_table_size=134217728
back_log=1000
wait_timeout=900
innodb_log_buffer_size=32M
innodb_log_file_size=768M
open_files_limit=1024000
max_allowed_packet=512M

Update #1 : Added SHOW GLOBAL STATUS and SHOW ENGINE INNODB STATUS during queries piled up (stuck for 120s+)
GLOBAL STATUS : https://justpaste.it/3hxey
INNODB STATUS : https://justpaste.it/5uren
Update #2 : Added SHOW VARIABLES
SHOW VARIABLES : https://justpaste.it/3chha
Update #3 : After replacing the disks (which are also SSDs), the issue is solved. This means that choosing the right SSD disk model is very important for a database high insertion/write rate
[very good] Do BULK insertions instead of many single insertions -- Yes.  Inserting 100 rows in a single INSERT can run 10 times as fast.

[good] Use transactions -- Multiple single-row INSERTs save some by doing this.

[it depends] Increase innodb_log_file_size -- There are metrics in GLOBAL STATUS that would help determine the utility of this.  (Your 768M is probably big enough.)

[minor] char(64) -- Is it truly fixed length?  If not, use VARCHAR.  If it is just ascii, then say so.  If it is hex, then consider using UNHEX() and putting it into BINARY(32).  Shrinking the size of the table always helps, but usually by only a small amount.

[safety] max_connections=10000 -- Shrink to something reasonable.  If you ever hit 10000, the system would (1) really bog down, and (2) swap, which would be terrible for performance.

[?] innodb_buffer_pool_size=240G -- This implies that you have at least 300GB of RAM?  How big is (or will be) the table?

[RAID] 4 drives just Mirrored?  No striping?  Hardware (better) vs software controller?

[2 unique keys] Each row must check both before committing.  Is the CHAR(64) a hash of some kind -- hence "random"?

[stumbling] If you have too many clients, they will just stumble over each other.  Your image show a rather long list.  (I don't have a good number for where InnoDB stops improving and starts stumbling.  But it sounds like you have too many.)

The first item will probably be the most productive.  But we can discuss the rest.