Надо смотреть план конкретного запроса. Если все необходимые данные уже загружены в кеш, то скорость ввода-вывода с диска значения не играет. Зато играет значение производительность процессора, системной шины, оперативной памяти. Именно так и происходит в хорошо сбалансированных системах, где памяти достаточно и Page Life Expectancy зашкаливает.

З.Ы. Оценивать производительности системы по отдельно взятому запросу не очень правильно. Например, если в системе много простых запросов (например, веб магазин), то хорошо будут работать многоядерные процессоры, где будут работать параллельные планы. А бывают задачи с очень тяжёлыми транзакциями. Типа ERP. Где планы редко распараллеливаются. Там высокая тактовая частота процессора играет значительную роль. А количество ядер можно поменьше.

#Хэш=

Tauzerдля чистоты эксперимента делаю простой запрос из таблицы


результат возвращает примерно 8,5 млн. строк

Вот статистика:
на Т30

на R910 все то же самое, только время выполнения не 120077 , а 194322
В остальном статистика идентичная.Неверное представление о чистоте эксперимента. Во-первых, данные могли читаться не с физического диска, а из кэша. Во-вторых я вижу количество байтов полученных с сервера и понимаю, что у Вас тут передача данных по сети в основном задействована и скорость вывода на консоль.

Не надо делать SELECT * FROM table.
Надо SELECT SUM() FROM table, например.

Чтобы вычисления проводились внутри сервера, а на клиента по сети кидалось всего несколько десятков байт результата.

Ну и SET STATISTICS IO ON; надо, чтобы понять, что там реально с дисковыми операциями происходит. Тогда будет понятно, физические это чтения или логические. Есть ли запись во временные таблицы и т.д.

#Хэш=

Andy_OLAP04cf9f9576a6f15Надо смотреть план конкретного запроса. Если все необходимые данные уже загружены в кеш, то скорость ввода-вывода с диска значения не играет. Зато играет значение производительность процессора, системной шины, оперативной памяти. Именно так и происходит в хорошо сбалансированных системах, где памяти достаточно и Page Life Expectancy зашкаливает.

З.Ы. Оценивать производительности системы по отдельно взятому запросу не очень правильно. Например, если в системе много простых запросов (например, веб магазин), то хорошо будут работать многоядерные процессоры, где будут работать параллельные планы. А бывают задачи с очень тяжёлыми транзакциями. Типа ERP. Где планы редко распараллеливаются. Там высокая тактовая частота процессора играет значительную роль. А количество ядер можно поменьше.

#Хэш=
Таки самое смешное, что в старом T30 у него стоят планки памяти DDR4 Unbuffered DIMMs (варианты 1600 MT/s, 1866 MT/s, 2133 MT/s, 2400 MT/s, скорее всего, самые скоростные), а в новом R910 на чипсете Intel 7500 стоят планки DDR3 низковольтовые, а по официальной спеке "Supported DDR3L are 2 GB x8, 4 GB x8, 8 GB x8, and 16 GB x4 DRAM RDIMMs. RDIMMs rated at 1333 MT/s operate at maximum of 1066 MT/s". И получается, что данные по шине между оперативной памятью и CPU в старом прокачиваются 2400, а в новом 1333. Делим 00:02:40 (160 секунд) на 1333 и умножаем на 2400 - и получаем 288 секунд (4 минуты 48 секунд). А если делим на 1066 и умножаем на 2400, то получаем 360 секунд (уже 6 минут). А плюс большой размер кэша L3 на новом, но в 24 Мбайта размер считанных строк для select не помещается - и тут вступает в работу частота 3.3 Гц против 2.67 Гц.
И берем 360 секунд, делим на 2.67 и умножаем на 3.3 - и получаем 445 секунд (7 минут 25 секунд).

Ну а учитывая то, что скорее всего на R910 включен режим не максимальной производительности для Windows, а адаптивной - ему еще нужно раскачаться и выйти на частоту 2.67. Отсюда получаем 7 минут 50 секунд. При одинаковом плане выполнения...Вот это скорее всего наиболее правдоподобное объяснение. Ради любопытства можно на рабочей системе под нагрузкой фиксировать показатели "page lookups / sec" и процент загрузки процессора. Скорее всего обнаружится хорошая корреляция. То есть, запросы, вызывающие большое количество логических чтений, вызывают высокую загрузку процессора. Соответственно, если в наличии огромный размер памяти, вся база туда целиком помещается, обращения к диску по нулям, то узким местом становится процессор и шина.

Выход здесь только в оптимизации запроса. Надо стремится, чтобы для получения результата требовалось минимальное количество логических чтений страниц.

З.Ы. Особенно обидно, когда есть 8 ядер, а запрос не параллелится. То есть, до предела загружено одно ядро. Остальные стоят. На графике загрузка процессора, соответственно, 12%. И это предел. Объяснить админу, что при загрузке процессоров 12% именно они являются узким местом, бывает непросто.

#Хэш=