8.х Файл-серверная vs клиент-серверная

Всем привет. Есть у меня есть конфа (полностью своя). Автоматизация общепита. Есть раскладка продуктов. Т.е. есть блюдо и в это блюдо входят ингредиенты. Себестоимость блюда рассчитывается как сумма себестоимости всех ингредиентов. Приходит ко мне пользователь и говорит, мл очень медленно происходит расчет. Типа минут 5. Переписал я все это дело и начал тестировать. Мой комп (файловая) и комп с SQL по мощности одинаковые. Но в файловой в разы быстрее все отрабатывает. Почему? Вот мои тесты Время в секундах. Тестировалось на разных по объему документах (6 документов). Old - старый механизм, New - новый.

Хорошо. Тогда почему запрос на SQL отрабатывает раз в 10 быстрее?

Обычные формы.
Самый незаурядный пример. Есть у меня регистр сведений. Спроектирован он не правильно сразу говорю. Непериодический. Подчинен регистратору (документ один). Вот его структура

Все измерения не индексированы.
Простой запрос на рабочей базе (SQL) выполняется

И вот тот же самый запрос на локальной базе

Данные в регистре идентичны. Их 1 461 266. Как объяснить?

Ну с этим Вы явно погоречились. Я посмотрю как у вас файловый вариант 3 раза в день у одно пользователя будет выборки делать по 100 000 записей и К-С, который это в лог положит а потом оттуда тащить будет.

С чем я согласен так это с 7 постом, что бы сравнивать производительность скуля то надо знать все эти параметры.
Производяительность от скуля получается не тем что только скуль поставили, но и тем как это все оптимизировали. Что файла разнесли на разные диски. какие RAID на этих дисках. Что индексы ребилятся, статискиса собирается, автошринк не стоит, место выделено нормально что бы дефрагментации не было и т.д.

--- Объединение сообщений, 19 сен 2014 ---

Тем что он эти данные уже в лог поместил и оттуда тянет, а не заново считывает из базы

Когда успел то? Или они там всегда хранятся?

Просто дело в чем. SQL обслуживаю не я. Что очень хотелось. Но что есть то есть. И закрались у меня сомнения, что чел, который обслуживает лукавит и делает не все в лучшем виде. Да, не спорю, сервак слабоват. 32 ОЗУ, 2 проца по 1,86 Ггц и по 4 ядра. RAID из 10 винтов по 80 ГБ. Больше мать не тянет. Но иногда возникают просто такие ужасные тормоза в работе. Вот я хочу найти причину.

--- Объединение сообщений, 19 сен 2014 ---

Вчера да. Там тестовый был

Ну ты как только запрос подобный выолнил он его в лог и записал и в статистику. Даже в след раз если в логе этой инфы не будет по статистике он тебе построит более оптимальный запрос выдаст данные быстрее. В логе данные храняться пока ты лог не шринкуешь или у тебя его бэкап не делается.
Что касается сервака, то и на таком омжно выдавать просто грамотно разложить. Вот что там за RAID стоят? на разных ли дисках log файл, файл данных, tmpDB. Какие RAID? Наверное 0 или 1й хотя можно выделить нормально места под лог и файл данных сделать на 5 Raid что бы данные считывались оттуда быстрее. Много всего. Про те же индексы. Может там только Реорганайз их стоит, но не ребилдятся они....

nomad_irk, я иногда тебя не понимаю вообще. Твоя притча мой мозг взорвала

Что касается именно 1С, то регламентные операции я всегда выполняю. ТиИ с реиндексацией и прочую херь. А вот с SQL сложнее. Не дают его мне.

хз...
Знаю только, что 10 HDD по 80 ГБ. SQL установлен на диске С. На D хранятся все базы. Есть еще E под логи и темпы. На диске с гигов 70. На E около 100, остальное под базы на D. Больше никакой инфой не владею.

Ну вот как ты сказал что на одном диске базы. так вот представим что там не 5 й райд. т.е мы сможем считать данные одновременно с одного винта, так вот ктото задал запрос к одно БД. Головка перемистилась и начала считывать и тут твоя конфа то же что то должна получить и то же надо считать с винта, мало того что она будет ждать пока выполниться тот запрос потом будет ждать опка головки переместятся обратно к твоим данным и только полсе этого выдаст. Т.е по идее может лучше каждый день делать бэкапы и на каждый винт сделать по базе, чем делать raid и места будут только на то что что бы все в куче было. Надо анализировать. Систему на RAID, основную базу, время разворота которой критично то же на RAID, остальные можно и просто. Ну это надо смотреть.
В инете инфы полно

тут особо понимать нечего - фрагментация (как и в файловой системе) приводит к увеличению количества операций чтения, а отсутствие нормальной статистики - к выбору не всегда оптимального плана запроса (в качестве примера - если по статистике в левом соединении приедет 1-2 записи справа - sql попользует nested lookup, даже если есть индекс, а если в реальности приедет 1000 записей - будет тормоз)

нафига схд при одном сервере? был бы кластер sql 2008 - имело бы смысл, с 2012 уже нет - там AlwaysOn.
лучше размер базы зафиксировать в состоянии, которого она достигнет через пару лет работы, и лога - в 2 максимальных размера между бэкапами - меньше будет фрагментация файлов

а так - да, смотреть физическое расположение и регламенты.

Тут все просто - кластерный индекс, дата в нем вторая, соответственно искать хоть и не так просто, как если бы она была первой, но проще. файловая будет тупо сканить всю таблицу

Думаю здесь ты прав на 100%. Помнится мне, что когда на 2-ой базе пользователь запустит отчет какой нить не хилый, за год. То виснет все напрочь. Будем думать