Deutsch
Germany.ruФорумы → Архив Досок→ Программирование

​Совсем не понимаю...

683  
Murr патриот06.07.18 11:37
Murr
NEW 06.07.18 11:37 

Совсем не понимаю...


Простая функция (код не мой - можно тапки бросать мимо):

Public Function fillDT(ByVal sql As String) As DataTable
Dim oraCN As New OracleConnection
Dim oraDA As New Oracle.DataAccess.Client.OracleDataAdapter
Dim DT As New DataTable
Dim oraCmd As New OracleCommand
Try
oraCN.ConnectionString = _connectionString
oraCN.Open()
Debug.Print(sql)
oraCmd.CommandText = sql
oraDA.SelectCommand = oraCmd
oraDA.SelectCommand.Connection = oraCN

DT.Columns.GetEnumerator()
oraDA.Fill(DT)

Return DT
Catch ex As Exception
Email.SendMailMessage(_senderAddress, My.Settings.emailErrorRecipient, "", "", _
My.Computer.Name.ToString & ": " & _
"error in: DANenprod1." & _
System.Reflection.MethodBase.GetCurrentMethod.Name.ToString, _
sql & ControlChars.CrLf & _
ex.ToString)
Return DT
Finally
oraCN.Dispose()
End Try

End Function

Успешно работала несколько лет.

Никаких изменений в код мною не вносилось.

Передаваемая СКЛ-строка - сложная, но относительно быстрая - в дбФорже-студии выполняется за 1.578 сек.


Что могло измениться так, что oraDA.Fill(DT) не может выполнится в течении 12-15 часов?

Ошибок выполнения или таймаутов - нет.

Данных - да, много, но ведь работало...

#1 
Murr патриот06.07.18 15:11
Murr
06.07.18 15:11 
в ответ Murr 06.07.18 11:37

Хммм...

Север точно отдает данные...

Весь набор строится... за пару секунд...

Весь набор можно читать... если читать оракловским реадером - где-то за 56 секунд... это трансфер по сети и навигация по записям...

Весь набор можно загнать в таблицу... построчно... читаем поля, формируем строку, добавляем в таблицу... где-то 10 минут...


Что-же, пилять, билли забубенил в винде, что процессу не хватает 16 часов?..

#2 
Murr патриот09.07.18 10:02
Murr
NEW 09.07.18 10:02 
в ответ Murr 06.07.18 15:11

За выходные успел померить время и объем данных которое перекачиваются по запросу.

Данных "не много" - 130 Мб... время перекидывания с сервера на клиента - 2 часа 39 минут...

С утра, пока никого не было, шеф запустил запросик и за 20 минут все получил...

Сейчас - все в работе и... все, задница - полтора часа,,,


Как решать - не представляю...

Могу понизить объем данных для перекачки где-то в два раза, но это только за счет отсечения

условно-устаревших данных...

Могу еще извратится с хранением основного массива на клиенте и переброской дельты, но

тут работы дохрена... и в пустую - скоро переход на новую систему,,,


В общем - пока на все плюну... даже на недоделанный репорт... и погляжу в аутентификацию

пользователей и лицензирование под ВKФ...

#3 
eklmn постоялец09.07.18 10:58
eklmn
NEW 09.07.18 10:58 
в ответ Murr 06.07.18 11:37

Проблемы с железом исключил?

#4 
Murr патриот09.07.18 12:56
Murr
NEW 09.07.18 12:56 
в ответ eklmn 09.07.18 10:58

Проблемы с железом не являются моими проблемами.

А так - да, "исключил" - не хватает ресурсов (памяти) на сервере для всех юзверей, он свопит по черному и отдает все медленно.

#5 
Murr патриот16.07.18 13:42
Murr
NEW 16.07.18 13:42 
в ответ Murr 09.07.18 12:56
<p>Обнаружилось следующее.</p><p>Оракле имеет свой свап/каш... и этот кеш отвалился... почему - не знаю, не моя епархия...</p><p>Сделал следующее - на сервере закачал все данные в локальную таблицу вместо кеша.</p><p>Запрос на заполнение таблицы выполнился за 4 сек. </p><p>Перевел все на выборку из этой таблицы.</p><p><br></p><p>Не помогло - данные с Оракла по прежнему поступают в час по чайной ложке.</p><p>Можно посмотреть как пишутся на диск - Фар волне отрисовывает построчные записи.</p><p><br></p><p>Сейчас колдую с буфферизацей. Может пошло чуток быстрее, но не сильно...</p><p><br></p><p>Где копать уже не представляю...</p><p><br></p><p>Кто посоветует что поковырять?</p>
#6 
Murr патриот16.07.18 18:41
Murr
NEW 16.07.18 18:41 
в ответ Murr 16.07.18 13:42

