там REDO лог переписан так, чтобы пользовательские треды не занимались записью на диск, а это делалось в отдельном background треде

кстати, это по-идее починит zfs + trx_commit=2 vs trx_commit=0

а что там было у zfs?

https://github.com/ihanick/zfs_percona_server_sysbench

Just a sysbench insert test shows the difference:
sysbench —threads=2 —time=60 —db-driver=mysql —mysql-user=root —mysql-password=secret oltp_insert —tables=2 —table_size=100000 prepare
sysbench —threads=2 —time=60 —db-driver=mysql —mysql-user=root —mysql-password=secret oltp_insert —tables=2 —table_size=100000 run

trx_commit=2 + standard
queries:                             224769 (3746.03 per sec.)
After zfs set sync=disabled local/innodblogs
queries:                             400799 (6679.76 per sec.)
standard + mysql> set global innodb_flush_log_at_trx_commit=0;
queries:                             459014 (7614.75 per sec.)

standard + trx_commit=2 + atime=on
queries:                             182380 (2870.45 per sec.)
zfs set logbias=throughput local/innodblogs, trx_commit=2
queries:                             26862  (393.50 per sec.)

trx_commit=2, innodb transaction logs on ext4 volume (on root volume)
queries:                             226598 (3776.05 per sec.)
trx_commit=2, innodb transaction logs on ext4 volume, after mount -o remount,nobarrier /
queries:                             360373 (5960.63 per sec.)

похоже на какой-то per-inode lock?

Всем привет есть люди кто умеет писать безумно сложные запросы на sql? Возможно понадобится работать с деревьями

Тут считай те же самые. Сделай табличку связей уровнями

@alexey_kopytov два треда, concurrency не причём имхо, просто у разработчиков ZFS свои представления что значит pwrite64 без fsync

Или ставь восьмую версию и делай рекурсивный запрос))))

вроде починило разницу на zfs, только производительность - грусть тоска:
https://bugs.mysql.com/bug.php?id=86215
было на 5.7:
trx_commit=2: queries:                             224769 (3746.03 per sec.)
trx_commit=0: queries:                             459014 (7614.75 per sec.)
стало на 8.0.11 (skip-binlog)
trx_commit=2: queries:                             277950 (4632.33 per sec.)
trx_commit=0: queries:                             250896 (4181.46 per sec.)

я так понимаю, это с 2 тредами? тогда это ожидаемо

ага, я в рамках репликации копал, ну и на много тредов подымать - это надо не ноут а серваки кочегарить

из бесед с Санни и Димой: при низком количестве соединений новый redo log медленнее. они об этом знают, когда-нибудь исправят, но у single-threaded performance низкий приоритет.

но всё равно неплохо, а то я запустил сначала и получил в 10 раз меньший результат (из-за дефолтового log-bin).

а подскажите, ребят, Percona / Oracle закопали поддержку handlersocket окончательно?

Oracle его никогда и не поддерживал (у них memcached plugin вместо handlersocket). а Percona скорее всего да, закопала

Закопала

А зачем он нужен когда Memcached Plugin есть?

для memcached plugin надо структуру таблиц менять, с другой стороны HS слишком сложный оказался для разработчиков и для того чтобы была отдача в производительности всё равно надо менять структуру до key-value + несколько служебных полей. Как результат, у HS просто нет пользователей, memcached plugin как-то жив и где-то посередине между sql и memcached теперь живёт protocol x

точнее x devapi. x protocol может передавать либо обычный SQL, либо devapi вызовы