Почему запрос на вставку иногда занимает так много времени?

Это довольно простая проблема. Вставка данных в таблицу обычно работает нормально, за исключением нескольких случаев, когда запрос на вставку занимает несколько секунд. (Я не пытаюсь выполнить массовую вставку данных.) Поэтому я настраиваю моделирование процесса вставки, чтобы выяснить, почему выполнение запроса на вставку иногда занимает более 2 секунд. Джошуа предположил, что индексный файл может быть изменен; Я удалил идентификатор (поле первичного ключа), но задержка все равно возникает.

У меня есть таблица MyISAM: daniel_test_insert (эта таблица начинается с полностью пустой):

create table if not exists daniel_test_insert ( 
    id int unsigned auto_increment not null, 
    value_str varchar(255) not null default '', 
    value_int int unsigned default 0 not null, 
    primary key (id) 
)

I вставьте в него данные, и иногда выполнение запроса на вставку занимает> 2 секунд. В этой таблице нет чтения - только последовательная запись с помощью однопоточной программы.

Я выполнил один и тот же запрос 100 000 раз, чтобы выяснить, почему этот запрос иногда занимает много времени. Пока это кажется случайным явлением.

Этот запрос, например, занял 4,194 секунды (очень много времени для вставки):

Query: INSERT INTO daniel_test_insert SET value_int=12345, value_str='afjdaldjsf aljsdfl ajsdfljadfjalsdj fajd as f' - ran for 4.194 seconds
status               | duration | cpu_user  | cpu_system | context_voluntary | context_involuntary | page_faults_minor
starting             | 0.000042 | 0.000000  | 0.000000   | 0                 | 0                   | 0                
checking permissions | 0.000024 | 0.000000  | 0.000000   | 0                 | 0                   | 0                
Opening tables       | 0.000024 | 0.001000  | 0.000000   | 0                 | 0                   | 0                
System lock          | 0.000022 | 0.000000  | 0.000000   | 0                 | 0                   | 0                
Table lock           | 0.000020 | 0.000000  | 0.000000   | 0                 | 0                   | 0                
init                 | 0.000029 | 0.000000  | 0.000000   | 1                 | 0                   | 0                
update               | 4.067331 | 12.151152 | 5.298194   | 204894            | 18806               | 477995           
end                  | 0.000094 | 0.000000  | 0.000000   | 8                 | 0                   | 0                
query end            | 0.000033 | 0.000000  | 0.000000   | 1                 | 0                   | 0                
freeing items        | 0.000030 | 0.000000  | 0.000000   | 1                 | 0                   | 0                
closing tables       | 0.125736 | 0.278958  | 0.072989   | 4294              | 604                 | 2301             
logging slow query   | 0.000099 | 0.000000  | 0.000000   | 1                 | 0                   | 0                
logging slow query   | 0.000102 | 0.000000  | 0.000000   | 7                 | 0                   | 0                
cleaning up          | 0.000035 | 0.000000  | 0.000000   | 7                 | 0                   | 0

(Это сокращенная версия команды ПОКАЗАТЬ ПРОФИЛЬ, я выбросил все столбцы, которые были равны нулю.)

Теперь в обновлении невероятное количество переключений контекста и незначительных ошибок страниц. Opened_Tables увеличивается примерно на 1 каждые 10 секунд в этой базе данных (не исчерпывается пространство table_cache)

Статистика:

• MySQL 5.0.89

• Аппаратное обеспечение: 32 гигабайта оперативной памяти / 8 ядер @ 2,66 ГГц; raid 10 SCSI жесткие диски (SCSI II ???)

• У меня был запрос на жесткие диски и raid-контроллер: об ошибках не сообщается. )

  Теперь в обновлении невероятное количество переключений контекста и незначительных ошибок страниц. Opened_Tables увеличивается примерно на 1 каждые 10 секунд в этой базе данных (не исчерпывается пространство table_cache)

  Статистика:

  • MySQL 5.0.89

  • Аппаратное обеспечение: 32 гигабайта оперативной памяти / 8 ядер @ 2,66 ГГц; raid 10 SCSI жесткие диски (SCSI II ???)

  • У меня был запрос на жесткие диски и raid-контроллер: об ошибках не сообщается. )

    Теперь в обновлении невероятное количество переключений контекста и незначительных ошибок страниц. Opened_Tables увеличивается примерно на 1 каждые 10 секунд в этой базе данных (не исчерпывается пространство table_cache)

    Статистика:

    • MySQL 5.0.89

    • Аппаратное обеспечение: 32 гигабайта оперативной памяти / 8 ядер @ 2,66 ГГц; raid 10 SCSI жесткие диски (SCSI II ???)

    • У меня был запрос на жесткие диски и raid-контроллер: об ошибках не сообщается. Процессоры простаивают примерно на 50%.

    • iostat -x 5 (сообщает об использовании жестких дисков менее 10%) наверху средняя загрузка отчета около 10 за 1 минуту (нормальное явление для нашей машины с базами данных)

    • Место подкачки занято 156 КБ (32 гигабайта оперативной памяти)

    Я не могу понять, что вызывает такое отставание в производительности. Этого НЕ происходит на наших ведомых устройствах с низкой нагрузкой, а только на мастере с высокой нагрузкой. Это также происходит с таблицами памяти и innodb. У кого-нибудь есть предложения? (Это производственная система, так что ничего экзотического!)