Выяснилась еще одна интересная штука - если экспортировать в ЦСВ прямо на сервере - процесс занимает всего секунд 10...


Получается, что где-то что-то с сеткой... но по сетке все летает - 60-70 мб...


Ни черта не понимаю... хммм

#7 
Murr патриот17.07.18 12:36
Murr
NEW 17.07.18 12:36 
в ответ Murr 16.07.18 18:41

Померял реальный трансфер с сервера на клиента.

Общее время трансфера - чуть больше 5 секунд. Остальные 49 минут - чтение полей данных из стрема...


Не понимаю что поменялось настолько, что все начало тормозить...


Блин, видимо придется тестить время чтения каждого отдельного поля... пипец...

#8 
Murr патриот17.07.18 18:29
Murr
NEW 17.07.18 18:29 
в ответ Murr 17.07.18 12:36

Кажется нашел возможную причину....


Не уверен, но...


- одно из полей имело значение NULL

- после замены значения поля протестировал загрузку по отдельным полям - время сократилось до 8 минут.


Никак не могли быстро обработать NULL?


Надо посмотреть что будет на стандартной загрузке таблицы...

#9 
Murr патриот18.07.18 18:25
Murr
NEW 18.07.18 18:25 
в ответ Murr 17.07.18 18:29

Кажется Я вообще ничего не понимаю...


Есть Оракла 10Г на линуксовой машине.

Стоит. Работает. Ну как может так и работает.


Есть несложная процедура обновляющая несколько неприятно больших таблиц.

В результате всех обновлений в интересующей таблице получается 35К записей по 173 поля. Длинна отдельной записи - <5К. Всего около 170 Мб.


Перебрал все возможные варианты чтения и выбрал самый быстрый - датареадером, по отдельным полям, с непосредственным указанием типа - GetString(i), GetNumeric(i), GetDateTime(i).

Процесс загрузки данных занимает 33 минуты... это вместо нескольких часов по филл(дататабле)...

Распределение времени следующее:


Read Time : 00:00:09.9054802

Value Time : 00:32:10.6379357

DT op Time : 00:00:01.8005709


Execution time (FL2DT)00:32:28.2043131

String : 00:04:28.2550130 (00:00:03.1365717/per field)

Numeric : 00:13:45.4187597 (00:00:03.2605435/per field)

DateTime : 00:13:56.9372428 (00:00:03.2190423/per field)


Первая строка - время трансфера с сервера и нарезания на строки.

Вторая строка - время извлечения данных из строки в поля датаров...

Третья строка - время операций с дататабле.

Ниже - распределение времени по типам полей (по сумме 35К записей).


Еще две цифирьки:

Execution time (DT2XML)00:00:11.0342339

Execution time (XML2DT)00:00:06.3511341


Первая строка - время записи схемы и данных (35К строк) из дататабле в файл (на локальный диск)

Вторая строка - время чтения схемы и данных (35Кстрок) из файла в дататабле.

Размер хмл-файла на диске - 250 Мб.


У меня снова тот же вопросик - Что сумели поменять так, что чтение данных в таблицу занимает полчаса вместо 7 секунд?


Я просто на понимаю - что можно было поменять в плане почти автономной Оракле.ДатаАкксесс.Длл чтобы она начала работать на несколько порядков медленнее?

#10 
Kvasimoda коренной житель19.07.18 12:01
Kvasimoda
NEW 19.07.18 12:01 
в ответ Murr 06.07.18 11:37

Проверь firewall, а точнее отключи его (если есть такая возможность)

#11 
Murr патриот19.07.18 16:53
Murr
NEW 19.07.18 16:53 
в ответ Kvasimoda 19.07.18 12:01

Внутренний файрволл - выключен.

Есть внешний, доставляющий много хлопот, но вроде как на данную ситуацию не влияющий.

