Громадное время исполнения "тяжелого" скрипта

Dion (19.04.2006)


Неплохая идея, кстати. Правда я нифига в T-SQL не понимаю... А хранимые процедуры пишутся только на этом языке, или это можно как-то сделать на C#, VB.NET?




Хранимки SQL сервера пишутся только на T-SQL.

На шарпе и всем остальном пишутся только клиенты.

snov (04.07.2006) Хранимки SQL сервера пишутся только на T-SQL. На шарпе и всем остальном пишутся только клиенты.

В MSSQL 2005 можно писать хранимые процедуры в управляемом коде.

0

Всем добрый день (впрочем, сейчас ночь...)!
У меня очередная непонятная проблема...
Значит так. Есть одна из задач некоего сайта - апдейт БД
Делается это так:
Скачиваются несколько XML-файлов, обновляемые ID прописываются в специальную таблицу, разные данные заносятся в соответствующие таблицы (структура имеет аж 3 уровня "наследования", всякие внешние ключи и т.д.).

Вносится 16000 записей по объектам такого рода, как недвижимость. Кроме основных записей вносятся где-то на 200 более записей в другие 4 таблицы и по-мелочи в таблицы всяких городов, типов, названий и т.п.

Я в отчаянии. Проект уже сегодня-завтра сдавать, всё вылизано, но апдейт на удалённом сервере тормозит несщадно, хотя у меня всё в пределах нормы. [bold]ПОЧЕМУ???[/bold]

Расклад по серверам такой.
Дома: Pentium IV 2.8 GHz, 512RAM DDR-400, ATA-133 диск, Windows XP Professional, MS SQL Server 2000 Desktop Engine, IIS 5 и .NET (но он не используется). + к этому работают всякие обычные бытовые программы, клиенты и т.п. Замечу, что базы SQL хранятся на том же диске и даже разделе, что и система, а подкачка (1Гб, постоянный) - на другом.
Время выполнения скрипта (без учёта загрузки картинок) - 3 минуты. (+ ещё 3 минуты предполагается на загрузку тормозных XML)

У заказчика: Xeon 3.2 GHz, 256 RAM (не знаю какого), какие-то виртуальные драйвы, базы и система находятся на разных разделах. Подкачка - на системном, 384-768 переменный.

Время выполнения скрипта (с загрузкой этих самых картинок) - предполагается час- полтара, ибо он всё ещё делается и работу где-то на половину/треть он сделал за полчаса.

Я понимаю, картинки - это ресурсоёмко, но картинок там на 500 МБ, скрипт оптимизирован как это только возможно вообще при работе с XML и SQL Server. Скорость соединения там высокая - около 16 МБит, хотя я так до конца её и не вычислил.

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

Плохо ещё то, что в администрировании _серверов_ я мало что понимаю...
Собственные эмперические подозрения такие:
1. Может тормозить тот сервак, с которого забираются картинки, ибо XML, например, он выдаёт с тормозами. Если это вероятно, то это хорошо, ибо с меня ответственность слетает.
2. Может тормозить из-за каких-нибудь настроек или особенностей железа SQL Server, потому что одну из операций (которая не связана с удаленными соединениями) заполнения новых АйДишников скрипт выполняет у меня дома секунд за 20, а на том сервере - минуты за 2. Это хуже, т.к. неясно, что дальше делать кроме смены сервака.
3. Сервер ограничивает расход ресурсов.

Если смотреть на Task Manager, то он выдаёт интересные подсказки:
ВО время выполнения скрипта.
CPU Usage Av: 10%, Peak:42% в одно время и Av: 30%, Peak: 97% в другое
Networkork usage Av: 3-4%, Peak:13%
PF: 360 MB где-то.
RAM: во время выполнения достаточно быстро падает (10 МБ за 18 сек) и иногда доходит до 8 МБ и там остаётся.

Вижу, что какие-то параметры неоптимизированы, но какие? У заказчиков есть какой-то администратор, но, видимо, он этим сервером не занимался...

16000 записей + 200 - это для сервака ерунда. Тормоза связаны не с числом записей, а как мне видится с средством, с помощью которого Вы запускаете скрипт, и которое, собственно, взаимодействует с сервером БД. Кстати, интересно узнать что за скрипт? VBS? SQL? С помощью чего Вы запускаете скрипт? wscript или еще как-то?

0

Сообщение от daarg 16000 записей + 200 - это для сервака ерунда. Тормоза связаны не с числом записей, а как мне видится с средством, с помощью которого Вы запускаете скрипт, и которое, собственно, взаимодействует с сервером БД. Кстати, интересно узнать что за скрипт? VBS? SQL? С помощью чего Вы запускаете скрипт? wscript или еще как-то?

