оказ в обслуживании MSSQL server

← →
redlord (2005-11-19 15:51) [0]

всем привет
подскажите в чом может быть проблема ?

многопоточное приложение , каждый поток создает пару
connect query для работы с таблицой (одной на все потоки)

принцип работы потока такой
происходит загрузка из таблици данных(в листбокс) удовлетворяющих условию по полю F1 (порядка 10000)
потом происходит обработка данных в листбоксе после чего
данные из лист бокс записываются в таблицу (update)
после етого поток умирает. после чего запускается такойже поток тока обрабатывает поле F1 с другим условием.

проблема в следующем когда работает одновременно порядка 5 потоков то гдето на 50 потоке (10 *5) чтение в листбокс не происходит . к тому времени mssql сервер сжирает
порядка 300 мб оперативки

в чом может быть проблема ?

p.s. приработе не используются начало и конец транзакций может проблема в етом ?

← →
Anatoly Podgoretsky © (2005-11-19 16:24) [1]

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

← →
redlord (2005-11-19 19:08) [2]

хоть листбокс к теме и не относится расказываю зачем он там нужен
основная работа потока заключается в проверке на совпадение данных
в таблице и вновь собранных и чтоб не нагружать сервер sql да и комп с запущенной прогой данные кешируются в листбоксе в нем выполняются все проверки и сравнения вносятся изменения (один поток делает порядка 10000 поверок) также в листбоксе хранится инфа о поле с первичным ключом по которому потом происходит изменение существующих саписей таблици , а ето на порядки быстрее чем передавать
Where F1=.... F2=... Fn=...

← →
Anatoly Podgoretsky © (2005-11-19 19:21) [3]

Все равно не понятно зачем нужен листбокс

← →
Separator © (2005-11-19 19:31) [4]

Может просто ограничение в количестве коннектов. Зайди через Enterprise Manager в Proces Info и посмотри сколько там коннектов. Потом в свойстве базы можно указать количество максимальных коннектов к базе, поставь 0

← →
sniknik © (2005-11-19 20:35) [5]

не. листбокс точно не нужен. (Дяда Вова, скрипачь не нужен... © Кин Дза-Дза)

← →
redlord (2005-11-19 22:54) [6]

колличество коннектов к серверу не ограничено ето я ешо при установки сервака поставил
нужен или не нужен листбокс ето не важно а важно то что заполнять его нечем после енного колличества подключений. хотя инфа в таблице удовлетворяющая запросу точно есть тока по какимто причинам query ее не возвращает

← →
Anatoly Podgoretsky © (2005-11-19 23:06) [7]

Ну как же не важно, это визуальный компонент, а работа с VCL имеет свои особенности.

← →
sniknik © (2005-11-19 23:25) [8]

особеность первая - желательно никаких VCL компонентов в потоках! VCL не thread safe. (однопотоковый)

т.е. скрипачь не нужен ;)

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

← →
redlord (2005-11-20 00:11) [9]

премного извеняюсь не Tlistbox а tstringlist
по чему не датасет потому что поиск в датасете на несколько порядков медленнее чем в стринглист

← →
sniknik © (2005-11-20 00:31) [10]

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

не, стриг грид у тебя тоже конечно может быть сортированн, но, ты туда еще и инфу о ключевом поле пихаеш (число строкой), по которому после соответствие в таблице делаеш > [2], вообше заполняеш (перебор всего рекордсета), т.е. делаеш кучу лишних действий в любом случае и утверждаеш что это быстрее? не смешите мои тапочки.

← →
redlord (2005-11-20 01:44) [11]

про индексы слышал? слышал
разницу между строкой и числом знаеш? знаю
не смешите мои тапочки помоему там про подковы было

вот тока про то что я число в стринг перевожу я не говорил
-----------------------------------------------------------------
sniknik не в обиду
просто напиши небольшой примерчик
в таблице 100000 записей колличество полей 8 поле1 первичный ключ
остальные поля varchar(1024) индексируй как хочеш

задача найти запись (сошедшеюся по значению во всех полях с
искомыми данными кроме первичного ключа так как он тебе не известен и его как минимум надо получить)
при условии что ее порядковый номер в таблице
~=90000 и изменить ее . сколько на ето уйдет времени ??

← →
Separator © (2005-11-20 08:21) [12]

А сколько уйдет времени на запихивание всего этого дела в stringlist? а потом ведь еще нужно и почистить

← →
sniknik © (2005-11-20 10:50) [13]

> сколько на ето уйдет времени ??
а сколько памяти? в твоем варианте
7 * 1024 * 100000 = 716800000байт - 687,59мг. * 2 (данные как минимум в 2х местах у тебя в датасете и стринглисте) = 1367,19мг * 5 (5 одноврменно работающих потока) = 6835,94мг. (т.е. почти 7 гиг. в памяти единомоментно. поиски то по всем делаются, во свех потоках. и это не учитывая доп. нужд. на те же индексы)...
надо не тесты делать, а в консерватории чтото менять. (и при этом жалобы на "сьеденные" 300мг mssql-ем ;о))
у тебя что оперативки 10гиг? думаю нет. но тогда ты "обрекаеш" систему на жуткий свопинг по каждому твоему действию... и говорить о скорости тут не приходится. выжила бы... ;)

