|
|
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Как определить что узким местом стал именно диск? Вродк по Profiler не определить что проблема в нём. Про процессор всегда можно сказать - загружен он на 100% или меньше, и кто кто его грузит, а есть ли какие-то утилиты чтобы определить тоже самое (загруженность диска в процентах и какая программа грузит) под Windows XP? Или это позволяют какие-то внутренние утилиты MySQL? Тормозит конкретная таблица (на движке MyISAM). Таблица занимает около 18Gb (20 полей Integer, DateTime и VarChar не более 15 символов, и одно Text которое создаёт объём). Таблица очень фрагментирована из-за того что данные переодически подкидываются, и когда дефрагментатор показывает что в ней больше 20 тысчь фрагментов, делаю дефрагментацию всего диска программой Auslogics Disk Defrag Professional с приоритом по свободному месту, так как при дефрагментации обычным дефрагментатором входящим в виндоус и при стандартной дефрагментации Auslogics Disk Defrag Professional этот файл остаётся без изменений и в финальных отчётах так и пишется что осталось несколько дефрагментированных файлов и показывает log-файл из Apache и эту таблицу в каждой из которых несколько тысячь фрагментов (что интересно, даже если я в дефрагментаторе указываю дефрагментировать только один конкретный файл, при этом разумеется на время дефрагментации выключаю сервис MySQL и Apache то эти файлы не дефрагментириуются, а если указываешь что надо весь диск дефрагментировать с приоритетом по свободному месту, тоесть когда он сгоняет все файлы к началу диска и концовку физически оставляет пустой, тогда дефрагментируются и эти файлы). Но по идее эта дефрагментация не должна влиять, так как поиск происходит только по полям которые в индексе, а индексный файл цельный (не фрагментированный), а запрос типа: Код: sql 1. тоесть поиск и сортировка по полям которые в индексе (в этом случае вроде как MySQL даже не будет открывать файл с данными), хотя вроде как при сортировках MySQL задействует диск (именно по этому и считаю что узое место диск). При простом запросе к такой таблице результат получаю черз 10-15 секунд, а если паралельно запустить почти такой же запрос то оба процесса замерают и комп шуршит диском неизвестно сколько (через 5-10 минут мне обычно надоедало и я через сервисы говорил MySQL-серверу рестартироваться и запускал процессы по отдельности). P.S. Слышал, что если использовать InodDB, то вроде MySQL сам мледит за фрагментацией всей таблицы (так как она вся хранится в одном файле). Действительно ли это так? Хотя на данный момент перейти на другой движок не могу, хоть и слышал что в последнем MySQL уже и в InodDB есть FullText, но у меня бекапирование осуществляется в виде файлов, так как таблица с 10 миллионами записями копируется за пару минут, а чтобы снять с неё дамп (а тем более восстановить) уходит больше часа... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.05.2014, 15:37:58 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSkyа запрос типа: Код: sql 1. тоесть поиск и сортировка по полям которые в индексе (в этом случае вроде как MySQL даже не будет открывать файл с данными)Откуда такой странный вывод? Во-первых, в индексе явно нет всех полей таблицы, т.е. лазить в в файл с данными придется однозначно. Во-вторых, не глядя в план, вообще не факт, что для этого запроса будет использоваться индекс. Зависит, как минимум, от состава индекса и селективности условия Data>'2014-05-04'. А за фрагментацией на уровне файловой системы пока рано гоняться, пока еще в MySQL все сыро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 13:27:56 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
miksoftВо-первых, в индексе явно нет всех полей таблицы, т.е. лазить в в файл с данными придется однозначно.Разумеется придётся лазить в файл с данными, но я имел в виду что даже если где-то для выбоки надо сделать перебор по большому поличеству полей - то этот перебор произойдёт по индексному файлу, а уже потом выбронные по ограничению limit 50 будут выбраны из файла с данными, а эта операция произойдёт быстро (тоесть гоняться будет индексный файл). miksoftВо-вторых, не глядя в план, вообще не факт, что для этого запроса будет использоваться индекс. Зависит, как минимум, от состава индекса и селективности условия Data>'2014-05-04'.Тут, как ни странно вы оказались очень правы, в примере видно что при первом запросе вместо индекса поля по которому ищу используется первичный ключ `ID`. По поводу экплэйна, вот пример: Код: sql 1. idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1SIMPLETablicaindexTipPRIMARY41370Using whereВремя выполнения 3.8 секунды И тоже самое без лимита: Код: sql 1. idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1SIMPLETablicarefTipTip12const8765"Using where; Using filesort"Время выполнения 2:31 минуты!!! При этом если я вместо "SELECT *" напишу "SELECT `ID`" то скорость не меняется (ну бегает в пределах погрешности 2:29-2:36 для второго запроса). P.S. Размер индексного файла всего 25Мб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 17:33:20 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSkyПо поводу экплэйна, вот пример:А причем тут это запрос? Вы показывайте план исходного запроса. И, кстати, предложите запросам из примера индекс (`Tip`, `ID`). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 17:46:10 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
miksoftА причем тут это запрос? Вы показывайте план исходного запроса. А разве есть какая-то разница? Это всё к одной таблице обращения... Там десятки схожих запросов (везде по индексированному полю), а результат примерно у всех одинаковый: если лимитированный одиночный запрос - то время обработки до 10 секунд, а если запустить 2 запроса одновременно (ну точнее второй запрос запускается до завершения первого), то выполнение идёт больше 10 минут... Или вы так принципиально хотите именно экплэйн с полем типа datetime? miksoftИ, кстати, предложите запросам из примера индекс (`Tip`, `ID`). Вы думаете это будет настолько актуально когда индексный файл занимает всего 25Мб? Я согласен что это облегчит базе поиск по данной связке. Но тогда мне придётся создать сотню новых индексов! (ведь пользователь может искать среди десяти проиндексированных полей, и дальше сортировка может быть тоже по любому из этих полей, в зависимости от того на какую колонку в таблице пользователь нажмёт). А ведь по экплэйну видно что результатом является всего 1000 записей в лимитированном и всего 8000 записей в полном запросе. На сортировку данного количества даже секунды много! В самой таблице меньше 250 тысячь записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 18:50:04 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSky, если запустить торент, то он показывает внизу предупреждение - шдд перегружен и резко падает скорость передач данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 19:19:35 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSkyА разве есть какая-то разница?Есть. InterSkyИли вы так принципиально хотите именно экплэйн с полем типа datetime?Я "принципиально" ничего не хочу. Вы показали проблемный запрос, а разбираться в нем не хотите. А мы, даже при всем желании, не можем из-за недостатка информации. InterSkymiksoftИ, кстати, предложите запросам из примера индекс (`Tip`, `ID`). Вы думаете это будет настолько актуально когда индексный файл занимает всего 25Мб?Актуальность слабо связана с расзмером индексного файла. Если текущее быстродействие устраивает, то и не трогайте. Индекс я предлагал больше в исследовательских целях. InterSkyА ведь по экплэйну видно что результатом является всего 1000 записей в лимитированном и всего 8000 записей в полном запросе. На сортировку данного количества даже секунды много! InterSkyТаблица занимает около 18GbInterSkyВ самой таблице меньше 250 тысячь записей.Вообще-то это несколько сотен мегабайт. И за секунду их никак не отсортируешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 19:23:23 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
miksoftЯ "принципиально" ничего не хочу. Вы показали проблемный запрос, а разбираться в нем не хотите. А мы, даже при всем желании, не можем из-за недостатка информации.Может вы имеете ввиду структуру таблицы? Или что тогда имеете в виду под фразой "план исходного запроса", раз explain не устроил? miksoftИндекс я предлагал больше в исследовательских целях.Я постараюсь ночью сделать. При изменении индекса MySQL ведь будет физически пересоздавать всю таблицу, а это по времени долго (да и откровенно говоря у меня сейчас нет столько свободного места). Другое дело что после дефрагментации скорость увеличивается в разы (но за день-два опять падает из-за увеличения фрагментирования файла). miksoftInterSky...Таблица занимает около 18Gb... ...В самой таблице меньше 250 тысячь записей... ...результатом выборки является всего 1000 записей... На сортировку данного количества даже секунды много! Вообще-то это несколько сотен мегабайт. И за секунду их никак не отсортируешь.Не соглашусь (или вы можете более равёрнуто аргументировать такую скорость?) Да, записи большие. Но я рассказывал структуру: десяток коротких полей Integer, VarChar, DateTime и одно Text более 60Кб. Но: 1) Я говорил что если меняю " SELECT * from ... " на " SELECT ID from ... ", то время практически НЕ меняется. 2) Разве сортирока производится всего набора данных? Почему-то я уверен что вначале в индексном файле выбираются все записи соответсвующие `Tip` = 'AA', затем из индексного же файла берутся значения поля `ID` и происходит сортировка, а уже затем из файла с данными достаются сами данные и передаются на выход... Или вы хотите сказать что MySQL собирает неотсортированный набор 8000*60Кб=480Мб и потом 2 минуты сортирует их на жёстком диске? (хотя в случае с select ID from объём выборки и мегабайта не займёт). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 21:30:01 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSkymiksoftЯ "принципиально" ничего не хочу. Вы показали проблемный запрос, а разбираться в нем не хотите. А мы, даже при всем желании, не можем из-за недостатка информации.Может вы имеете ввиду структуру таблицы? Или что тогда имеете в виду под фразой "план исходного запроса", раз explain не устроил?Вы план исходного запроса (т.е. explain) не показывали. Именно этим он и не устроил :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 21:44:12 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSkyРазве сортирока производится всего набора данных?К сожалению, да. По крайней мере, обратной ситуации мне не доводилось наблюдать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2014, 21:45:13 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
а что покажет Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2014, 02:35:48 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Из-за отсутсвия свободных 18Гб мне так и не удалось добавить двойной индекс чтобы проверить насколько изменится производительность при нём (хотя как я говорил - это не будет решением, так как я не могу поставить двойные индексы по всем вариантам поиск+сортировка). Но зато за ночь я сделал дефрагментацию (как я уже говорил ранее - реально дефрагментировать файл Tablica.MYD может только Auslogics Disk Defrag Professional и исключительно в режиме Free space optimization, потому что в обычном режиме большие файлы с большим количеством фрагментов полностью игронирует как стандартный дефрагментатор виндоуса, так и используемый мной Auslogics Disk Defrag Professional даже если я указываю что мне надо дефрагментировать только один мой конкретный файл). Итак после дефрагментации запрос выплняемый за "2:31 минуты" стал выплняться за 0.6 секунды, а лимитированный который выполнялся "3.8 секунды" стал выполняться за 0.02 секунды. Но это сразу после дефрагментации, а спустя пару дней всё вернулось примерно к прежним тормозным скоростям. Сегодня даже был случай: запустил цикл апдейтов: Код: sql 1. (ясное дело вместо "..." подставляются разные значения) Обновления выполнялись быстро (там куча расчётов по этому скорость 3-4 обновления в секунду считаю отличной), и паралельно запустил лимитированный запрос: Код: sql 1. (который в самые плохие времена выполняется за несколько секунд, а после дефрагментации как писал выше - выполнился за 0.02 секунды), и после запуска этого запроса всё повисло на 12 минут!!! Я подключился к MySQL через третий клиент и смотрел SHOW FULL PROCESSLIST - время выполнения у update и select запросов было одинаковое (тоесть за время сэлэкта не проскочил ни один апдэйт). Причём всё это время (все 12 минут) компьютер нещадно молотил жёстким диском... А нагрузка на процессор была почти нулевой (mysqld иногда поднимался до 2% процессорного времени, а больше ничего и не работало). Может есть какая-то утилита под виндоус которая показывает с каким конкретным файлом работает программа и сколько раз обращалась, чтобы понять - или это идёт выборка данных из таблицы, или это сортировка в файле, или это ещё непонятно что? Упомянутый тут AnVir показывает общую нагрузку на диск (как впрочем и встроенный в виндоус PerfMon.msc) Для вадя : Вот результат выполнения вашего запроса: Код: sql 1. idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1PRIMARY<derived2>ALL11017Using filesort2DERIVEDTablicarefTipTip128087Using whereПричём этот экплэйн выполнялся 2 минуты 3 секунды. На всякий случай напишу и структуру таблицы: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Количество записей: более 300 тысячь Размер файла Tablica.MYD: более 20Gb Размер файла Tablica.MYI: всего 28Мб ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 17:55:23 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSky, По полю `Data` нет индекса? Тогда откуда вот это: InterSky Код: sql 1. тоесть поиск и сортировка по полям которые в индексе??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 18:03:20 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Есть индекс по полю Data, я просто чтобы небыло очень длинно стёр повторяющиеся строки: Код: sql 1. 2. 3. 4. 5. и их индексы, случайно захватив и индекс по дате... Хотя по дате очень редко ищется и сортируется (восновном по ID), по этому после первого примера который я привёл в описании проблемы, я давал уже более частые запросы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 19:35:51 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
InterSkyНа всякий случай напишу и структуру таблицы: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Количество записей: более 300 тысячь Размер файла Tablica.MYD: более 20Gb Размер файла Tablica.MYI: всего 28МбУ вас специально ID не первичный ключ? Если так, то 1) при поиске по Data в индексе (Data) будет найдено значение Nr 2) для получения значения Id придется искать его во всей таблице (по кластерному индексу) по значению Kr 3) для сортировки по Id свопировать результаты поиска на диск и там сортировать Если бы Id был PK: 1) при поиске по Data в индексе (Data) будет найдено значение Id 2) для сортировки по Id свопировать результаты поиска на диск и там сортировать, т.к. поиск был по другому индексу. Если PK=Nr, индекс (Data,Id): 1) при поиске по Data в индексе (Data,Id) будет сразу найдено значение Id 2) для сортировки по Id свопировать результаты поиска на диск и там сортировать, т.к. поиск был по другому индексу. Если индекс (Id,Data): 1) поиск сканированием всего индекса требуемых значений Data 2) сортировка не требуется (отсортировано индексом) Не факт, что этот алгоритм будет эффективнее, но попробовать можно :) Если индекс не покрывающий, то в любом варианте (кроме первого - там уже есть) понадобится поиск в кластерном индексе для извлечения необходимых значений (указанных в SELECT) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 20:28:22 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
* указанных во всем запросе (SELECT, WHERE, ON и т.д.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 20:30:36 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Cygapb-007У вас специально ID не первичный ключ? Если так, то 1) при поиске по Data в индексе (Data) будет найдено значение Nr 2) для получения значения Id придется искать его во всей таблице (по кластерному индексу) по значению Kr 3) для сортировки по Id свопировать результаты поиска на диск и там сортироватьОбратите внимание, тут MyISAM. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 20:32:03 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
авторУпомянутый тут AnVir показывает общую нагрузку на диск (как впрочем и встроенный в виндоус PerfMon.msc) если у него раскрыть ,по на жатию в систрее иконки с дисками, откроется окно где будет показываться и проги загружающие диск похоже у тебя всё упирается влисковую ситему кстати Auslogics Disk Defrag позволяет посмотреть, если задать деврагментаци. 1 фала, и количество фрагментов и их расположение на диске у дисков с системе есть параметр, галочка, как использовать кеш. также интересно, можно посмотреть в диспетчере задач, как используется память и своп. а сколько памяти в ХР? и чему равен своп файл? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 20:33:07 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Хотя расхождение все равно странное... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 20:33:16 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
miksoftCygapb-007У вас специально ID не первичный ключ? Если так, то 1) при поиске по Data в индексе (Data) будет найдено значение Nr 2) для получения значения Id придется искать его во всей таблице (по кластерному индексу) по значению Kr 3) для сортировки по Id свопировать результаты поиска на диск и там сортироватьОбратите внимание, тут MyISAM.ыыы ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 20:39:12 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
miksoftХотя расхождение все равно странное...Я неправильно трактую работу с индексами в MySQL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 22:06:42 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
Cygapb-007miksoftХотя расхождение все равно странное...Я неправильно трактую работу с индексами в MySQL?То, что Вы написали, верно для InnoDB, но не для MyISAM. В MyISAM обычная таблица-куча, а не кластерный индекс. А под расхождением я имел в виду, что автоинкрементное поле одно, а в первичном ключе другое. Да еще которого нет в определении таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2014, 22:16:02 |
|
||
|
Тормозит ли диск?
|
|||
|---|---|---|---|
|
#18+
автор`Kto` varchar(25), `Kuda` varchar(25), третья нормальная форма плачет кровавыми слезами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2014, 01:36:02 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38641404&tid=1834757]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
51ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 242ms |
| total: | 383ms |

| 0 / 0 |
