Один работает - остальные висят.

← →
Shirson (2003-12-04 07:43) [0]

Если у одного пользователя отрабатывается большой и ресурсоёмкий запрос, например по поиску в полях типа text, то остальные аользователи не то что тормозят - просто "висят".
Есть ли возможность это побороть? Какой-нибудь ограничитель ресурсов сервера на выполнение одного запроса.
Можно без подробностей, просто подскажите в какую сторону смотреть :)

← →
Hooch (2003-12-04 08:05) [1]

оперативной памяти доставить, проц помощнее, винт побыстрее :-)

← →
Shirson (2003-12-04 08:17) [2]

>Hooch © (04.12.03 08:05) [1]
оперативной памяти доставить, проц помощнее, винт побыстрее :-)

Это относится к разряду "ограничитель ресурсов сервера на выполнение одного запроса"?
Не знал :)

← →
Hooch (2003-12-04 08:19) [3]

>Shirson ©

это относится к разряду "Есть ли возможность это побороть?" :-)

← →
yozhik (2003-12-04 08:23) [4]

Менять запрос...

← →
sniknik (2003-12-04 08:27) [5]

а что у тебя на закладке -> свойства сервера -> processor ? см. в ентерпрайз менеджере.

← →
Shirson (2003-12-04 08:28) [6]

Запрос менять не получится.
Если бы по varchar искал - это секунды. А вот с text - амбец.
(Full-Text Index сделан - не особо помогает)

← →
Hooch (2003-12-04 08:31) [7]

а чего и ишещ и что в text поле лежит ?

← →
Anatoly Podgoretsky (2003-12-04 08:32) [8]

Это говорит, что компьютер надостаточен для выполнение это задачи.

← →
Shirson (2003-12-04 08:32) [9]

>sniknik

А что именно интересует?

Maximum worker threads - 255
Boost SQL Server priority on Windows - None
Use Windows NT fibers - None
Minimum query plan threshold - 5
Сonfigured values - Yes

← →
sniknik (2003-12-04 08:36) [10]

Shirson © (04.12.03 08:32) [9]
вот это
> Maximum worker threads - 255
и это
> Сonfigured values - Yes
обеспечивает параллелизм запросов. но у тебя стандартно, не меняли. значит единственное машина слабая.
хотя, интересно можно ограничить потоковость из системных настроек? нет скорее всего (не знаю такого метода).

можеш конечно поиграть на этих параметрах но по моему без толку.

← →
Hooch (2003-12-04 08:38) [11]

либо машину покруче надо, либо принцип поиска менять

← →
sniknik (2003-12-04 08:44) [12]

Shirson © (04.12.03 08:28) [6]
> Запрос менять не получится.
> Если бы по varchar искал - это секунды. А вот с text - амбец.
> (Full-Text Index сделан - не особо помогает)
а служба запущена? я с полнотекстовым поиском не работаю, но вроде видел там его отдельная служба осуществляет (ошибаюсь?), просто если так то без нее все одно будет перебор без индексов (она же их обновлять должна).

← →
Shirson (2003-12-04 08:46) [13]

>Hooch © (04.12.03 08:31) [7]
а чего и ишещ и что в text поле лежит ?

Есть поле, типа text. Там лежит шмат текста, килов на 10-20.
В этом поле запрос ищет ключевые слова и подсчитывает их количество...

Так, пока писал, родилась идея, как запрос мальца ускорить :)
Запрос работает с полем через TEXTPTR + READTEXT/UPDATETEXT (потому что оно text, мать его :)). Попробую исключить UPDATE, должно прокатиить.

← →
Shirson (2003-12-04 08:51) [14]

sniknik © (04.12.03 08:44) [12]
а служба запущена? я с полнотекстовым поиском не работаю, но вроде видел там его отдельная служба осуществляет (ошибаюсь?), просто если так то без нее все одно будет перебор без индексов (она же их обновлять должна).

Population у меня зашедулен на каждый час.
Full-Text Search - Running.

