LINUX.ORG.RU

Медленный инсерт и апдейт в мускуле

 


0

2

Есть такая таблица

CREATE TABLE `table_name` (
  `id` int unsigned NOT NULL AUTO_INCREMENT,
  `item` int unsigned NOT NULL,
  `url` varchar(255) NOT NULL,
  `object` binary(16) DEFAULT NULL,
  `timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `region` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE KEY `url` (`url`) USING BTREE
) ENGINE=MEMORY AUTO_INCREMENT=1051 DEFAULT CHARSET=utf8mb3
И вот такой офигенный mysql-slow.log
Count: 30  Time=2.15s (64s)  Lock=0.09s (2s)  Rows=0.0 (0)
  UPDATE `table_name` SET `timestamp` = CURRENT_TIMESTAMP WHERE `id`=N
Чего я в этой жизни не понимаю? Почему переписать 4 байта в ОП занимает 2 секунды?

UPD: сделал

for i in {1..50};do time mysql -e "insert into test.table_name (item, url) values (15, 'urlsss$i');"&done
На локалхосте значения от real 0m0,018s до 0m0,155s, на хостинге от 0m0.860s до 0m21.471s.

Итого: переехал на Digital Ocean, волосы гладкие и шелковистые.

★★★★★

Последнее исправление: erfea (всего исправлений: 3)

sysbench --db-driver=mysql --mysql-user=root --mysql-db=test --mysql_storage_engine=memory /usr/share/sysbench/oltp_read_write.lua run

На локалхосте (AMD Ryzen 7 3700U):

SQL statistics:
    queries performed:
        read:                            5866
        write:                           1676
        other:                           838
        total:                           8380
    transactions:                        419    (41.83 per sec.)
    queries:                             8380   (836.59 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          10.0138s
    total number of events:              419

Latency (ms):
         min:                                   19.69
         avg:                                   23.89
         max:                                   39.12
         95th percentile:                       26.68
         sum:                                10009.69

Threads fairness:
    events (avg/stddev):           419.0000/0.00
    execution time (avg/stddev):   10.0097/0.00
simplecloud.ru (заявляют якобы «Современные процессоры Intel Xeon E5-2670v2 и E5-2660v3», /proc/cpuinfo: QEMU Virtual CPU version 1.7.0):
SQL statistics:
    queries performed:
        read:                            280
        write:                           80
        other:                           40
        total:                           400
    transactions:                        20     (1.96 per sec.)
    queries:                             400    (39.23 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          10.1946s
    total number of events:              20

Latency (ms):
         min:                                  219.79
         avg:                                  509.65
         max:                                  930.25
         95th percentile:                      773.68
         sum:                                10193.00

Threads fairness:
    events (avg/stddev):           20.0000/0.00
    execution time (avg/stddev):   10.1930/0.00
gdkhost.net (Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz):
SQL statistics:
    queries performed:
        read:                            882
        write:                           252
        other:                           126
        total:                           1260
    transactions:                        63     (6.28 per sec.)
    queries:                             1260   (125.53 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          10.0330s
    total number of events:              63

Latency (ms):
         min:                                  100.23
         avg:                                  159.20
         max:                                  297.92
         95th percentile:                      193.38
         sum:                                10029.78

Threads fairness:
    events (avg/stddev):           63.0000/0.00
    execution time (avg/stddev):   10.0298/0.00

Первая VPS стоит 500р, вторая 25лари (около 8$). Обе 1 ведро и 1 Гиг. Выводы напрашиваются вполне конкретные. Что ещё исключить, прежде чем кидаться какашками?

erfea ★★★★★
() автор топика
Ответ на: комментарий от erfea

чо по индексам

?

Подозреваю, что без индексов БДшка будет заходить в каждую строчку и проверять id-шку. Если строчек много - это займет довольно продолжительное время. Для 550 строчек это не должно быть критично, но на будущее индекс все же лучше создать.

trex6 ★★★★★
()
Последнее исправление: trex6 (всего исправлений: 1)
Ответ на: комментарий от erfea

Индексы могут с одной стороны помочь при поиске (в том числе обновление с условием), но с другой стороны каждое изменение таблицы затрагивает обновление всех индексов. Когда их много, они сложные, а данных в таблице дофига — они могут существенно сказываться на времени вставки или обновления.

Но это не твой случай.

filosofia
()
Ответ на: комментарий от adn

А mysql еще чем-нибудь загружен кроме этих update’ов?

Почти нет. Могу точно сказать что этот трешак происходит когда сервак ничем более не нагружен.

Сколько у тебя параллельных update’ов?

0-20 в минуту. Иногда бывает 2-3 единовременно. Приблизительно каждый 4 попадает в лог. Таких чтобы более одного параллельно процентов 10 от силы и они уже по 4-12 секунд выполняются.

И сколько памяти под heap выделено в mysql?

ХЗ, не трогал, где посмотреть?

ЗЫ там ещё modx крутится. Так вот почти на каждый его чих в логе записи появляются. Отключил сессиий, «INSERT INTO `prefix_session` (`id`, `access`, `data`) VALUES ('S', N, 'S')» тоже самое было. На любое изменение настроек или документов появляются записи в логе. Проблема не с этой конкретной таблицей.

erfea ★★★★★
() автор топика
Последнее исправление: erfea (всего исправлений: 1)
Ответ на: комментарий от erfea

0-20 в минуту. Иногда бывает 2-3 единовременно. Приблизительно каждый 4 попадает в лог. Таких чтобы более одного параллельно процентов 10 от силы и они уже по 4-12 секунд выполняются.

блин, надо в документации посмотреть, у меня почему-то воспоминания что memory engine однопоточный + при update лочится вся таблица

ХЗ, не трогал, где посмотреть?

как всегда

SHOW GLOBAL VARIABLES LIKE '%heap%';
adn ★★★★
()
Ответ на: комментарий от adn

блин, надо в документации посмотреть, у меня почему-то воспоминания что memory engine однопоточный + при update лочится вся таблица

Даже если так, не думаю что это проблема: «Count: 2017 Time=2.49s (5019s) Lock=0.15s (312s)»

как всегда

Действительно: «max_heap_table_size | 16777216»

erfea ★★★★★
() автор топика
Ответ на: комментарий от erfea

Дроплет на DO за 6$

SQL statistics:
    queries performed:
        read:                            20902
        write:                           5972
        other:                           2986
        total:                           29860
    transactions:                        1493   (149.21 per sec.)
    queries:                             29860  (2984.20 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          10.0049s
    total number of events:              1493

Latency (ms):
         min:                                    4.31
         avg:                                    6.69
         max:                                   10.50
         95th percentile:                        8.58
         sum:                                 9994.95

Threads fairness:
    events (avg/stddev):           1493.0000/0.00
    execution time (avg/stddev):   9.9950/0.00
Лицорука!

erfea ★★★★★
() автор топика