Скрипт - это ASP (VBScript), использует adodb.connection с провайдером olesqldb. В него методом execute вносятся SQL-комманды. Буферизовать этот процесс и прогнать по одной транзакции не представляется возможным, т.к. в разные таблицы вносятся зависимые друг от друга данные и скрипт следит за IDENTITY.

То, что 16000 записей для сервака должно быть ерундой, я догадываюсь. Дома то всё быстро. Запуск обычный, через вызов по URL.

Лучше такие задачи делать без ASP. Из-за него и тормозит. Потому что через IIS пытаетесь выполнить на SQL довольно тяжелую задачу.
Да и зачем тут ASP? Показать девочке-менеджеру, что БД проапдейтилась успешно и вывести в браузере "все OK"?
Представьте, что Ваша БД увеличилась раз так в 5. И что тогда? Полное зависание задачи?
Я б всю эту задачу сделал вообще через консольное приложение, например на VB.NET (или C#) и запускал его по расписанию - шедулером Windows - самый лучший вариант.
Еще вариант - реализовать логику в ХП на SQL и запускать эти ХП через утилитку isql через батник. Это если у вас нет обработки внешних ресурсов, например каких-нибудь файлов.
VBS+wscript.exe - не советую. Очень быстро нарветесь на те же тормоза.

0

Сообщение от daarg Лучше такие задачи делать без ASP. Из-за него и тормозит. Потому что через IIS пытаетесь выполнить на SQL довольно тяжелую задачу. Да и зачем тут ASP? Показать девочке-менеджеру, что БД проапдейтилась успешно и вывести в браузере "все OK"? Представьте, что Ваша БД увеличилась раз так в 5. И что тогда? Полное зависание задачи? Я б всю эту задачу сделал вообще через консольное приложение, например на VB.NET (или C#) и запускал его по расписанию - шедулером Windows - самый лучший вариант. Еще вариант - реализовать логику в ХП на SQL и запускать эти ХП через утилитку isql через батник. Это если у вас нет обработки внешних ресурсов, например каких-нибудь файлов. VBS+wscript.exe - не советую. Очень быстро нарветесь на те же тормоза.

Хмм... Ну консольное приложение на VB.NET - это интересный вариант, наверное стоит подумать... Правда ещё не факт, что я это осилю - с нормальным Visual Basic стал ознакамливаться совсе надвано и опя-таки больше в парадигме ASP.NET

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

Увы, не нашёл редактирования...
По поводу масштабируемости - тут уже всё чуть-чуть лучше, т.к. во время планового апдейта скрипт исполняется минут за 10, т.к. происходит только удаление старья и добавление новья. Хотя и это должно быть быстрее, особенно странно то, что минуты 2 уходит на примерно такую фигню:

for each item in xml_document.childNodes
'Заполнить простую табличку id-шниками из свежего xml
sql.exec("insert into id_list value(" & item.getSingleNode("id").Text & ")")
next
'Удалить все неактуальное - может запросы у меня плохие?
sql.exec("delete from main where id not in (select id from id_list)")

Потому что вы в цикле для каждого итема из XML вызываете БД (command.execute). Вдвойне нагружаете сервак - действуете с XML и SQL - в одном месте программы.
Не проще ли сформировать строку из Node("id").Text через запятую, закрыть XML, а потом написать одну(!) ХП и в нее (без каких-либо циклов) совать эту строку как параметр и в этой же ХП потом удалять все неактуальное.
А отличие в производительности на боевом сервере и дома только в том, что боевой загружен видимо еще какими-то процессами.

0

еще...такие вещи как <<sql.exec("delete from main where id not in (select id from id_list)")>>
делать не совсем корректно опять же с точки зрения производительности. Пишите такие запросы через хранимые процедуры. Отличие в том , что ХП уже скомпилированы на SQL, и соответственно выполняются быстрее.

0

Сообщение от daarg Потому что вы в цикле для каждого итема из XML вызываете БД (command.execute). Вдвойне нагружаете сервак - действуете с XML и SQL - в одном месте программы. Не проще ли сформировать строку из Node("id").Text через запятую, закрыть XML, а потом написать одну(!) ХП и в нее (без каких-либо циклов) совать эту строку как параметр и в этой же ХП потом удалять все неактуальное. А отличие в производительности на боевом сервере и дома только в том, что боевой загружен видимо еще какими-то процессами.

Неплохая идея, кстати. Правда я нифига в T-SQL не понимаю... А хранимые процедуры пишутся только на этом языке, или это можно как-то сделать на C#, VB.NET?

RTFM

0