Запросы обновления MySQL замедлились во всех базах данных

Question

У меня есть сервер ubuntu (2x 3.0Ghz quad core, 16GB ram и raid 1 на 15k sas-дисках), работающий с обычным стеком LAMP, где примерно 5 клиентов подключают второй скрипт php. Клиенты обмениваются небольшим количеством информации и данные обновляются в базе данных MySQL.

В фоновом режиме на сервере у меня есть сценарий php, который анализирует данные один раз в секунду и обновляет базу данных.

Есть только пара записей, которые обновляются снова и снова, а не вставлены, поэтому размеры таблицы ДЕЙСТВИТЕЛЬНО маленькие (максимум 4 строки).

Это говорит о том, что я обычно открываю сеанс ssh, наблюдая скорость, с которой работает фоновый скрипт. Спустя месяц подряд, когда запросы SELECT и UPDATE занимают около 100 микросекунд (0,0001 секунд), внезапно UPDATE начал принимать 20000+ микросекунд (0,02 секунды) на запрос, независимо от того, какая база данных, какой столбец был использован или обновлен (первичный ключ или иным образом) и т. д. Я перезапустил все, включая сервер, удалил все мои базы данных (только те, которые я создал, а не системные базы данных), заблокировал клиентов, запустил запросы из консоли mysql и PhpMyAdmin, и результат тоже самое.

Вот пример, запускается из консоли без нагрузки или клиентов, подключенных к серверу:

mysql> CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET utf8 */; 
Query OK, 1 row affected (0.00 sec) 