> sniknik не в обиду
обижаюсь когда мне врут, а не при обсуждениях чегото.
и не в обиду тебе, ты не то чтобы вреш, но "немного" "приукрашиваеш" свою задачу(вернее решение. оптимизацией которого занимаешся, и нас "припрягаеш", хотя оно в корне неверное имхо(даже не видя что там ;), по разговорам сдесь)), даеш данные на тест "страшнее" чем есть на самом деле, либо не договариваеш (то что тип varchar(1024) это еще не значит что там килобайтная строка... реальный(средний) размер строк не приведен (и может он в среднем 10 байт?), а я буду по максимальным тест делать? а у меня всего 512мг оперативки...).

> помоему там про подковы было
слышал от Жванецкого, у него про тапочки.

по поиску на нормальных данных (помещающихся в оперативке) примерно так (не помню точно, была ветка про замену стринггрида, там проверял(предлагал менять на рекордсет как сам делаю). не нашол), ну так вот там сравнивали на милионе записей текстовое поле 200(примерно) символов, заполнение от 150 до 200 символов, индекс в памяти строится гдето 30сек, дальнейшие локейты/перестроения порядка отображения не засекается (я там проверял по разнице времени, грубо, а надо было точнее по тикам чтобы засеч) т.е. у меня оно (время поиска) равнялось 0.000 сек.
если хочеш сам сделай тест, по моим данным по своему, даже предпочтительнее тебе делать, нужно то тебе и данных я больше привел. сравни.
в той ветке сравнивали стандартный стринг грид с рекордсетом и ArrayGrd отсюда http://home.earthlink.net/~akonshin/delphi_ru.htm. кто победил сказать трудно чтото делалось быстрее одним чтото другим, это варианты под разные задачи (но то что это был не стринг грид точно ;). для многократного поиска тоже однозначно рекордсет был предпочтительнее (ArrayGrd не поддерживает индекси и если при первй сортировке он обгоняет то при последующих того же поля он то же время занимает а у рекордсета повторное время стремится к нулю).

Смею предположить, что используется Table или Query с запросом SELECT * FROM tbl

Как-то тоже так думал, что если перегнать все данные в массив, а потом поиск по нему будет идти быстрей, то сильно ошибся.
Вытаскивал из таблицы порядка 90000 записей, размером от 50 до 100 байт, все текстовое. Так вот, он у меня только ~2 минут заполнял массив, потом конечно искал довольно быстро, но когда все-таки решил все оставить в DataSet, на глаз во всяком случае разници не заметил в поиске, а вот первоночальной задержки не было.

Anatoly Podgoretsky © (20.11.05 11:45) [14]
;)
а для того чтобы быстрее открывалось серверный курсор. а после сравнивается поиск в локальном стринглисте с выборкой с сервера каждой записи, и поиском перебором в рекордсете...

← →
redlord (2005-11-20 16:56) [17]

в моем случае прога поедает во время работы 9 метров нагружает проц
на 02% (5 потоков)
в среднем на выполнение задачи одним потоком уходит 10..13 секунд (загрузить проверить и вернуть в тбл ) приетом поток обрабатывает 20000 записей
НА КАЖДОЙ ПРОВЕРКЕ СТОИТ SLEEP(3)

вот тока не пойму чтож вы до моего stringlist докопались я веть не про ето спрашивал [ смотри вопрос]

> в моем случае прога поедает во время работы 9 метров нагружает проц
не вяжется это с 7 строковыми полями по 1024 байта в пусть даже всего 20000тыс (а не ста как мне говорим) записей, дожно быть 136метров. на один поток, с одним только стринглистом... (я так и знал, хорошо тест не стал делать ;)

> вот тока не пойму чтож вы до моего stringlist докопались я веть не про ето спрашивал [ смотри вопрос]
а по вопросу нет конкретики, а стринг грид есть... и он не нужен.

(- ты суслика видиш? - нет. -и я нет, а он тем не менее есть! ;)

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

(ну вот примерно так с моей точки зрения твой топик и выглядит)
и тут есть один момент. основная задача "купить хлеба" не решается "разгоном феррари". разгон феррари это твоя личная блаж. никакого отношения к задаче/программированию она не имеет (также как использование чегото предназначенного для одного для совершенно другого, хотя есть другое предназначенное именно для этого). все это (пусть некоторые и подсознательно ;) понимают и естественно напрягаться не хотят, такое навязывание средств для решения оно противоестественно. (ну попробуй экскаваторшика на стройке заставить яму лопатой выкопать ;о), там где ему только раз ковшом ковырнуть... а тут.., думаеш есть разница?)

← →
redlord (2005-11-20 19:13) [19]

to sniknik
не можеш помочь так хоть флудить заканчивай

оказ в обслуживании MSSQL server Найти похожие ветки