|
|
|
Junior Member
 
участник
Last Login: 07.07.2007 21:50
Сообщ.: 21,
Visits: 144
|
|
Всем добрый день (впрочем, сейчас ночь...)!
У меня очередная непонятная проблема...
Значит так. Есть одна из задач некоего сайта - апдейт БД
Делается это так:
Скачиваются несколько 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 МБ и там остаётся.
Вижу, что какие-то параметры неоптимизированы, но какие? У заказчиков есть какой-то администратор, но, видимо, он этим сервером не занимался...
|
|
|
|
|
Supreme Being
участник
Last Login: 27.10.2006 10:12
Сообщ.: 179,
Visits: 1 960
|
|
16000 записей + 200 - это для сервака ерунда. Тормоза связаны не с числом записей, а как мне видится с средством, с помощью которого Вы запускаете скрипт, и которое, собственно, взаимодействует с сервером БД. Кстати, интересно узнать что за скрипт? VBS? SQL? С помощью чего Вы запускаете скрипт? wscript или еще как-то?
|
|
|
|
|
Junior Member
участник
Last Login: 07.07.2007 21:50
Сообщ.: 21,
Visits: 144
|
|
[quote="daarg"]16000 записей + 200 - это для сервака ерунда. Тормоза связаны не с числом записей, а как мне видится с средством, с помощью которого Вы запускаете скрипт, и которое, собственно, взаимодействует с сервером БД. Кстати, интересно узнать что за скрипт? VBS? SQL? С помощью чего Вы запускаете скрипт? wscript или еще как-то?
[/quote]
Скрипт - это ASP (VBScript), использует adodb.connection с провайдером olesqldb. В него методом execute вносятся SQL-комманды. Буферизовать этот процесс и прогнать по одной транзакции не представляется возможным, т.к. в разные таблицы вносятся зависимые друг от друга данные и скрипт следит за IDENTITY.
То, что 16000 записей для сервака должно быть ерундой, я догадываюсь. Дома то всё быстро. Запуск обычный, через вызов по URL.
|
|
|
|
|
Supreme Being
участник
Last Login: 27.10.2006 10:12
Сообщ.: 179,
Visits: 1 960
|
|
Лучше такие задачи делать без ASP. Из-за него и тормозит. Потому что через IIS пытаетесь выполнить на SQL довольно тяжелую задачу.
Да и зачем тут ASP? Показать девочке-менеджеру, что БД проапдейтилась успешно и вывести в браузере "все OK"? ;)
Представьте, что Ваша БД увеличилась раз так в 5. И что тогда? Полное зависание задачи?
Я б всю эту задачу сделал вообще через консольное приложение, например на VB.NET (или C#) и запускал его по расписанию - шедулером Windows - самый лучший вариант.
Еще вариант - реализовать логику в ХП на SQL и запускать эти ХП через утилитку isql через батник. Это если у вас нет обработки внешних ресурсов, например каких-нибудь файлов.
VBS+wscript.exe - не советую. Очень быстро нарветесь на те же тормоза.
|
|
|
|
|
Junior Member
участник
Last Login: 07.07.2007 21:50
Сообщ.: 21,
Visits: 144
|
|
[quote="daarg"]Лучше такие задачи делать без ASP. Из-за него и тормозит. Потому что через IIS пытаетесь выполнить на SQL довольно тяжелую задачу.
Да и зачем тут ASP? Показать девочке-менеджеру, что БД проапдейтилась успешно и вывести в браузере "все OK"? ;)
Представьте, что Ваша БД увеличилась раз так в 5. И что тогда? Полное зависание задачи?
Я б всю эту задачу сделал вообще через консольное приложение, например на VB.NET (или C#) и запускал его по расписанию - шедулером Windows - самый лучший вариант.
Еще вариант - реализовать логику в ХП на SQL и запускать эти ХП через утилитку isql через батник. Это если у вас нет обработки внешних ресурсов, например каких-нибудь файлов.
VBS+wscript.exe - не советую. Очень быстро нарветесь на те же тормоза.
[/quote]
Хмм... Ну консольное приложение на VB.NET - это интересный вариант, наверное стоит подумать... Правда ещё не факт, что я это осилю - с нормальным Visual Basic стал ознакамливаться совсе надвано и опя-таки больше в парадигме ASP.NET
Ну тогда всё равно неясно, что-ж оно у меня дома то так шустренько исполняется. Я бы не сказал, что у меня дико профессиональная машина и уж тем более, система, хотя она и затачивалась под прожорливый музыкальный софт
|
|
|
|
|
Junior Member
участник
Last Login: 07.07.2007 21:50
Сообщ.: 21,
Visits: 144
|
|
Увы, не нашёл редактирования...
По поводу масштабируемости - тут уже всё чуть-чуть лучше, т.к. во время планового апдейта скрипт исполняется минут за 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)")
|
|
|
|
|
Supreme Being
участник
Last Login: 27.10.2006 10:12
Сообщ.: 179,
Visits: 1 960
|
|
Потому что вы в цикле для каждого итема из XML вызываете БД (command.execute). Вдвойне нагружаете сервак - действуете с XML и SQL - в одном месте программы.
Не проще ли сформировать строку из Node("id").Text через запятую, закрыть XML, а потом написать одну(!) ХП и в нее (без каких-либо циклов) совать эту строку как параметр и в этой же ХП потом удалять все неактуальное.
А отличие в производительности на боевом сервере и дома только в том, что боевой загружен видимо еще какими-то процессами.
|
|
|
|
|
Supreme Being
участник
Last Login: 27.10.2006 10:12
Сообщ.: 179,
Visits: 1 960
|
|
еще...такие вещи как <>
делать не совсем корректно опять же с точки зрения производительности. Пишите такие запросы через хранимые процедуры. Отличие в том , что ХП уже скомпилированы на SQL, и соответственно выполняются быстрее.
|
|
|
| | |