Что-нибудь еще? (я сам с полнотекстным поиском не работал, пока не прижало...)

← →
Shirson (2003-12-04 08:53) [15]

Показал Генеральному эту ветку и сказал - НАДО.
Он ответил - Пиши заявку.
:)
Второй проц + 512 метров, это минимум. :)))

← →
sniknik (2003-12-04 08:54) [16]

> Есть поле, типа text. Там лежит шмат текста, килов на 10-20.
а ты не путаеш?(или я) full-text это же вроде не поиск в текстах а поиск "не обрашая внимания на колонки" т.е. по всей строке.
а в тексте в любом случае перебор.
и таблици для него должны быть отмечены, во всяком случае так написано, в справке по sp_fulltext_table

← →
sniknik (2003-12-04 08:58) [17]

Shirson © (04.12.03 08:53) [15]
> Второй проц + 512 метров, это минимум. :)))
попытайся RAID выбить, если пока нет, 5 уровня (масив мин. на 3диска или 4(необязательно) 2(зеркало) просто не эфективно в плане скорости(та же остается)). ОЧЕНЬ ускоряет дисковые операции (в 2 раза гарантирую).

← →
Hooch (2003-12-04 08:58) [18]

у нас есть справочник номенклатуры пордяка 2 миллионов товаров, на каждый товар несколько колонок с описанием типа text. есть справочник основ слов. при изменении поля текст разбирается на слова, у слов отсекаются окончания и создается "перевязка" между справочникм слов и текстом (КОД_СЛОВА;НОМЕР_ТОВАРА).
в итоге поиск просто "летает", но соответсвенно и размер БД будет больше. попробуй по такому принцпу сделать должно помочь

← →
Shirson (2003-12-04 09:08) [19]

>sniknik
Таблица под Full-Text отмеченна.
Насчёт RAID - сам хочу, но недадут. Для них это дорого.

← →
Nikolay M. (2003-12-04 09:10) [20]

> остальные аользователи не то что тормозят - просто "висят".

Именно висят? Попробуй FROM mytable ( nolock)
?

← →
Shirson (2003-12-04 09:25) [21]

>Hooch
Заранее неизвестно, по каким словам будет поиск, поэтому словарь тут неподойдёт.
У меня тут появилась одна ганжубасная идея... Нарезать текст на параграфы, и хранить как varchar.
Теперь надо подумать, как эту идею реализовать...

← →
Shirson (2003-12-04 09:31) [22]

>Nikolay M.

Попробую, спасибо.

← →
Hooch (2003-12-04 09:58) [23]

>> Shirson ©

"Заранее неизвестно, по каким словам будет поиск"
прежде чем текст ляжет в таблицу он разбирется и пополняет словарь отсутствующими словами, так что не важно по каким словам идет поиск, нет в словаре нет в тексте. Что касается нарезки на парараграфы, мне кажется это мало поможет, тормоза из-за полного прохода всех данных а в предложенном мною способе получается эффект поиска по индексу

← →
Shirson (2003-12-04 10:04) [24]

>Hooch

Тогда размер будет действительно не-детский...
Но это вариант. Спасибо, я его помозгую.

← →
Anatoly Podgoretsky (2003-12-04 10:08) [25]

Надо не железо менять, а алгоритмы, это основой резерв, а наращивание железа это экстенсивный путь, ведущий в тупик.

← →
sniknik (2003-12-04 10:50) [26]

Hooch © (04.12.03 09:58) [23]
а как с повторами быть? ведь необязательно 1 слово в одном тексте. надо список вхождений хранить. плюс если по нескольким словам поиск искать пересечения. получается чтото вроде интернет поисковика (в некоторых пишут слово - сколько вхождений, ...). ну в общем то они быстро ищут, несмотря на массу текстов (представляю себе сколько там). но вот только одним запросом не ограничишся, это целый алгоритм.

Anatoly Podgoretsky © (04.12.03 10:08) [25]
машину проапгрейдить тоже лишним не будет. (чего это за сервер без рейда на одном проце? просто рабочей станции присвоили гордое имя сервер? ;о))

