Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
26.11.2021, 09:00
|
|||
---|---|---|---|
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
Здравствуйте, есть метод, который грубо говоря делает следующее: принимает в качестве параметра список ID, по каждому из которых надо сходить в базу данных и стянуть еще дополнительную информацию. То есть нужно сделать около 300-400 небольших запросов последовательно. В качестве клиента подключения для базы данных используется Oracle.ManagedDataAccess.Core 3.21.4 В качестве текущей версии фреймворка: NET5. Код: 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.
Проблема в том, что на выполнение одного прогона метода уходит дополнительно +80 мб RAM при дебажной конфигурации- вряд ли при релизной она как-нибудь починится. Причем память растет с каждым вызовом, может до 1.3 GB вырасти и GarbageCollector не спешит её чистить. При анализе снимков обнаружено, что самым занимаемым компонентом в памяти является OracleInternal.Common.ZoneValue. Соответственно вопрос- как можно ограничить в аппетитах этот OracleInternal.Common.ZoneValue? Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
|
26.11.2021, 09:51
|
|||
---|---|---|---|
|
|||
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
Перегнать IEnumerable<FromExcelDto> (эти самые xlItems) в xml, передать его на сервер, там распарсить (300-400 узлов - это, в общем-то, ерунда), и получить всё требуемое одним запросом не пробовали? vb_sub +80 мб RAM при дебажной конфигурации- вряд ли при релизной она как-нибудь починится. Почему вряд ли? Дебаг в памяти держит очень много всякого, чего не держит релиз. Я бы проверил и убедился. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
26.11.2021, 10:04
|
|||
---|---|---|---|
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
Сон Веры Павловны, к сожалению доступ к администрированию БД отсутствует, поэтому не могу создавать свои обработки. Сон Веры Павловныполучить всё требуемое одним запросом не пробовали Рассматривал такие варианты, но теоретически они мне показались один хуже другого и точно хуже выше описанного варианта. 1) Создать один мега запрос вида Код: plsql 1.
, где (1,2,3,4,5,6 ...400) - составленно из списка IEnumerable<FromExcelDto> 2)Создать один запрос, который возвращает multySet результатов Код: plsql 1. 2. 3. 4. 5. 6.
Возможно эти два варианта даже полностью решат проблему с памятью на клиентском приложении, но от них уже станет плохо базе данных- таким образом я просто передислоцирую проблему в другое место, но не устраню её. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
26.11.2021, 10:11
|
|||
---|---|---|---|
|
|||
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
vb_sub и точно хуже выше описанного варианта Эм. На основании чего был сделан такой вывод? Планы запросов смотрели? Трейсы снимали? Ещё, как вариант, в транзакции залить список в GTT, используя array binding, и выполнять запрос с джойном к GTT. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
26.11.2021, 10:14
|
|||
---|---|---|---|
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
Сон Веры Павловны, попробую протестировать на практике. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
26.11.2021, 19:44
|
|||
---|---|---|---|
|
|||
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
vb_sub, А через временную таблицу? Сначала туда загнать (INSERT tmp (ID) VALUES (1)), а потом временную таблицу использовать в запросе. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
27.11.2021, 04:18
|
|||
---|---|---|---|
|
|||
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
Сон Веры Павловны Ещё, как вариант, в транзакции залить список в GTT, используя array binding, и выполнять запрос с джойном к GTT. SergiiW Сначала туда загнать (INSERT tmp (ID) VALUES (1)), а потом временную таблицу использовать в запросе. GTT (global temporary table) - это и есть оракловая временная таблица, а array binding - некий аналог MSSQL'ного bulk insert. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.11.2021, 09:40
|
|||
---|---|---|---|
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
В общем поэкспериментировал я с разными вариантами реализации и пришел к выводу, что оверхед возникает не в момент многократного вызова комманд. Я перевел текст запроса параметрами в строковую константу и однократно отправил её для получения данных - в итоге получил такое же RAM потребление, как и в первом сообщении. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.11.2021, 19:47
|
|||
---|---|---|---|
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
А если попробовать по старинке через DataReader? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
29.11.2021, 23:45
|
|||
---|---|---|---|
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
fkthat А если попробовать по старинке через DataReader? не умеет ... |
|||
:
Нравится:
Не нравится:
|
|||
|
30.11.2021, 06:17
|
|||
---|---|---|---|
|
|||
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
vb_sub В общем поэкспериментировал я с разными вариантами реализации и пришел к выводу, что оверхед возникает не в момент многократного вызова комманд. А LOB'ы этим запросом вытаскиваются? В гугле дофига и больше вопросов и сообщений по запросу "oracle manageddataaccess memory leak", и практически все в той или иной степени связаны с работой с LOB. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
30.11.2021, 09:48
|
|||
---|---|---|---|
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
ViPRos fkthat А если попробовать по старинке через DataReader? не умеет умеет ... |
|||
:
Нравится:
Не нравится:
|
|||
|
30.11.2021, 09:48
|
|||
---|---|---|---|
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
fkthat, тоже самое ... |
|||
:
Нравится:
Не нравится:
|
|||
|
30.11.2021, 10:13
|
|||
---|---|---|---|
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
Сон Веры Павловны vb_sub В общем поэкспериментировал я с разными вариантами реализации и пришел к выводу, что оверхед возникает не в момент многократного вызова комманд. А LOB'ы этим запросом вытаскиваются? В гугле дофига и больше вопросов и сообщений по запросу "oracle manageddataaccess memory leak", и практически все в той или иной степени связаны с работой с LOB. Думаю вряд ли здесь имеет смысл работать с LOB- ведь по факту за 300 запросов в итоге приходит около 1000 строк с 5 текстовыми полями длиной до 255- то есть никаких супертяжелых объемов данных в ответ не приходит. Сон Веры ПавловныВ гугле дофига и больше вопросов и сообщений по запросу "oracle manageddataaccess memory leak" 99% топиков из-за неверно закрытого using. Единственно релевантный топик по моей проблеме ссыль - но там чел вообще отчаялся и полез GarbageCollector'y объяснять как ему лучше работать. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
01.12.2021, 09:52
|
|||
---|---|---|---|
|
|||
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
vb_sub Единственно релевантный топик по моей проблеме ссыль - но там чел вообще отчаялся и полез GarbageCollector'y объяснять как ему лучше работать. Интересно. Как инстанциируется эта OracleInternal.Common.ZoneValue (структура, хранит в себе массив структур) (весь код ниже - от декомпиляции ILSpy): 1. Метод OracleInternal.Common.OracleTimeZone.GetInstance: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
2. Метод OracleInternal.Common.TimeZoneFileReader.ReadObj: Код: 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.
3. Метод OracleInternal.Common.TimeZoneFileReader.PopulateZoneOffsetMapHashtable: Код: 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.
- и всё, больше никак и нигде. Получается, что OracleInternal.Common.OracleTimeZone.GetInstance на каждый запрос вызывает OracleInternal.Common.TimeZoneFileReader.ReadObj - т.е. где-то как-то статическое поле класса сбрасывается в null. И что интересно - у меня на попечении есть несколько заданий по расписанию для оракла, которые выполняются несколько раз в день, и сами выполняют достаточно много запросов, но никаких утечек памяти в них не обнаруживалось. Эти задания написаны на обычном .Net framework, а в версии ODP.Net код фактически эквивалентен вышеприведенному. То ли в Core как-то по-другому устроен жизненный цикл статик-полей, то ли ещё что. Но, видимо, принудительная сборка мусора здесь действительно единственный выход (до тех пор, пока ораклисты сами не поправят этот баг). ... |
|||
:
Нравится:
Не нравится:
|
|||
|
01.12.2021, 10:34
|
|||
---|---|---|---|
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
Сон Веры ПавловныПочему вряд ли? Дебаг в памяти держит очень много всякого, чего не держит релиз. Я бы проверил и убедился. Релиз проблему не странил. Где можно создать issue с этой проблемой? Разработчик Nuget для Oracle.ManagedDataAccess.Core 3.21.4, или саппорт Oracle? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
02.12.2021, 06:16
|
|||
---|---|---|---|
|
|||
Чрезмерное использование RAM при запросах к базе данных |
|||
#18+
vb_sub Где можно создать issue с этой проблемой? Разработчик Nuget для Oracle.ManagedDataAccess.Core 3.21.4, или саппорт Oracle? https://www.nuget.org/packages/Oracle.ManagedDataAccess.Core/ Справа внизу см. ссылки Owners и Contact owners ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=20&tablet=1&tid=1398199]: |
0ms |
get settings: |
12ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
54ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
364ms |
get tp. blocked users: |
2ms |
others: | 315ms |
total: | 788ms |
0 / 0 |