|
|
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
miksoftTvolodА вот выполняется ли неравенство t 1 + t 2 + t 3 < t 1+2+3 не знаю. Нужно делать точные замеры.По этой части какие-нибудь новые данные не появились? Да, сейчас вот провёл эксперимент. Условно говоря три разные задачи выполнялись последовательно и параллельно каждая по 1000 циклов с изменяющимися параметрами. Результаты следующие: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. Т.е. в параллели общий объём таки считается быстрее, процентов на 50-60 (в таблице 37%, но реально вторая задача успела посчитаться по второму кругу). Таким образом в параллельных расчётах всё-таки смысл есть. :) ScareCrowгруппировка по уникальному полю - это сила. Во-первых, если посмотреть глазами, то по крайней мере в одном из запросов видно, что полей c ID в таблице несколько (MH.MsgID, MH.PlaceID), а значит искушённый человек может предположить, что они не уникальны. И, представьте себе, так и есть во всех трёх запросах! Во-вторых, даже если бы были уникальны, Вы про джойн таблиц что-нибудь слышали? NikolayV81Выделено 25/47 а физически 24, может попробовать бех swap-а стартануть, тут такое впечатление что менеджер памяти винды запутался. ( У win есть проблема со swap, ( кстати он как создан, фикс или плавающий? А то он может быть так размазан по дискам что тормозить будет при первом обращении к нему ) ) Николай, спасибо, почитаю/посмотрю. Хотя, разве, вот эта картинка не говорит о том что своп он не использует, раз диски без чтения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2015, 19:05:54 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
TvolodХотя, разве, вот эта картинка не говорит о том что своп он не использует, раз диски без чтения? Да кто-же его знает, оно может и не считаться счётчиками, лог ntfs тоже не пишется ( если файл уже выделен, то просто сектора переписываются ). При вываливании в swap вообще сразу несколько проблем появляется, фрагментация идёт в том числе и в памяти, я к сожалению проверить в win эти эффекты не могу, у меня уже много лет swap отключен. Но дело в том что на первом вашем PrintScreen-е в swap система залезла ещё больше, просто попробуйте вырубить ( если есть возможность эксперементировать 24Гб дотсаточно много ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2015, 01:07:58 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
Tvolod, Кстати, можете лично спросить у разработчиков о причине вашей проблемы. habrahabr.ru/company/codefreeze/blog/250497/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2015, 16:54:32 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
miksoft, большое спасибо! Зарегистрировался. Не то чтобы надеюсь решить эту проблему с помощью семинара, но в целом интересное мероприятие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2015, 17:35:01 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
TvolodЗарегистрировался.Было бы здорово потом почитать топик-отчет о мероприятии. Заодно, возможно, развеете (или, наоборот, укрепите) бытуюущее мнение, что Оракл практически забил на разработку MySQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2015, 18:33:23 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
miksoftTvolodЗарегистрировался.Было бы здорово потом почитать топик-отчет о мероприятии. Заодно, возможно, развеете (или, наоборот, укрепите) бытуюущее мнение, что Оракл практически забил на разработку MySQL. И прочие заблуждения типа "percona нашла закомментированную константу в коде, раскомментировала ее и ускорила mysql в 10". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2015, 19:04:08 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
вот я погуглил и сэкономил вам билет в метро http://proitclub.ru/2009/06/22/Многопроцессорные-системы/ авторВсего 2-3 десятка лет назад использование нескольких процессоров встречалось лишь на больших суперкомпьютерах-мейнфреймах , но сейчас это уже встречается повсеместно, включая персональные компьютеры. Если говорить об архитектуре МС, то наиболее часто используется симметричная многопроцессорная обработка (Symmetrical Multi-Processing, SMP), в которой каждый процессор имеет равноправный доступ ко всей системной памяти. Однако система собственных процессорных кэшей усложняет синхронизацию и обмен данными, вводя дополнительные задержки, связанные с обновлением информации в памяти системы. Именно это, вкупе с ограничениями пропускной способности шины памяти, является причиной нелинейного изменения производительности при добавлении дополнительных процессоров. Кроме того, подобные системы плохо масштабируются из-за возникающих конфликтов при одновременном обращении нескольких процессоров к одним и тем же областям памяти. Подобные конфликты уже могут быть ощутимы при 8 одновременно работающих процессорах. Все современные серверы стандартной архитектуры на процессорах Intel построены с использованием технологии SMP. Практически любая современная операционная система может работать на таких серверах. Журнал с пафосным названием "ИТ-Спец" для вас достаточно авторитетен ? Неужели это кому-то еще неочевидно ? каких-то свопов приплели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2015, 19:09:46 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
netwind, Мне кажется, что Вы зря нагнетаете на процессорный кэш. Не верю я, что он может дать деградацию производительности почти до уровня последовательного выполнения. На единицы процентов - может, но не в разы. Иначе проблема топикстартера не была бы настолько экзотичной, а затрагивала бы почти любой многопоточный софт. Корень проблемы мне более видится в неких блокировках, вынуждающих отдельные потоки работать последовательно изрядную долю времени. На роль их источника хорошо подошел бы диск, но топикстартер с картинками настаивает, что это не он. Как вариант, остаются блокировки на уровне доступа к внутренним структурам MySQL (например, гипотетически может оказаться принципиально однопоточным механизм обслуживания временных таблиц). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2015, 19:32:26 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
miksoftnetwind, Мне кажется, что Вы зря нагнетаете на процессорный кэш. Не верю я, что он может дать деградацию производительности почти до уровня последовательного выполнения. На единицы процентов - может, но не в разы. Иначе проблема топикстартера не была бы настолько экзотичной, а затрагивала бы почти любой многопоточный софт. Так она и затрагивает. Корень проблемы мне более видится в неких блокировках, вынуждающих отдельные потоки работать последовательно изрядную долю времени. На роль их источника хорошо подошел бы диск, но топикстартер с картинками настаивает, что это не он. Как вариант, остаются блокировки на уровне доступа к внутренним структурам MySQL (например, гипотетически может оказаться принципиально однопоточным механизм обслуживания временных таблиц). тогда на картинках была бы видна недогруженность N CPU при N потоках, но ее не заметно. Все полностью загружено работой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2015, 19:58:34 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
netwindТак она и затрагивает.Далеко не так часто и сильно, как должно было бы, если бы дело было реально в процессорном кэше. netwindтогда на картинках была бы видна недогруженность N CPU при N потоках, но ее не заметно. Все полностью загружено работой.Если ожидание ресурсов сделано индусским способом (тупым бесконечнм циклом), то так и будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2015, 20:09:33 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
miksoftnetwindТак она и затрагивает.Далеко не так часто и сильно, как должно было бы, если бы дело было реально в процессорном кэше. Так ситуация изменилась после отключения HT. Уже не настолько явно проявляется. netwindтогда на картинках была бы видна недогруженность N CPU при N потоках, но ее не заметно. Все полностью загружено работой.Если ожидание ресурсов сделано индусским способом (тупым бесконечнм циклом), то так и будет. Уверен, что так плохо быть не может. Это продукт мифотворчества пользователей ворованного Оракла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2015, 20:19:13 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
Если ожидание ресурсов сделано индусским способом (тупым бесконечнм циклом), то так и будет. Как я понимаю этот случай, тут из примитивов, которым оперирует mysql, как программа, блокироваться нечему. Все запросы захватывают блокировку чтения на таблицу успешно, каждый со своими отдельными временными таблицами работает. Тут в принципе mysql-ю как программе некуда меняться и расти. Что уж проще ? Делать нечего, кроме как уменьшать объем работы. Но это уже требует вникания в бизнес-логику. Вот почему все любят учить оптимизации, но никто не любит ее делать. Я тоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2015, 20:29:02 |
|
||
|
Тормоза при выполнении параллельных запросов. Copying to tmp table
|
|||
|---|---|---|---|
|
#18+
miksoft, Зря не верите. Когда пошли первые конвееризованные ЦПУ с глубиной конвеера 6-7, делал замеры по потере производительности на переходах и "прочистке" конвеера ... получал падение в 2-4 раза (на память), вместо "итого рост". Сейчас глубина конвеера - значительно больше, поэтому есть и "предсказатели" переходов (и не один как понимаю!), позволяющие предварительно догружать конвеер ... за счет роста нагрузки на внутрипроцессорную шину ... и как следствие, чаще требовать подгрузки внутрипроцессрного кеша ... когда пошли первые процессоры с процессорным кешем ... получал аналогичные проблемы, но уже "этажом выше" ... и с большей нагрузкрй на шину... выходом была перекомпиляция приложений так, чтобы в кеш проца влезало основное ядро библиотек, и кеш блокировался от свопа принудительно. Потери прямого доступа в память окупались за счет частого попадания в кеш. Сейчас кеши приобрели ещё несколько уровней ... то есть проблема в ряде случаев может только "усугубиться"... .. просто уже давно, главным тормозом является шина, а не "вычислитель" в архитектуре "Фон Неймана"... она была полезна раньше, а сейчас - даже пара процов вполне способна "засрать" шину на 146% ... собственно почему многие архитектуры ограничиваются 4 "портами", "потоками", "камнями" ... дальше нет не только роста, а идет прямое падение в "итого" за счет накладок. Как сейчас обстоят дела в построении архитектур - давно не смотрел (лет 10) ... но не думаю что что-то "сильно поменялось". Эта проблема (и фиктивность многих "тестов") стояла уже в начале 90-х. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2015, 08:22:53 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38879494&tid=1833574]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
49ms |
get topic data: |
13ms |
get forum data: |
2ms |
get page messages: |
69ms |
get tp. blocked users: |
2ms |
| others: | 213ms |
| total: | 376ms |

| 0 / 0 |