mysql> CREATE TABLE `test` (
    `idtest` int(11) NOT NULL AUTO_INCREMENT, 
    `field1` varchar(64) NOT NULL, 
    `field2` varchar(64) NOT NULL, 
    `field3` int(11) NOT NULL, 
    PRIMARY KEY (`idtest`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 
Query OK, 0 rows affected (0.14 sec) 

mysql> INSERT INTO `test`.`test` (`idtest`, `field1`, `field2`, `field3`) VALUES (NULL, 'Testing', 'None', '0'); 
Query OK, 1 row affected (0.02 sec) 

mysql> SELECT * FROM test; 
+--------+---------+--------+--------+ 
| idtest | field1 | field2 | field3 | 
+--------+---------+--------+--------+ 
|  1 | Testing | None |  0 | 
+--------+---------+--------+--------+ 
1 row in set (0.00 sec) 

mysql> UPDATE `test`.`test` SET `field3` = '1' WHERE `test`.`idtest` = 1; 
Query OK, 1 row affected (0.03 sec) 
Rows matched: 1 Changed: 1 Warnings: 0 

Из приведенного выше примера также появляется ВСТАВИТЬ влияет. Я запустил те же запросы выше на другом сервере с примерно 1/10 ресурсов, и он запускает запросы в 100-200 мкс, как и ожидалось. Я подозреваю, что это имеет какое-то отношение к кешу InnoDB, но я могу ошибаться.

Вот некоторая информация на сервере и MySQL:

средние нагрузки: Средняя нагрузка: 0,04, 0,04, 0,05

Сервер: Localhost через сокет UNIX

Тип

Сервер: MySQL

Версия сервера: 5.6.28-0ubuntu0.15.04.1 - (Ubuntu)

Версия протокола: 10

Пользователь: корень @ локальный

Сервер кодировки: UTF-8 Unicode (utf8)

и

mysql> SHOW VARIABLES LIKE '%query%'; 
+------------------------------+-----------------------------------+ 
| Variable_name    | Value        | 
+------------------------------+-----------------------------------+ 
| binlog_rows_query_log_events | OFF        | 
| ft_query_expansion_limit  | 20        | 
| have_query_cache    | YES        | 
| long_query_time    | 10.000000       | 
| query_alloc_block_size  | 8192        | 
| query_cache_limit   | 1048576       | 
| query_cache_min_res_unit  | 4096        | 
| query_cache_size    | 16777216       | 
| query_cache_type    | OFF        | 
| query_cache_wlock_invalidate | OFF        | 
| query_prealloc_size   | 8192        | 
| slow_query_log    | OFF        | 
| slow_query_log_file   | /var/lib/mysql/xxxxx-slow.log | 
+------------------------------+-----------------------------------+ 
13 rows in set (0.00 sec) 

и

mysql> SHOW VARIABLES LIKE '%cache%'; 
+--------------------------------+----------------------+ 
| Variable_name     | Value    | 
+--------------------------------+----------------------+ 
| binlog_cache_size    | 32768    | 
| binlog_stmt_cache_size   | 32768    | 
| have_query_cache    | YES     | 
| host_cache_size    | 279     | 
| innodb_disable_sort_file_cache | OFF     | 
| innodb_ft_cache_size   | 8000000    | 
| innodb_ft_result_cache_limit | 2000000000   | 
| innodb_ft_total_cache_size  | 640000000   | 
| key_cache_age_threshold  | 300     | 
| key_cache_block_size   | 1024     | 
| key_cache_division_limit  | 100     | 
| max_binlog_cache_size   | 18446744073709547520 | 
| max_binlog_stmt_cache_size  | 18446744073709547520 | 
| metadata_locks_cache_size  | 1024     | 
| query_cache_limit    | 1048576    | 
| query_cache_min_res_unit  | 4096     | 
| query_cache_size    | 16777216    | 
| query_cache_type    | OFF     | 
| query_cache_wlock_invalidate | OFF     | 
| stored_program_cache   | 256     | 
| table_definition_cache   | 615     | 
| table_open_cache    | 431     | 
| table_open_cache_instances  | 1     | 
| thread_cache_size    | 8     | 
+--------------------------------+----------------------+ 
24 rows in set (0.00 sec) 

my.cnf:

[mysqld] 
innodb_autoinc_lock_mode=0 

И, наконец:

ubuntu@xxxxx:~$ df 
Filesystem      1K-blocks Used Available Use% Mounted on 
udev        8202368  0 8202368 0% /dev 
tmpfs       1642808 9600 1633208 1% /run 
/dev/mapper/xxxxx--vg-root 53035144 7827988 42490076 16%/
tmpfs       8214020  0 8214020 0% /dev/shm 
tmpfs        5120  0  5120 0% /run/lock 
tmpfs       8214020  0 8214020 0%  /sys/fs/cgroup 
/dev/sda1       240972 112893 115638 50% /boot 
tmpfs       1642808  0 1642808 0% /run/user/1000 

Любые идеи? Заранее благодарю за помощь!

Обновления редактирование:

Учитывая очень странное и внезапное начало вопроса, я начинаю подозревать, что может быть связанно с оборудованием.

Я полностью очистил MySQL от сервера и переустановил его из хранилища, и это не повлияло на ситуацию. Я запускаю рейд 1 с двумя дисками svc 15k на Perc6i - я собираюсь начать там. Это может привести к большей проблеме ServerFault, чем к StackOverflow. Я отчитаюсь после того, как сделаю больше копания.

Answer 1

Если это СУДЕБНО началось гораздо дольше, на ум приходит на ум.

Я не буду говорить о очевидных вещах, таких как механика блокировки, на которую можно положиться, чтобы внедрять одновременные обновления на месте.

Я бы предположил, что вы пересекли порог размера файла, где теперь требуется, скажем, двухсторонняя дисковая блокировка, а не односторонняя блочная адресация. Это будет означать, что каждый отдельный вызов для выбора следующего блока диска в логической последовательности будет намного медленнее. Каждый конкретный ввод-вывод будет наказываться. Я отношусь к ACTUAL I/O, как к чему-то, что выходит и попадает в очередь хеш-блоков диска, что влечет за собой (в какой-то момент) задачу контроллера диска, а не просто чтение read() и извлечение данных, которые уже были предварительно выбраны в соответствии с последний диск ввода-вывода.

Это просто догадка.

Вы действительно расстроены около 20 000 usec = 0,2 мс?

Answer 2

Если вы хотите улучшить скорость обновления, подумайте об использовании полей char instead of varchar и создайте unclustered indexes в полях, используемых для сравнения в ваших предложениях.

Кроме того, не измеряйте скорость обновления, запустив один запрос, потому что в запросе обновления, если у вас есть механический жесткий диск, spin up time может повлиять на результаты. Windows может кэшировать файлы базы данных и обслуживать данные из RAM. Отключите службу суперкары и run loops, чтобы проверить задержки отсрочки.