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

Вот сейчас например вот такая запись присутствует:

Id    User    Host    DB    Command    Time    State    Info
8755    root    localhost    se    Query    4091    Repair with keycache    ALTER TABLE T_Temp ENABLE KEYS

ниче не понимаю...

Отредактированно Shopen (24.11.2007 21:35:36)

ALTER TABLE T_Temp ENABLE KEYS

У Вас кто-то альтерит таблички. ENABLE KEYS перестраивает все ключи таблички,
поэтому оно может тормозить. Особенно оно будет тормозить, если у Вас маленькие
буферы в памяти под ключи. Всё, что обращается к этой таблице, разумеется, будет
ждать изменения метаданных, а всё, что обращается к другим таблицам, будет
тормозить, потому что такой альтер на большой таблице создает _очень_ большую
дисковую активность. Увеличение буфера для ключей должно помочь.

paulus написал:

ALTER TABLE T_Temp ENABLE KEYS

У Вас кто-то альтерит таблички. ENABLE KEYS перестраивает все ключи таблички,
поэтому оно может тормозить. Особенно оно будет тормозить, если у Вас маленькие
буферы в памяти под ключи. Всё, что обращается к этой таблице, разумеется, будет
ждать изменения метаданных, а всё, что обращается к другим таблицам, будет
тормозить, потому что такой альтер на большой таблице создает _очень_ большую
дисковую активность. Увеличение буфера для ключей должно помочь.

буфер для ключей это key_buffer_size? помоему он у меня достаточно большой стоит, сейчас не могу посмотреть, только завтра.

дело в том, что это работает уже давно, более менее существенного прироста в обьеме баз данных нет, размер таблиц порядка 2-4G
а тут тормоза скачкообразно подскочили. Раньше скрипт генерящий базу отрабатывал за ~1.5 часа а теперь 4-5.

Что могло такого случится, вот чего мне не понятно

P.S. Есть переменная repair_threads, как то так - какое значение имеет смысл ставить на 4 процессорной системе?
1? 2? 4?

я так понимаю она напрямую влияет на скорость перегенерации индесков, разводя их по процессорам, или нет?

Отредактированно Shopen (25.11.2007 03:48:24)

Я вот тоже думаю, что то таки с файловой системой или i/o
код не менялся, индексы не добавлялись.

не знаете каких нибудь user-friendly unix-утилит, которыми можно потестировать производительность например той же файловой системы?

еще маленький вопрос  - по умолчанию mysql юзает системный /tmp или какой то свой? Имеет ли смысл тут что то менять, например если базы данных на одном разделе (Raid10) а система на другом (Raid1) - то где лучше держать tmp - на разделе с данными или таки на системном.

В первом варианте при использовании tmp пересекаться будут запросы mysql с самимм собой, а во втором mysql с системными (логи и пр.)
Мне что то подсказывает, что лучше tmp держать вместе с данными, но аргументов нет
Отдельный диск под tmp не рассматриваю - нет его, диска

P.S. multi_thread я как то пробовал - наблюдал существенный прирост в скорости реиндексирования (напр. при ALTER TABLE), при этом реально работают несколько камней, а потом они кучей пишутся на диск

Отредактированно Shopen (25.11.2007 13:54:46)

Машинка - типичный LAMP. (SUSE SLED10)
Несколько сайтов с весьма большой посещаемостью, несколько с поменьше. Больше ничего особенного нет

paulus написал:

А, если не секрет, зачем нужно восстановление дампа на регулярной основе?

Это не восстановление дампа, это перенос.

Есть одна база, расположенная на локальной машине-реестре, примерно 15G, которая обновляется непрерывно. Но по историческим причинам (база ведется почти 10 лет) - формат хранения dbf. Для нее написано масса софта, который с ней работает

C другой стороны есть поисковик, в котором можно искать из мира в этой базе. Каждый день по ночам одна софтина с локальной машины делает текстовый tab-файл, который заливает на сервер. Сервер по крону перегенерирует поисковые базы из этого файла. Сделать обновление дельтами крайне проблематично, хотя мы про это подумываем на перспективу.

Более того есть планы и локальный реестр перевести на не BDE-движок и заюзать что нибудь типа mysql или oracla-а. Но тут пока конь не валялся, надо понять какая СУБД нам лучше, переписать ту самую кучу софта(а Delphi-программист у нас один и это не я ) и пр.


Вот примерно так.

paulus написал:

Вас спасет ODBC драйвер MySQL, который легко подключается к BDE

Пробовали. Конвертация всей базы занимает примерно 8 часов.
я попробовал понять почем так долго, обнаружил в логе mysql - что вставка идет вот такими вот записями:

INSERT INTO .....
SELECT @@IDENTIFY
INSERT INTO .....
SELECT @@IDENTIFY
....

При этом к mysql приходит порядка 100 тыс. запросов в минуту. из них половина вставок, половина select identity.

селекты эти никому не нужны, потому что вставки идут подряд и в одну таблицу. Но с другой стороны mysql я так понимаю вынужден физически записывать каждую запись на диск, чтобы вернуть достоверный LID. Как это отключить я не нашел, а 8 часов это нереально много

paulus написал:

А как Вы делаете дамп из dbf? Один инсерт на 100 строк работает в несколько раз
быстрее, чем 100 инсертов по 1 строке.

Это я знаю, но в софте изпользуется ADOTable и там нет запросов, там что то типа вставить строку, извлечь итп, а ADO уже преобразует это в запросы и через ODBC передает в Mysql, как то так. Вообще я не очень знаю как это работает, это не моя программа, у меня только более менее общее понимание.

paulus написал:

Кстати, можете в начало дампа написать LOCK TABLES ... WRITE - это несколько увеличит
скорость загрузки данных из дампа.

Попробую, спасибо. А это действительно ускоряет процесс при загрузке дампа с нуля в пустую таблицу?

Ясно.

По последней информации стало известно, что проблемы в дисковой системе. БД располагается на 10 райде из четырех дисков. Один из винтов судя по всему стал сбоить или его порт на контроллере. Вынули винт - все вернулось к предыдущим скоростям. Щас тестируем винта, готовим замену.

Кстати, может есть какой то опыт по конфигурации дисковой подсистемы? Какой Raid предпочтительней? Какие диски/контроллеры?

paulus написал:

Да, конечно, так оно по крайней мере делает "вставить", а не
"заблокировать-вставить-разблокировать".

Я думал, что при LOAD DATA блокировка происходит одна...

При LOAD DATA - да. Вы просто писали INSERT-SELECT-INSERT...

Хороших железок предложить не могу. Опыт показывает, что железки
хуже, чем md-raid. Работают медленнее и куда менее настраиваемые.
Возможно, я просто их не встречал - хороших

С другой стороны, софтверно Вы никогда не сделаете battery back