Нужно железо для рабочей машины, где бы быстро (реально быстро и это важно) работала база данных MS SQL и многопоточное приложение из под net.core.
В настоящее время файл базы около 10Гб. В таблицах может быть до десятка миллионов записей.
На компе с i7 и HDD комплекс: приложение + база быстродействием базы упирается в HDD и обработка задачи занимает 3.5 часа. Учитывая, что это еще не самая сложная задача...
В общем хочется понять, насколько для MS SQL является более приоритетным диск или процессор. Достаточно ли SSD или нужно более хитрое решение.
P.S. Приложение хотя и одно, но многопоточное и стучится в базу одновременно множеством соединений.

Здравствуйте, CyberRussia, Вы писали:

CR>Нужно железо для рабочей машины, где бы быстро (реально быстро и это важно) работала база данных MS SQL и многопоточное приложение из под net.core.
CR>В настоящее время файл базы около 10Гб. В таблицах может быть до десятка миллионов записей.
Вообще ни о чем.

CR>На компе с i7 и HDD комплекс: приложение + база быстродействием базы упирается в HDD и обработка задачи занимает 3.5 часа. Учитывая, что это еще не самая сложная задача...
Индексы правильно настроены?

CR>В общем хочется понять, насколько для MS SQL является более приоритетным диск или процессор. Достаточно ли SSD или нужно более хитрое решение.
CR>P.S. Приложение хотя и одно, но многопоточное и стучится в базу одновременно множеством соединений.
Сколько памяти стоит? Если жестко упирается в диск, подумать о разнесении базы на несколько дисков (SSD) для паралельного доступа.

AJD>Вообще ни о чем.
Угу. Мне так все говорят. И отдельно взятые запросы выполняются быстро.

AJD>Индексы правильно настроены?
Насколько моего знания БД хватает, а я в них не специалист — да.
Грубо говоря — прочитать полмиллиона записей, на каждую сделать расчет и сохранить в другую таблицу. Плюс на каждую запись сделать примерно по пять запросов в другие таблицы (примерно по 100 записей), по каждой из которых сделать расчет и сохранить в соответствующие таблицы.

AJD>Сколько памяти стоит? Если жестко упирается в диск, подумать о разнесении базы на несколько дисков (SSD) для паралельного доступа.
16Гб. Может и стоит, вот и спрашиваю какое железо смотреть. В идеале с указанием на конкретные марки / модели.

Здравствуйте, CyberRussia, Вы писали:


CR>В общем хочется понять, насколько для MS SQL является более приоритетным диск или процессор. Достаточно ли SSD или нужно более хитрое решение.

Так нужно ваше приложение + mssql ускорить, или mssql?
Если первое, то что мешает посмотреть использование CPU,
памяти и диска за эти 3.5 часа и выяснить что именно вызывает "затык"?

Здравствуйте, Zhendos, Вы писали:
Z>Так нужно ваше приложение + mssql ускорить, или mssql?
Z>Если первое, то что мешает посмотреть использование CPU,
Z>памяти и диска за эти 3.5 часа и выяснить что именно вызывает "затык"?
Ускорить в комплексе. Затык вызывает диск. Однако непонятно, если условно заменить HDD на SSD, будет ли продолжать утыкаться в диск или в процессор. Понятно, что точный ответ может дать только практика. Но интересует опыт людей, что оказывалось в железе наиболее "узким".

Здравствуйте, CyberRussia, Вы писали:
CR>Ускорить в комплексе. Затык вызывает диск. Однако непонятно, если условно заменить HDD на SSD, будет ли продолжать утыкаться в диск или в процессор. Понятно, что точный ответ может дать только практика. Но интересует опыт людей, что оказывалось в железе наиболее "узким".

Практически всегда диск. Или память. Которой не хватает для кеширования из-за чего всё опять упирается в диск.

PS Попробуй ограничить количество чтений из бд. Вообще все, что можно, перенеси в бд, благо mssql уже лет 15 позволяет писать функции на .net.

Нужно установить любой SSD и оперативной памяти хотя бы 64-128 ГБ. Процессор желательно тоже побыстрей, i7 ничего не говорит. Если железо десктопное, то сейчас нормальный вариант это 10900K или похожий Xeon.

Здравствуйте, CyberRussia, Вы писали:

CR>Но интересует опыт людей, что оказывалось в железе наиболее "узким".
У тебя всего 10ГБ база при 16 гигах оперативки. Почему она с диска у тебя много читает и что именно она читает?
Сама фраза "упирается в диск" мало что говорит, если честно.

Узкие места — память обычно. Которая вызывает затыки на диске и ЦПУ.
Вот если просто так, от балды советовать по фотографии — увеличь объем памяти и поставь SSD.
Скорее всего, поможет, но насколько поможет — я не знаю.

Может у тебя там 3.5 часа из-за RBAR подхода и надо код переписывать, а не железо апгрейдить, например.

Здравствуйте, CyberRussia, Вы писали:

CR>Нужно железо для рабочей машины, где бы быстро (реально быстро и это важно) работала база данных MS SQL и многопоточное приложение из под net.core.
CR>В настоящее время файл базы около 10Гб. В таблицах может быть до десятка миллионов записей.
CR>На компе с i7 и HDD комплекс: приложение + база быстродействием базы упирается в HDD и обработка задачи занимает 3.5 часа. Учитывая, что это еще не самая сложная задача...
CR>В общем хочется понять, насколько для MS SQL является более приоритетным диск или процессор.

