|
|
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
netwindпопробуйте у mysql tmpdir на ramdrive вынести. Зачем? TvolodНагрузки на диски нет никакой, ибо винда кеширует все файлы используемых таблиц и индексов. netwindTvolod, да что ж такое? не будет того результата, который вам нужен. Ну мне б хотя б научно обоснованную трактовку, что происходит. Я б успокоился. :) А то хрен знает что... Отсюда и решения предлагаются хрен знает какие. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2015, 12:55:48 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
Виноват. На картинке не видно, что не пишет она ни разу на диск в tmpdir Ну раз Created_tmp_disk_tables 44 Created_tmp_files 0 то это так! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2015, 12:59:18 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
Tvolodnetwindпопробуйте у mysql tmpdir на ramdrive вынести. Зачем? Ну просто попробуйте. Например, в linux на практике накладные расходы на поддержку файлов в ramdrive меньше чем создание файлов на диске, даже если запись этих файлов буферизирована и идет без явного запроса на синхронизацию. netwindTvolod, да что ж такое? не будет того результата, который вам нужен. Ну мне б хотя б научно обоснованную трактовку, что происходит. Я б успокоился. :) А то хрен знает что... Отсюда и решения предлагаются хрен знает какие. :) Тут как раз все понятно. Перечитывайте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2015, 13:28:34 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
TvolodВиноват. На картинке не видно, что не пишет она ни разу на диск в tmpdir Ну раз Created_tmp_disk_tables 44 Created_tmp_files 0 то это так! так в документации написано же Created_tmp_disk_tables - The number of internal on-disk temporary tables created by the server while executing statements. может быть не пишет так интенсивно, чтобы это было заметно в мониторе ресурсов windows ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2015, 13:29:53 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
netwindCreated_tmp_disk_tables - The number of internal on-disk temporary tables created by the server while executing statements. может быть не пишет так интенсивно, чтобы это было заметно в мониторе ресурсов windows ? Это старые значения из предыдущего поста взял. Текущие, после перезагрузки винды неделю назад такие: авторCreated_tmp_disk_tables 0 Created_tmp_files 0 Created_tmp_tables 0 Это после нескольких сотен тысяч циклов запросов, постоянно висящих в статусе Copying to tmp table. Заметьте, не в copying to tmp table on disk ! Всё равно попробуйте? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2015, 14:55:53 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
Блин! Это SHOW STATUS Если SHOW GLOBAL STATUS то темповые таблицы, конечно есть: авторCreated_tmp_disk_tables 296 Created_tmp_files 0 Created_tmp_tables 4332526 Но всё равно, на многие сотни тысяч запросов триста дисковых таблиц. Это не то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2015, 15:05:35 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
ВСЁ! Проблема решена! Как и предполагалось, проблема не в мускуле, а в системе. Оказалось, что процессор не 8-ми, а 4-х ядерный. 8 ядер создаётся с помощью кривой технологии гипертрейдинга, которая и не давала нормально работать даже одному процессу, выделяя ему менее 1/8 процессорной мощности (70-80% одного виртуального ядра). После отключения гипертрейдинга в биосе на каждый процесс стало выделяться в аккурат 1/4 мощности, т.е. 100% одного реального ядра. Соответственно как в одиночном режиме запросы стали выполняться гораздо быстрее, так и при одновременном запуске до 4-х процессов скорость прекрасная и никакого взаимного влияния на скорость не наблюдается (конечно, после кеширования системой всех нужных таблиц). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2015, 22:52:10 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
Tvolod, Однако... про гипертрейдинг мне даже в голову не приходило... Случаем, вы не зацепили по дороге какие-нибудь опции, связанные с энергосбережением и турбобустом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2015, 00:06:17 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
автор Оказалось, что процессор не 8-ми, а 4-х ядерный. 8 ядер создаётся с помощью кривой технологии гипертрейдинга, которая и не давала нормально работать даже одному процессу, выделяя ему менее 1/8 процессорной мощности Чейто она кривая? Нормальная. Как была спроектирована, прямо так и работает . Это частный случай того, о чем я говорил - параллельные процессы не параллелятся потому что не параллелятся никогда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2015, 00:45:53 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
miksoftСлучаем, вы не зацепили по дороге какие-нибудь опции, связанные с энергосбережением и турбобустом? Не. Ещё друг, который подсказал про гипертрейдинг, советовал отключить DEP (предотвращение выполнения данных), но короткие опыты не показали, что это что-то дало. А отключение гипертрейдинга сразу изменило ситуацию. netwindЧейто она кривая? Нормальная. Как была спроектирована, прямо так и работает. Возможно, что работает как спроектирована, но согласитесь, что не даёт выигрыша ни на одном потоке, ни тем более на многих. В моём случае по крайней мере. Хотя в современной операционке всегда много потоков, всяких служб и демонов... netwindЭто частный случай того, о чем я говорил - параллельные процессы не параллелятся потому что не параллелятся никогда. Эту философию я не понимаю. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2015, 09:55:06 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
TvolodОказалось, что процессор не 8-ми, а 4-х ядерный. 8 ядер создаётся с помощью кривой технологии гипертрейдингаРазбивать ядра пополам есть смысл, пожалуй, в системе с большим количеством разных лёгких задач, с целью их параллельного выполнения. Да и то, с осторожностью. Каждая отдельная задача будет выполняться значительно дольше на "половинке" ядра, нежели на целом (объективно частота примерно вдвое ниже + время на переключение). Потому для тяжеляка проще отдать полный ресурс для более быстрого выполнения задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2015, 10:17:40 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
Возможно вам и др. участникам обсуждения будет интересно тестирование влияния технологии гипертрединга. Вот ссылка http://habrahabr.ru/post/248359/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2015, 22:41:59 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
Что-то я поторопился с выводами... :( После отключения гипертрейдинга всё стало настолько быстрее, что казалось, что проблема взаимного влияния процессов больше не стоит. Но добавив в систему метрики скорости каждого из процессов (просто считаю количество обработанных циклов в минуту), стало видно, что при двух, а тем более при трёх параллельных процессах скорость таки проседает. Просто если раньше она проседала на порядок, то теперь в 2-3 раза. На глазок это не очень было заметно, а с метриками стало ясно, что это так. По-прежнему не ясно, почему это так и что с этим делать. С одной стороны оказалось, что число процессорных ядер почти равно числу процессов. А значит дефицит ресурсов может возникать (при обработке каких-нибудь прерываний и системных процессов), с другой стороны, на машине, где крутится только MySQL время на обработку прочих системных процессов должно составлять доли процента. При трёх параллельных процессах загрузка ядер выглядит так: Т.е. номинально картинка соответствует 100% загрузке 3-х ядер. Диски по-прежнему работают только на чтение. Запросы по-прежнему 99% времени висят в статусе Copying to tmp table. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2015, 22:53:36 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
Tvolod, Если дискового места достаточно, я бы попробовал на отдельной копии базы MySQL обновить до последней из ветки 5.5 или даже 5.6. Просто на всякий случай, проверить, что это не баг MySQL, который уже исправили. Я правильно понял из вашего последнего поста, что три запроса последовательно выполняются в 2-3 раза быстрее, чем три запроса параллельно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2015, 23:14:37 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
Я правильно понял из вашего последнего поста, что три запроса последовательно выполняются в 2-3 раза быстрее, чем три запроса параллельно? Да. И так всегда просходит со всеми программами, более сложными чем чисто вычислительные, типа оверклокерских тестов super pi. ТС почему-то решил что это не нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2015, 23:34:07 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
miksoftЕсли дискового места достаточно, я бы попробовал на отдельной копии базы MySQL обновить до последней из ветки 5.5 или даже 5.6. Просто на всякий случай, проверить, что это не баг MySQL, который уже исправили. Да, это можно попробовать. Тем более что написано: What's New in MySQL 5.6Better Performance and Scalability miksoftЯ правильно понял из вашего последнего поста, что три запроса последовательно выполняются в 2-3 раза быстрее, чем три запроса параллельно? Каждый по одиночке да, раза в 2-3 быстрее, чем если запускать его в параллель с другими. А вот выполняется ли неравенство t 1 + t 2 + t 3 < t 1+2+3 не знаю. Нужно делать точные замеры. Но это интерес чисто теоретический. Что будет, если "да" и что будет если "нет"? Зачем на машине 4 камня, если она упорно "едет" на одном? netwindДа. И так всегда просходит со всеми программами, более сложными чем чисто вычислительные, типа оверклокерских тестов super pi. ТС почему-то решил что это не нормально. А почему это должно быть нормально, при числе процессов меньшем числа ядер? Физика явления в чём? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 00:39:33 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
Tvolod, так я уже объяснял Современные процессоры штука сложная. В вашем случае скорее всего ограниченный и разделяемый кеш действует больше всего. Тот факт, на что широкий рынок 256 ядерные процессоры что-то не торопятся попадать, разве не подтверждает это общее правило? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 01:42:50 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
netwindTvolod, так я уже объяснял Современные процессоры штука сложная. В вашем случае скорее всего ограниченный и разделяемый кеш действует больше всего. Ну вот скорости работы оперативной памяти У меня как раз DDR-3 1600, т.е. 25 ГБит/сек. т.е. 3 ГБайт/сеу. Мускул у меня юзает менее 6 гигов, а все используемые таблицы весят около 4.5 Гигов т.е. за 1.5-2 секунды их можно просканировать полностью. Кеш же по идее в разы быстрее. netwindТот факт, на что широкий рынок 256 ядерные процессоры что-то не торопятся попадать, разве не подтверждает это общее правило? Широкий рынок не занят обработкой подобных массивов данных. Широкий рынок в контру режется, а для этого и двух ядер за глаза. Если посмотреть, сколько стоит 8-ми ядерный процессор, то можно понять, почему они не распространены. Широкий рынок серверов, кстати, идёт по пути увеличения числа процессоров на плате. Ещё лет 15 назад двухпроцессорные сервера были нормой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 20:14:57 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
TvolodnetwindTvolod, так я уже объяснял Современные процессоры штука сложная. В вашем случае скорее всего ограниченный и разделяемый кеш действует больше всего. Ну вот До чего ж простые люди. И что ну вот? Очевидно, есть и другие ограничения и оценка работы процессора в вашем случае не укладывается в обычные 2+2+4. netwindТот факт, на что широкий рынок 256 ядерные процессоры что-то не торопятся попадать, разве не подтверждает это общее правило? Широкий рынок не занят обработкой подобных массивов данных. Широкий рынок в контру режется, а для этого и двух ядер за глаза. А как же Крузис ? Вы геометрические размеры процессора-то видели ? Проблема не в том, что некуда впихать 32 ядер на кристалл, не в нехватке электричества, а в том, что сложно добиться чтобы эти ядра эффективно работали вместе, не мешались друг другу . Широкий рынок это еще и хостеры занятные поддержкой кривых сайтов с SELECT ..CALC_FOUND_ROWS(), куча плохих программ, рендер видео и тд и тд. Их все можно было бы легко и просто ускорить, но не получается. Из-за усложнения всего комплеса ПО когда одни компоненты опираются на другие, рост многоядерной производительности даже не десктопе всем очень был бы нужен, но она что-то забуксовала. Не растет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2015, 13:00:16 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
В общем ещё несколько экспериментов. Нашёл такую статью про парковку ядер . Включил в режим максимальной производительности. И... Ничего не почувствовал. :)) Так же перешёл на MySQL 5.6. Опять таки, если и есть изменения в производительности (похоже что есть), то они минимальны. Зато процессы теперь висят не в статусе "Copying to tmp table", а в статусе "Sending data". Подозреваю, что просто те же операции (или даже подоперации) просто называются по-другому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2015, 19:16:09 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
ну тоесть запросы и схему БД вы отказываетесь оптимизироватьпринципиально ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2015, 00:39:19 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
Видите ли, девушка... У меня нет ни чёрного пояса по SQL, ни таких учебников по теории баз данных как у Вас (например, запрещающих использовать ID в Group by). За сим самонадеянно полагаю, что запросы вполне себе ничего, и позволяю себе ставить вопрос именно так, как я его ставлю... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2015, 00:48:01 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
TvolodА вот выполняется ли неравенство t 1 + t 2 + t 3 < t 1+2+3 не знаю. Нужно делать точные замеры.По этой части какие-нибудь новые данные не появились? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2015, 03:25:45 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
TvolodВидите ли, девушка... У меня нет ни чёрного пояса по SQL, ни таких учебников по теории баз данных как у Вас (например, запрещающих использовать ID в Group by). За сим самонадеянно полагаю, что запросы вполне себе ничего, и позволяю себе ставить вопрос именно так, как я его ставлю... группировка по уникальному полю - это сила. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2015, 15:13:20 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
TvolodЧто-то я поторопился с выводами... :( После отключения гипертрейдинга всё стало настолько быстрее, что казалось, что проблема взаимного влияния процессов больше не стоит. Но добавив в систему метрики скорости каждого из процессов (просто считаю количество обработанных циклов в минуту), стало видно, что при двух, а тем более при трёх параллельных процессах скорость таки проседает. Просто если раньше она проседала на порядок, то теперь в 2-3 раза. На глазок это не очень было заметно, а с метриками стало ясно, что это так. По-прежнему не ясно, почему это так и что с этим делать. С одной стороны оказалось, что число процессорных ядер почти равно числу процессов. А значит дефицит ресурсов может возникать (при обработке каких-нибудь прерываний и системных процессов), с другой стороны, на машине, где крутится только MySQL время на обработку прочих системных процессов должно составлять доли процента. При трёх параллельных процессах загрузка ядер выглядит так: Т.е. номинально картинка соответствует 100% загрузке 3-х ядер. Диски по-прежнему работают только на чтение. Запросы по-прежнему 99% времени висят в статусе Copying to tmp table. Выделено 25/47 а физически 24, может попробовать бех swap-а стартануть, тут такое впечатление что менеджер памяти винды запутался. ( У win есть проблема со swap, ( кстати он как создан, фикс или плавающий? А то он может быть так размазан по дискам что тормозить будет при первом обращении к нему ) ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2015, 20:45:45 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38856906&tid=1833574]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
44ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 322ms |

| 0 / 0 |
