Форум пользователей MySQL

Ну... возможно, на дисковую часть нагрузка и есть, но она ведь должна быть достаточно стабильна.
То, что база не залезает в своп - в этом я уверен. И память ещё свободная есть.. На сервере вообще крутится только mysql, так что вся нагрузка только от него.
Да и с дисковой частью там тоже, вроде как всё должно быть неплохо - специально поставили аппаратный RAID1.

Просто насколько я помню freebsd если своп использовал, он потом пишет в топе, что сколько-то там "used". А у меня там всё чисто пока..

А RAID1 должен вообще-то давать увеличенную скорость чтения, что мне как раз интересно, поскольку у меня больше селектов.

show processlist в файлике есть, вдумчиво читал - ничего не обнаружил..

Сейчас решил попытаться, раз такие подозрения на диск, продублировать часть табличек и сделать их memory. Но тут надо ещё решить проблему с поддержанием их в актуальном состоянии в случае рестарта сервера
Так что, возможно, проблему удастся решить таким образом..

RAID1 никогда не дает более высокую скорость чтения, т.к. читает с двух дисков
всегда, чтобы гарантировать целостность данных. Увеличение скорости дает RAID0
(или комбинации типа RAID10).

iostatом не смотрели?

Т.е. он реально упирается в диск при этом, судя по размеру очереди ожидания.

Давайте еще раз пройдемся по предыстории - таблички MyISAM или InnoDB? Если
InnoDB - не маленький ли размер лога в памяти? Если MyISAM - достаточно ли памяти
для сортировки/ключей?

Такое ощущение, что он копит какое-то количество данных в памяти, после чего
выплескивает все скопом на диск. Если памяти дать больше - часть данных можно
будет вообще не скидывать на диск (временные данные), а нужные данные можно
будет раскидывать по времени более равномерно.

Опять-таки, это предположение. Я бы смотрел в лог запросов, скорее всего, что-то
в нем подскажет, что не так.

insert делается в таблицу, в которой к концу суток более 2 миллионов записей (в полночь создаётся новая таблица), сама таблица весит 60 метров, а ещё 120 метров - индексы для неё (лишних индексов, с моей точки зрения, там нет). Это самая большая таблица, есть и другие, но они используются не так интенсивно. К этой же таблице у меня до 100 запросов в секунду на наличие уже подобных полей, но, насколько я понимаю, непосредственно до таблицы дело даже не доходит, потому что всё что нужно уже есть в одном из индексов.
Вставляю данные я только insert delayed, поэтому тут, я думаю не должно быть проблемы..
key_buffer_size у меня был 384M. Сейчас увеличил до 768 - абсолютно та же картина.
sort_buffer_size я не менял - он у меня 512К, но я и не сортирую никакие данные.
Запросы у меня однотипные, поэтому если бы какой-то тормозил, то я бы уже знал.
После того, как сделал поменьше время "медленного запроса" - запросы стали попадать туда почаще, но они там вполне стандартные и их очень мало по отношению к общему количеству.

Хм.. ну можно попробовать.
Честно говоря, я считал, что это основное преимущество MyISAM в быстром чтении. И 23 запроса - это в среднем только.. вот например, в 00:00:01 - сегодня было 160 вставок.. а селектов из этой же таблицы - примерно столько же, даже чуть больше. InnoDB это всё ещё потянет? А если будет в два раза больше? Я могу продублировать часть этой таблицы табличкой в memory - тогда селектов будет в сотни раз меньше - такой вариант, наверное, сильно облегчит жизнь базе?

Ну вот.. новую таблицу создал уже в InnoDB - действительно, с диском ситуация стала намного лучше.

                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  b
amrd0      0.0 207.8     0.0  3324.6    0   1.4  11
amrd0      0.0 197.8     0.0  3164.8    1   0.6  12
amrd0      0.0 187.8     0.0  3005.0    0   0.6  12
amrd0      0.0 193.8     0.0  3100.9    0   0.6  12
amrd0      0.0 205.8     0.0  3292.6    0   0.6  13
amrd0      0.0 207.8     0.0  3324.6    1   0.6  13
amrd0      0.0 197.8     0.0  3164.8    0   0.6  12
amrd0      0.0 227.8     0.0  3644.3    1   0.6  14
amrd0      0.0 197.8     0.0  3164.7    0   0.6  12

Посмотрю как будет с производительностью, когда таблица вырастет. Если у меня innodb_buffer_pool_size заведомо больше всех моих таблиц вместе взятых, то, наверное, при чтении у меня и никаких затыков со скоростью не будет? Вообще, есть ли смысл те таблички на memory, которые я создал (и обновляю их раз в минуту актуальными данными) перевести на InnoDB и рассчитывать, что потерь в скорости не будет, потому что таблицы будут читаться из памяти?

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

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

Если решите создавать поле - подумайте, может быть, стоит сделать из него primary key -
короткие основные ключи на таблице очень нравятся InnoDB.

Подвох только в том, что если строчки удаляются, то количество не соответствует max(id).

Кстати, если Вам нужно не точное, а приблизительное количество строк, то можете использовать
SHOW TABLE STATUS LIKE 'tablename' - эта операция выполняется очень быстро и возвращает
приблизительное количество строк.

paulus написал:

RAID1 не увеличивает ни скорость записи, ни скорость чтения. Это просто обеспечение
толерантности к падению одного из дисков.

скорость чтения все таки увеличивается, так как чтение идет в несколько потоков со всех накопителей (при отсутствии записи опять же, хотя это уже тонкости реализации контроллеров).

Ну я вообще то не спец, но думаю, что RAID 1 может теоретически выдавать при чтении удвоенную скорость по сравнению с одним таким же винтом.

Логика подсказывает следующую элементарную схему. Допустим на контроллер приходит запрос на блок данных D. Контроллер разбивает этот блок на два A и B, которые читает с двух винтов одновременно. "Сверки" при этом не происходит. Если один из блоков A или B не считался, соответствующий носитель метится как битый и выбывает из процесса с вытекающими. Контроль происходит _при записи_, т.е. пока запись одного и того же блока данных не произведена на каждый диск зеркала оно не считается рабочим.

ну и плюс аппаратный кэш еще чуток добавляет

Отредактированно Shopen (01.07.2008 13:02:38)