|
|
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
Где искать потерю производительности? Оракле 10Г, старая база где-то 300 и еще одна на 400 таблиц. Работает на Линуксе. Каких-либо изменений там в последнее время не производилось. Клиенты - разные - WinXP, Win7, WIn10. WinXP уже не апдейтится - можно исключить патчи от мелкомягких. А проблемы с производительностью у них одинаковые. Приложение тоже старое, VB.NET в стиле VB6 - тексты запросов перемешаны с управлением визуальными элементами. Разобраться в коде и пофиксить все узкие места - почти не реально. Новая версия в разработке, но в ней появились те же самые проблемы с производительностью по загрузке данных. Производительность приложения просела где-то 2 недели назад. Просела существенно - с цикла длящегося 40 минут приложение только на загрузку основных данных тратит более 16 часов. "Обмолот" данных - вообще несколько суток. "Основной" запрос возвращает таблицу из ~35К записей по 173 поля. Длинна одной записи - порядка 8К. Всего 170 Мб. Время выполнения запроса сервером - порядка 4-х секунд. Время трансфера данных по сети - порядка 8-10 секунд. Ошибок в процессе передачи данных - не фиксируется. Дальше начинается непонятное. Время заполнения DataTable стандартным Fill() OracleDataAdaptor - изменилось с примерно 10 минут до несколько часов. Переделал загрузку на чтение полей из DataReader'a - стало полегче - время загрузки сократилось до 35 минут. Переделал еще раз - на стороне сервера врапирую строки в хмл-формат, на клиенте - собираю в файл (250Mb) и поднимаю в дататабле посредством ReadXml(). Время сократилось до 5 минут. Могу переделать еще раз - сформировать файл на сервере, перекинуть его на клиента и стандартно загрузить по ReadXml(). По сумме времени будет меньше минуты. Сам подъем данных из хмл-файла в DataTable занимает несколько секунд. Но это - решение для одного "узкого" места. А запросов к базе - много. Запросы - разные. Выявить все места и как-то их обойти - возможности нет. Обычно эти запросы - короткие, возвращают немного данных - на них изменение производительности незаметно. Но этих запросов - много и, Я подозреваю, у них те же самые задержки с конвертацией потока с сервера в дататабле. Я просмотрел код оракловских реадеров. Чего-то, что могло бы существенно - с 10 минут на несколько часов - влиять на время извлечения данных там не нашел. С профайлером Студии 2017 - пока не разобрался - у меня он не запускается. В общем - не понимаю куда дальше копать. Пните, плс, по направлению... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 13:22 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
PinkCatНовая версия в разработке, но в ней появились те же самые проблемы с производительностью по загрузке данных.Код не скопипастили ли? PinkCatПроизводительность приложения просела где-то 2 недели назад.Логи смотрел? Для клиентской части СКВ есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 13:30 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
Для начала на хосте смотри CPU память ввод/вывод по дискам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 13:30 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
Код не скопипастили ли? ----- Код не копипастили. Есть тесты независящие от кода приложения - на них тоже идет существенное увеличение времени. Логи смотрел? Для клиентской части СКВ есть? ----- Есть лог приложения - он нормальный - все запросы - выполняются, данные - получаются. Что такое СКВ и как его делать? Сорри, не профи Я в Оракле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 13:43 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
landy, CPU - 25%, один поток, одно ядро. Memory - 60% Hard Drive - несколько секунд на поднятие всего объема данных из хмл-файла. У меня своп лежит на ССД - я не увижу большой разницы даже если свопит. И это - проблема не на одной машине - проблема одинаковая на разных машинах, в том числе и на тех, которые не апдейтятся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 13:49 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
PinkCatЧто такое СКВ и как его делать? Сорри, не профи Я в Оракле.Система контроля версий. Смотреть коммиты двухнедельной давности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 13:50 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
Только что закончился один из расчетов, по которому померил время. Обрабатывалось исходных 1000 строк. На каждую строку выполнялось по 5 запросов. Результаты запросов - 10-15 строк по 11 полей. Итого - 1000 х 5 х 10 х 11 = ~700.000 чтений полей - 26 минут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 13:56 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
шК0ДЕР, Аааа... код без изменений с 2014 года... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 13:57 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
И это - проблема не на одной машине - проблема одинаковая на разных машинах, в том числе и на тех, которые не апдейтятся. Так они наверное с БД работают БД тормозит смотри iostatat -xm 1 sar Какие запросы на БД в топе, какие ожидания и т д ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 14:09 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
landy, > БД тормозит Всего 170 Мб. Время выполнения запроса сервером - порядка 4-х секунд. Время трансфера данных по сети - порядка 8-10 секунд. Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. Распределение времени: Read Time : - 5 сек - +/- ожидаемое время трансфера по сети Value Time : - 30 минут Если добавить помещение данных в DataTable, то там добавится пара секунд. Чего Я не понимаю - откуда берутся 30 минут и где искать почему они 30 минут, а не 10 секунд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 14:20 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
Всего 170 Мб. Ну и что? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 14:31 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
В той сети где это работает скорость передачи данных 60-80 мб/сек - это порядка 3-5 сек перегона данных по сети. Тесты говорят что именно это время затрачивается на перекачку. Т.е. - нет существенных проблем ни на сервере, ни в сети. Если Я правильно понимаю, то reader.Read() гарантирует что запись либо считана, либо ее нет, либо ошибка. Если она считана, то считана полностью - никаких подгрузок данных в процессе чтения полей не будет. Тратит reader на это практически ноль времени в дополнение к трансферу по сети. Затем - читаются данные из строки. Это чтение у меня сейчас происходит со скоростью 15-17 строк по 173 поля в секунду. Такое же чтение и тех же данных, но из хмл-файла, выполняется с скоростью 6-7.000 строк в секунду. Разница - 3 порядка. Откуда? Непонимаю... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 14:50 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
Ну так запусти на своей балалайке профайлер и посмотри Какое это отношение имеет к Oracle? Только то, что у тебя к нему коннект? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 14:53 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
Ну так запусти на своей балалайке профайлер и посмотри ----- Идея - интересная. Особенно в свете того, что тайминги Я уже как мог снял, а Студийный профайлер - отвалился. А как профайлить код из Oracle.DataAcess.dll version 10G x64? PDB у меня нет. Xmmm... х86 - тоже тормозит... Пишу же внятно - нет понимания причин данной ситуации и нет понимания куда копать. Что могу - проверяю, но яснее - не становится. Пока исключены: - проблемы на сервере - проблемы в сети - проблемы апдейтов от microsoft Что еще можно поковырять? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 15:10 |
|
||
|
Где искать потерю производительности?
|
|||
|---|---|---|---|
|
#18+
Можно смеяться, но дело было так... Кто-то умный решил что новый станок можно включить в систему элементарно прописав его в базу. Станок то он прописал, но вот выполняемые им процедуры описал не корректно - в одном тексте вместо PVB, было написано PV2. Дальше это PV2 использовалась как часть имени поля... ну так код слеплен - вместо нормального Трансформ используется сильно синтетическая и предопределенная выборка с последующим заполнением таблицы данными. При обращении к таблице за данным полем получался вполне ожидаемый фаулт. По факту такого безобразия программка должна была сообщать по е-майлу с указанием кучи деталей об что, где, когда... Но как обычно сетевики что-то нахомутали с почтовиком и вместо отправления сообщения получалось отсутствие соединения, которое через пару секунд выливалось по таймауту и почему-то сопровождалось Socket Error и последующими тормозами по всем операциям с данными из сети. Сколько именно система ждала тайм-аутов от мыльного сервера - непонятно - там где процедура была задействована - там и ждала, но, похоже, как раз все время - 16-20+ часов... По крайней мере сейчас все по еле-еле но телепается.... Спасибо всем кто откликнулся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2018, 18:22 |
|
||
|
|

start [/forum/topic.php?fid=52&gotonew=1&tid=1883705]: |
0ms |
get settings: |
6ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
167ms |
get topic data: |
12ms |
get first new msg: |
7ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 516ms |

| 0 / 0 |