При таком соотношении чисел возникает зверски сильное ощущение, что быстродействие упирается в неоптимальность приложения и приоритетным является программист. Конечно, вопрос, что за расчёты... но блин, пять лет назад у меня на рабочей станции биллинг со всеми завихрениями на порядок быстрее считался, включая radius-сервер. А вот что может быть неоптимально в приложении... да очень много что... с бедра:

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

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, CyberRussia, Вы писали:

CR>>Нужно железо для рабочей машины, где бы быстро (реально быстро и это важно) работала база данных MS SQL и многопоточное приложение из под net.core.
CR>>В настоящее время файл базы около 10Гб. В таблицах может быть до десятка миллионов записей.
CR>>На компе с i7 и HDD комплекс: приложение + база быстродействием базы упирается в HDD и обработка задачи занимает 3.5 часа. Учитывая, что это еще не самая сложная задача...
CR>>В общем хочется понять, насколько для MS SQL является более приоритетным диск или процессор.

S>При таком соотношении чисел возникает зверски сильное ощущение, что быстродействие упирается в неоптимальность приложения и приоритетным является программист.
Вполне возможно, в БД не силен

S>- чрезмерная многопоточность
ThreadPool в который грузится не более 12 задач (по числу процессорных потоков)

S>- чрезмерное дробление операций
Если имеется в виду возможность выполнения одной sql команды вместо группы команд — нет

S>- вытаскивание из БД и расчёт в приложении того, что куда быстрее посчитать в базе
Вот это возможно

S>- многократное таскание из БД в приложение одних и тех же данных
Нет

S>- избыток операций, требующих синхронизации (например, слишком частые коммиты)
На каждый завершенный блок бизнес логики

S>- реконнект на каждую запись
Нет

Здравствуйте, CyberRussia, Вы писали:

CR>На компе с i7 и HDD комплекс: приложение + база быстродействием базы упирается в HDD и обработка задачи занимает 3.5 часа. Учитывая, что это еще не самая сложная задача...
Если чисто для скоросьти — разнесите базу на несколько дисков. Таблицы пусть лежать на SSD (NVME, не SATA), а логи — либо на отдельном SSD либо рейде из нескольких HDD.

CR>В общем хочется понять, насколько для MS SQL является более приоритетным диск или процессор. Достаточно ли SSD или нужно более хитрое решение.
Зависит от нагрузки, нужно профилировать. Измерьте, чего у вас не хватает? пропускной способности диска или латентности.
И насколько параллельные запросы размазаны по таблицам: обрабатывают их подряд или в случайном порядке.
Ну и, как уже советовали, проверьте, что соединения используют индексы. Если нет — то начать нужно именно с них.

Здравствуйте, CyberRussia, Вы писали:

CR>Понятно, что точный ответ может дать только практика.

Точный ответ может дать исследование.

CR>Но интересует опыт людей, что оказывалось в железе наиболее "узким".

Проблема в том, что без изучения твоей конкретной ситуации все советы это "пальцем в небо". Советую нанять специалиста и оплатить его услуги.

Здравствуйте, Ромашка, Вы писали:

Р>Практически всегда диск. Или память. Которой не хватает для кеширования из-за чего всё опять упирается в диск.

По моему опыту в половине случаев это код приложения.

W>Проблема в том, что без изучения твоей конкретной ситуации все советы это "пальцем в небо". Советую нанять специалиста и оплатить его услуги.
Совет конечно хороший, только экономически нецелесообразных.

V>И насколько параллельные запросы размазаны по таблицам: обрабатывают их подряд или в случайном порядке.
Подряд

V>Ну и, как уже советовали, проверьте, что соединения используют индексы. Если нет — то начать нужно именно с них.
Индексы имеются

Здравствуйте, CyberRussia, Вы писали:

W>>Проблема в том, что без изучения твоей конкретной ситуации все советы это "пальцем в небо". Советую нанять специалиста и оплатить его услуги.
CR>Совет конечно хороший, только экономически нецелесообразных.

То есть проблема не настолько серьезная, что из-за нее бизнес деньги теряет или клиентов и т.п. OK. Тогда можно пока не париться. Или не спеша разобраться в проблеме и самому стать специалистом.

W>То есть проблема не настолько серьезная, что из-за нее бизнес деньги теряет или клиентов и т.п. OK. Тогда можно пока не париться. Или не спеша разобраться в проблеме и самому стать специалистом.
Станет ли проект когда-либо бизнесом — я без понятия. Вообще, по ТЗ складывается ощущение, что это лично-индивидуальный заказ человека. Заказчик не хочет нанимать кого-то еще и предлагает разбираться мне. Зато готов купить железо. Если я буду нанимать за свои, то учитывая стоимость консультаций действительно хорошего специалиста, то мне выгоднее будет от проекта просто отказаться.
И, да, я НЕ являюсь спецом по БД. И то, что столкнусь с такой проблемой на этапе ознакомления с ТЗ не представлял.

Здравствуйте, CyberRussia, Вы писали:

V>>Ну и, как уже советовали, проверьте, что соединения используют индексы. Если нет — то начать нужно именно с них.
CR>Индексы имеются
А используются?

V>А используются?
Эм... озадачили... А, разве, могут иметься, но не использоваться?
Индексы проставлены на пять полей по которым выбираются записи.

Здравствуйте, CyberRussia, Вы писали:

V>>А используются?
CR>Эм... озадачили... А, разве, могут иметься, но не использоваться?
CR>Индексы проставлены на пять полей по которым выбираются записи.
То есть, там нет джойнов, а просто выборка из одной таблицы по условию равенства пяти полей?
Если так и по этим полям есть индекс, то с вероятностью 99% он используется, удостовериться можно, посмотрев план выполнения запроса.
Еси условие более сложное или есть джойны — то могут быть нюансы. В любом случае, execution plan поможет в расследовании.