← →
Shirson (2003-12-04 10:59) [27]

>Anatoly Podgoretsky

Это само собой. Но железо под шумок выбить - тоже полезно.

Сейчас вариант Hooch-а пробую реализовать. Посмотрим, что получится.

← →
Shirson (2003-12-04 11:06) [28]

>sniknik

Я себе это вижу так:
При вставке/апдейте поля с текстом, оно разбивается на слова.
Все слова, которые не содержатся в словаре в оный заносятся.
Кроме таблицы словаря, есть таблица содержания. Она связанна со словарём и в неё заносятся ID записей, содержащих тексты.

Словарь
-Народ-5
-Партия-6
Содержание
-5-1598
-5-16598
-5-21598
-5-1009598
-5-15980
-5-159648
-6-1009598
-6-4576
-6-786

Ищем "Народ" - получаем список ID-шников всех статей, где он есть.
Пересечение никаких проблем не вызывает. Можно выбирать или-или.
"Народ" или "Партия".
Можно и по И искать.

Вроде ничего. Только со статистикой пока затык.

← →
SergSuper (2003-12-04 11:29) [29]

Full-Text Index предназначен для Full-Text Search, который выполняяется посредством Full-text Query, в результате запрос должен быть вида:
SELECT ProductName FROM Products WHERE CONTAINS(ProductName, "spread NEAR Boysenberry")

← →
Shirson (2003-12-04 12:44) [30]

Это понятно, проблема в другом.
Запрос считает статистику повторений слова в поле. Вот это и тормозит запрос жутко. И есть CONTANS или нет его сути не имеет - этим оператором статистику не посчитаешь.

Я тут делаю пока словарь, сделал разбивалку на слова. Работает ОЧЕНЬ быстро. Вот её же я хочу прикрутить вместо статистического запроса с жуткими READTEXT и UPDATETEXT.

← →
Shirson (2003-12-04 18:50) [31]

>Hooch

Огромное Спасибо за идею .
Написал я словарь, прикрутил реляции и даже статистику повторений приклямал.
База начинает расти (но не катастрофически, а логарифмически, причём с убыванием прогрессии роста. О загнул :)) Но скорость! Это просто пугает и ищешь подвох :) Раньше запрос считал статистику до 10 минут. Сейчас я палец не успеваю от кнопы оторвать, как выплёвывается результат.
За это пришлось, правда, заплатить потерей скорости в другом месте - при занесении данных. Но это еще можно пережить. Блок текста на ~270000 символов он раздербанивает за 2:10-2:20 минуты. Фигня, таких кусков не так уж и много и на этом этапе время некритично (потоковая обработка .doc-файлов в автоматическом режиме)

← →
Anatoly Podgoretsky (2003-12-04 20:29) [32]

sniknik © (04.12.03 10:50) [26]
Машину усилить надо, но не по этой причине. Аппаратный RAID1/5 взависимости от денежных русурсов. Процессор можно и один, но лучше 2/4 XEON HT/MP
Двух канальная память до 2 гб

← →
Anatoly Podgoretsky (2003-12-04 20:30) [33]

Ты это новый метод не внедряй, если хочешь проапгрейдить железо, зато потом будешь показывать как железо ускорило.

← →
Shirson (2003-12-05 06:25) [34]

Я его внедрю для Унутреннего пользования.
Когда докупят железячку, переключу на всеобщее пользование. Заодно и новую версию программы закончу. Кроме проблемы поиска в text есть и другие. Заодно и их решу и выдам всё за раз :)

(за 10 часов ночной работы по заполнению словаря, обработалось ~21000 существующих записей. Осталось еще ~48000. Как раз на выходные оставить жужжать.)

← →
Hooch (2003-12-05 07:21) [35]

> Огромное Спасибо за идею.

Всегда пожалуйста ! :-)

Один работает - остальные висят. Найти похожие ветки