TvolodnetwindКонечно, некоторые хипстеры, считают что сайт должен сам себя администрировать. Но тогда им не надо ожидать, что обычные базы будут хорошо работать в необычном применении.
По-вашему предел возможностей MySQL - это прайс-лист загрузить и гуэстбук замутить?
В чем необычность задач, я не очень понимаю. Не метафизически: "не предназначено, мол", а физически, т.е. имеются (объективно) следующие ограничения... и мы их можем увидеть/пощупать на приведённом примере там то и там то...

Дело не в пределе возможностей, а в том как обычно используются рсубд.
Используешь как все - гуглишь ответ на любую проблему. А в большинстве случаев они даже не возникают.
Хочешь необычного - ты один на один с проблемой.


netwindЗдесь нет никакой особенной проблемы. производительность не масштабируeтся линейно по числу ядер и это не новость.
Опять таки, это просто общее утверждение, пусть даже и верное, я же не знаю. Физика то в чём? Почему это так на данном конкретном приведённом мной весьма простом и измеримом примере.

Но вы с ними согласны ?
За конкретное это вам придется самолет и командировку оплачивать. Пивом не обойтись.

netwindЕсли план запроса предполагает генерирование большой временной таблицы из и так большого числа фактов, почему бы этим запросам выполняться быстро?
При параллельном выполнении нескольких запросов план меняется, относительно "сольного" выполнения? Вряд ли. Тогда почему ему исполняться на порядок медленнее?
Ещё раз

вот именно, еще раз повторюсь:
netwindесли вас лично вместо работы над алгоритмом каждые 15 минут заставлять отвлекаться бумагу в принтере менять, забывая каждый раз на чем вы остановились (аналогия с кешем внутри процессора), много вы эти говносайтов склепать успеете в день?


автор: ресурсов (процессорной мощности и оперативки), более чем достаточно. Другие не используются. Ну я же показал на картинках, что сервер вовсе не напрягается при выполнении этих трёх задач. Возможно, есть другие измерители, на которые нужно смотреть - тогда буду признателен за подсказку.
В моём идеальном мире запросы должны выполняться с той же скоростью, что и раньше пока не станут где-то друг с другом конкурировать (взаимные блокировки, чтение с диска, разделение процессорного времени и т.п.). А если нет конкуренции за ресурсы, то видимых причин снижать на порядок скорость выполнения я не вижу. Ведь если бы запросы шли не одновременно, а друг за другом (в теории по крайней мере), они бы выполнились за линейно возросшее время (в теории по крайней мере).

У вас задача поиска всего среди всего - то есть, интенсивный обмен с памятью, который осуществляется через кеш процессора. Вот этого ресурса при параллельной архитектуре и не хватает. И соседи постоянно забивают его другими данными.
Наверное, какой-то из профайлеров в состоянии снять метрики cache miss, но это собирать mysql специально надо.
Мне кажется это и так достаточно здравое объяснение.


netwindНу может быть в этой конфигурации негативные эффекты возникают из-за наличия NUMA или PAE, но скорее всего их нет.
Погуглил эти термины... NUMA точно нет, т.к. обычная стандартная машинка.
http://www.nix.ru/autocatalog/nix_computers/S5000B_S5365LNi_Core_i74790_16_SATA_RAID_190793.html

netwindУ вас современный windows на какой-то массовой хостерской платформе ведь ?
Не очень массовая. В антресоли над туалетом пылится. :)

Я бы все же убедился как-нибудь конкретнее. Формально в википедии написано что Haswell EP таки поддерживает NUMA.
но раз уж это "серийный" сервер из nix, наверное не стоит.

Tvolod,

я так думаю надо вот с этой штукой разобраться https://perf.wiki.kernel.org/index.php/Tutorial, в линуксе запустить mysqld, налить тестовых данных и как-то снять счетчики cache miss

автор It provides a list of events to measure micro-architectural events such as the number of cycles, instructions retired, L1 cache misses and so on

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

ну вот как-то вроде считает у меня, где 13357 - pid процесса mysqld :
автор perf stat -e L1-dcache-load,L1-dcache-load-misses,L1-dcache-stores,L1-dcache-store-misses -p 13357
^C
Performance counter stats for process id '13357':

1,109,824 L1-dcache-load
201,929 L1-dcache-load-misses # 18.19% of all L1-dcache hits
372,766 L1-dcache-stores
23,616 L1-dcache-store-misses

9.512196166 seconds time elapsed

шо бы это значило ответ где-то здесь http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3b-part-2-manual.html

Кстати, после перезагрузки сервера эффект существенно уменьшился. Он по-прежнему есть, но стало в разы лучше. До этого менял параметры мускула и только рестартовал его.
Будем посмотреть, может быть это софтверный глюк. Кто его разберёт... :(
Может быть память была как-то занята другими таблицами и задачами. А при перезагрузке еще не успела.

Если у вас myisam, то попробуйте еще myisam_use_mmap=1.
Переход на innodb в данной ситуации может улучшить работу с данными в памяти, потому что данные точно залягут в пул innodb.

Ну и подумать над планами запросов всегда полезно.

TvolodnetwindЕсли у вас myisam, то попробуйте еще myisam_use_mmap=1.
Попробовал. Несколько дней покрутилось с этой опцией. Стало или хуже, или по крайней мере не лучше. Во всяком случае монитор ресурсов показывал постоянные обращения к диску в течение 1.5 суток, пока система всё-таки не закешировала большие таблицы.
netwindПереход на innodb в данной ситуации может улучшить работу с данными в памяти, потому что данные точно залягут в пул innodb.
А можете пояснить, за счёт чего может улучшить?


По определению. Так работает mmap - один из интерфейсов в ОС , про который неплохо было бы знать. Как и про кеш в процессоре.
вместо того чтобы считывать блоки данных через системные вызовы постоянно, эти системные вызовы возникают лишь когда блоки не попадают в уже считанную память область проецируемого файла.
Может и не ускорить запросы, которые использовали только лишь key_buffer.
Во всяком случае не должно быть хуже. Но вместе вот с этим :
Если у меня MyISAM через пару часов работы и так все системой (не MySQL!) полностью загружаются в оперативку. Просто проблемно этот опыт поставить. Нужно конвертировать таблицы, а их каждые сутки бекап подменяет...

..ситуация уже менее прозрачна. что там на что подменяется ?

Другой механизм используется в innodb, но он похож. Блоки просто считываются в буфер и при достаточно большом объеме памяти работа происходит только с буфером без обращения к ОС.
К несчастью, данные в innodb будут тупо больший размер в байтах занимать и прогноз дать нельзя. Я так подозреваю, все даже ухудшится.


Ну вот, например, простейший вариант:
[src sql]
select M2.ImageID, count(*) as Cnt


не читал, но заранее подход осуждаю.

Tvolod, да что ж такое? не будет того результата, который вам нужен.
попробуйте у mysql tmpdir на ramdrive вынести. Это может оказаться непросто для винды и возможно сожрет память навсегда ( не как в линуксе), но ускорить может.