#12 
Murr патриот19.07.18 18:48
Murr
NEW 19.07.18 18:48 
в ответ Murr 19.07.18 16:53

Согнал время до 7 минут.

При этом апдейт таблицы - 1.5 мин,

Загрузка с Оракла - 4.5 минуты.

Загрузка в ДатаТабле из файла - 5-6 секунд.

Ээээ... дамп файла на сервере - 5-8 секунд и еще 5-7 секунд - перекачка по сетке...


Завтра надо слепить процедурку экспорта файла на сервере и закачку его в таблицу... будет около 2-х минут. up


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

#13 
soarian местный житель19.07.18 19:55
soarian
NEW 19.07.18 19:55 
в ответ Murr 19.07.18 18:48

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

Тёмные аллеи
#14 
Murr патриот20.07.18 10:05
Murr
NEW 20.07.18 10:05 
в ответ soarian 19.07.18 19:55

Пропорционально.

Там где выведено время обработки поля - это на 35К записей, на 10 записей - будет в 35К раз меньше.

Но мне нужен весь объем данных.


Если была мысль закачать пакетами по 10-100-1000 строк - будет много медленнее, чем целиком.

#15 
soarian местный житель20.07.18 11:06
soarian
NEW 20.07.18 11:06 
в ответ Murr 20.07.18 10:05
Данных "не много" - 130 Мб... время перекидывания с сервера на клиента - 2 часа 39 минут

это конечно не нормально!

Подозреваю, что может воновата Fill(). Типичное явление на практике, что эта метода влечёт за собой в SQL Server так называемый ASYNC_NETWORK_IO вартетип, в Оракле тоже есть подобный IO Wait.
Как решение обычно предлагается сократить количество строк или модифицировать Fill(). Как, к сожалению не могу так сразу сказать, поскольку другой у меня schwerpunkt

Тёмные аллеи
#16 
Murr патриот20.07.18 15:50
Murr
NEW 20.07.18 15:50 
в ответ soarian 20.07.18 11:06

или модифицировать Fill().

------

Снова имеется интересная мысль!

Модифицировать код из Oracle.DataAccess.dll... хаха

Стандартный, работающий в куче приложений....



Оракле тоже есть подобный IO Wait.

-----

Да, но у меня - не используется - стандартная синхронная загрузка.


Просто не понимаю почему читается только 15-17 строк в секунду...

Пусть их 20 в секунду, по 200 полей - 4000 чтений элементов массива в памяти в секунду...

Бред... но именно так и происходит.

На И8080А Я бы это еще понял... но и там Я это делал быстрее...





#17 
Murr патриот20.07.18 17:07
Murr
NEW 20.07.18 17:07 
в ответ Murr 20.07.18 15:50

Нашел.


Можно смеяться, Но дело было так...


Кто-то умный решил что новый станок можно включить в систему элементарно прописав его в базу.

Станок то он прописал, но вот выполняемые им процедуры описал не корректно - в одном тексте

вместо PVB, было написано PV2.


Дальше это PV2 использовалась как часть имени поля... ну так код слеплен - вместо нормального

Трансформ используется сильно синтетическая и предопределенная выборка с последующим

заполнением таблицы данными.


При обращении к таблице за данным полем получался вполне ожидаемый фаулт.


По факту такого безобразия программка должна была сообщать по е-майлу с указанием

кучи деталей об что, где, когда...


Но как обычно сетевики что-то нахомутали с почтовиком и вместо отправления сообщения

получалось отсутствие соединения, которое через пару секунд выливалось по таймауту и

почему-то сопровождалось Socket Error и последующими тормозами по всем операциям с

данными из сети.


Сколько именно система ждала тайм-аутов от мыльного сервера - непонятно - там где процедура

была задействована - там и ждала, но, похоже, как раз все время - 16-20+ часов...


По крайней мере сейчас все по еле-еле но телепается....


Пыххх... Я таки утомился...

#18 
Murr патриот24.07.18 09:57
Murr
NEW 24.07.18 09:57 
в ответ Murr 20.07.18 17:07

И все же работает медленно.


Причем медленно - именно чтение полей из реадера. Все остальное - типа Филл() - еще медленнее.

Пака не понял как ускорить, кроме как скинуть в файл и выкачать один БЛОБ...


Есть какие идеи как быстро перекачать 200Мб из базы в ДатаТабле?

#19