Увеличение скорости запроса MySQL менее чем на 0,1 мс / запрос

Question

О

Для любого отдельного запроса серверу MariaDB потребовалось примерно 1 мс для каждого запроса.Когда параллелизм увеличивается, время запроса для каждого запроса также увеличивается до истечения времени ожидания.Безусловно, кажется, что возможно только сделать около 2k максимальных соединений в секунду для каждого экземпляра сервера MySQL, никакие настройки конфигурации, кажется, не имеют никакого эффекта.Есть ли способ уменьшить время запроса для каждого клиента менее чем на 0,1 мс?

Это запрос

select ID from table where id=1;

Если это поможет, вот файл конфигурации mysql

[client]
port        = 3306
socket      = /home/user/mysql.sock
[mysqld]
port        = 3306
bind-address=127.0.0.1
datadir=/home/user/database
log-error=/home/user/error.log
pid-file=/home/user/mysqld.pid
innodb_file_per_table=1
back_log = 2000
max_connections = 1000000
max_connect_errors = 10
table_open_cache = 2048
max_allowed_packet = 16M
binlog_cache_size = 1M
max_heap_table_size = 64M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
sort_buffer_size = 8M
join_buffer_size = 8M
thread_cache_size = 8
thread_concurrency = 200
query_cache_size = 64M
query_cache_type = 1 #My settings
innodb_io_capacity = 100000
query_cache_limit = 2M
ft_min_word_len = 4
default-storage-engine = innodb
thread_stack = 240K
transaction_isolation = REPEATABLE-READ
tmp_table_size = 64M
log-bin=mysql-bin
binlog_format=mixed
slow_query_log
long_query_time = 2
server-id = 1
key_buffer_size = 32M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover
innodb_buffer_pool_size = 2G
innodb_data_file_path = ibdata1:10M:autoextend
innodb_doublewrite = 0
sync_binlog=0
skip_name_resolve
innodb_write_io_threads = 500
innodb_read_io_threads = 500
innodb_thread_concurrency = 1000
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 8M
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 120

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash

[myisamchk]
key_buffer_size = 512M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M

[mysqlhotcopy]
interactive-timeout

[mysqld_safe]
open-files-limit = 81920

HW

2x Intel Xeon 2670 32 ГБ ОЗУ 500 ГБ ssd samsung evo 850

Объезд

ХотяЭто правда, что MySql может выполнять более 1 миллиона запросов в секунду, тест здесь просто сделал только 250 подключенных клиентов.

PS

IЯ еще не являюсь экспертом в программировании или MySQL, поэтому, пожалуйста, потерпите меня.

Answer 1

Ваша машина имеет 4 ядра, правильно?Таким образом, если вы запустите более 4 процессов, связанных с процессором, процессор будет насыщен.Это означает, что каждый поток будет прерван для запуска других потоков.То есть задержка увеличивается .

Ваша цель - сократить время, затрачиваемое на средний запрос?Это латентность?Тогда больше подключений не помогут .

Является ли ваша цель запросов / секунду, тогда, опять же, вы остановитесь, как только ЦП загрузятся.Это, вероятно, произойдет до того, как вы получите 8 соединений.После насыщения ЦП пропускная способность (количество запросов в секунду) будет выравниваться даже при увеличении количества соединений.Но, как я уже сказал, задержка для отдельных запросов увеличится .

Если вы хотите нажать на машину, выполните несколько запросов в каждом соединении.В противном случае вы только синхронизируете обработку соединения.Это бесполезный показатель.

Если вы добавите больше серверов (через репликацию, кластеризацию и т. Д.), Вы сможете выполнить больше запросов в секунду.То же самое для большего количества ядер.Но ничто не уменьшит время, затрачиваемое на отдельный запрос.

В настройках max_connections = 1000000 смешно и может потреблять много оперативной памяти.Как я уже сказал, 8 могут быть все, что может сделать ваш бенчмаркинг.

Другая настройка ... Включение кеша запросов обманчиво.Он ускоряет запуск идентичных SELECT , если соответствующая таблица не изменилась.То есть первый запуск запроса может занять 1,0 мс;тогда все последующие запуски того же запроса могут занять 0,1 мс.Это не очень захватывающая находка.Выполните запрос дважды - это даст вам все, что вы можете выучить, без запуска какой-либо платформы для тестирования и т. Д.

Но большинство производственных машин считают контроль качества бесполезным.Это связано с тем, что данные меняются, поэтому контроль качества устарел.Фактически, из-за затрат на «очистку» QC запросы могут выполняться медленнее!

Если вы хотите иметь много соединений для чтения, ведомые устройства репликации могут предоставить неограниченное количество соединений.Раньше я работал с системой из 23 рабов;это дало 23x связи.Booking.com имеет системы с более чем 100 рабами.Вот как вы можете так быстро проверить доступность отеля.

Пожалуйста, сделайте резервную копию и подумайте, какова ваша реальная цель.Тогда мы можем обсудить вещи дальше.