Это довольно простая проблема. Вставка данных в таблицу обычно работает нормально, за исключением нескольких раз, когда запрос вставки занимает несколько секунд. (Яне пытаясь выполнить массовую вставку данных.) Поэтому я настроил симуляцию для процесса вставки, чтобы выяснить, почему для выполнения запроса вставки иногда требуется более 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) 
)

Я вставляю в него данные, и иногда для выполнения запроса на вставку требуется более 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

(Это сокращенная версия команды SHOW PROFILE, я выкинул все столбцы, которые были равны нулю.)

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

Статистика:

MySQL 5.0.89

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

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

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

В разделе подкачки использовано 156 КБ (32 ГБ оперативной памяти)

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