Текущее время: Чт, мар 28 2024, 17:03

Часовой пояс: UTC + 3 часа


Правила форума


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 16 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Оптимизация использования памяти
СообщениеДобавлено: Ср, окт 06 2021, 11:25 
Младший специалист
Младший специалист
Аватара пользователя

Зарегистрирован:
Чт, сен 01 2005, 15:54
Сообщения: 95
Коллеги, доброго дня!

Используем SAP BW 7.4 с огромным количеством одновременных загрузок/расчётов. Много где используются огромные таблицы с какими-то нужными дополнительными данными. Например, договора и контрагенты. Происходит следующее: запускается несколько расчётов по нескольким БЕ одновременно, и каждый из них выполняется отдельно по каждому месяцу. И везде нужны, скажем, договора. Таблица большая, и периодически её чтение из таблицы БД заканчивается дампом по нехватке памяти.
При этом сама таблица договоров внутри абапа никак не изменяется.

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

Подскажите, есть ли подобная возможность? Может, пример кода?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Ср, окт 06 2021, 18:04 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, дек 20 2007, 18:21
Сообщения: 1613
Вариантов много. Самый простой - пакетная обработка в селекте. Изобретать что-то с распределенной памятью - как стрелять из плазмогана по воробьям.

_________________
я твой сап эфай внедрял
BAdI-позитив
Взять немножечко абопу, сунь туда кошачью *опу, RFC лапки, БТ старой бабки, на медленном базиснике переносить, тестовое окружение материть, снимать SAT пенку, биться головой о стенку, охапка тайм-шитов, отчет готов!


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Чт, окт 07 2021, 23:52 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3074
Откуда: Москва
ST написал(а):
Коллеги, доброго дня!

Используем SAP BW 7.4 с огромным количеством одновременных загрузок/расчётов. Много где используются огромные таблицы с какими-то нужными дополнительными данными. Например, договора и контрагенты. Происходит следующее: запускается несколько расчётов по нескольким БЕ одновременно, и каждый из них выполняется отдельно по каждому месяцу. И везде нужны, скажем, договора. Таблица большая, и периодически её чтение из таблицы БД заканчивается дампом по нехватке памяти.
При этом сама таблица договоров внутри абапа никак не изменяется.

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

Подскажите, есть ли подобная возможность? Может, пример кода?

Проблемы с памятью определяются через SAT.
У нас подобные проблемы с нехваткой памяти для процесса решались с помощью освобождения памяти временных внутренних таблиц. Кроме REFRESH нужно было делать FREE.
И да - нехватка памяти для процесса, или глобальной памяти?
Опять же - зачем для таблиц договоров и контрагентов читать все поля? :roll:

_________________
С уважением,
Удав.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Пн, окт 11 2021, 11:16 
Директор
Директор

Зарегистрирован:
Вт, ноя 09 2010, 19:59
Сообщения: 792
Откуда: Novosibirsk
Пол: Мужской
подобное для большинства компаний скорее всего только после 2030 года?
Внутренние таблицы как источник в SQL запросах
Code:
Существует два сценария выполнения таких запросов:
    Для выполнения SQL запроса не требуется переноса содержимого внутренней таблицы на уровень СУБД. В таком случае обработка запроса осуществляется непосредственно на сервере приложений, по аналогии с табличным буфером.
    Для выполнения SQL запроса требуется перенести содержимое внутренней таблицы во временную таблицу на уровень СУБД. Этот сценарий поддерживается не всеми СУБД и чтобы статический анализ кода не ругался, следует использовать прагму: ##itab_db_select. При отсутствии поддержки система выдаст исключение в runtime — CX_SY_SQL_UNSUPPORTED_FEATURE.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Ср, окт 13 2021, 14:34 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
Не нужно читать таблицы по отдельности. Пишите сложные выборки с join и packed size. Open cursor with hold поможет сохранять данные порциями. В идеале из БД вы должны получать только необходимые данные, ничего лишнего. Если у вас много селектов с for all entries, это верный признак, что делаете что-то не так.
Разумеется, в борьбе за память потеряете в производительности - по другому и быть не должно.

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Пн, ноя 29 2021, 13:42 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, мар 29 2007, 11:51
Сообщения: 330
Откуда: Yugorsk.RU
Пол: Мужской
Parazit написал:
Не нужно читать таблицы по отдельности. Пишите сложные выборки с join и packed size. Open cursor with hold поможет сохранять данные порциями. В идеале из БД вы должны получать только необходимые данные, ничего лишнего. Если у вас много селектов с for all entries, это верный признак, что делаете что-то не так.

Хм. А разве это не путь обратно в двухзвенку? Нагружая СУБД сложными джойнами (с километровыми планами выполнения) мы разве не садим общую производительность системы, ценой ускорения работы одного конкретного пользователя данного отчёта/транзакции?
Почемуто думал, что архаичная декомпозиция джойнов на отдельные операции с таблицами через сервер приложения и последующие абап-циклы "джойнов", это какраз то, чем исторически сильна сап-коробка. :?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Пн, ноя 29 2021, 13:48 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 13:35
Сообщения: 4842
Откуда: Москва
Пол: Мужской
pberezin написал:
Хм. А разве это не путь обратно в двухзвенку? Нагружая СУБД сложными джойнами (с километровыми планами выполнения) мы разве не садим общую производительность системы, ценой ускорения работы одного конкретного пользователя данного отчёта/транзакции?
Почемуто думал, что архаичная декомпозиция джойнов на отдельные операции с таблицами через сервер приложения и последующие абап-циклы "джойнов", это какраз то, чем исторически сильна сап-коробка. :?

Ну да. Несколько десятилетий существования продуктов R/3 и ERP, SAP объяснял какие они молодцы, что при помощи абапа позволяют снять нагрузку с единой точки отказа (БД) за счет горизонтально масштабируемых серверов приложений. Потом с появлением HANA маятник качнулся и SAP стал объяснять какие они молодцы, что позволяют убрать лишний код из серверов приложений, перенести его в БД и тем самым уменьшить объем сетевого трафика.

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Вт, ноя 30 2021, 14:14 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, мар 29 2007, 11:51
Сообщения: 330
Откуда: Yugorsk.RU
Пол: Мужской
LKU написал:
Потом с появлением HANA маятник качнулся и SAP стал объяснять какие они молодцы, что позволяют убрать лишний код из серверов приложений, перенести его в БД и тем самым уменьшить объем сетевого трафика.


Видимо шустрые ssd-диски подешевели, что теперь нет смысла экономить на ИО-Костах, БД на шустром железе и так прожуёт. Логично такто, но както не по саповски :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Вт, ноя 30 2021, 23:12 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, май 12 2011, 16:06
Сообщения: 347
Только не совсем понятно, что имеется в виду под «перенести логику в БД». Если использовать возможности обновлённого SQL – то да: он стал мощнее (например, если раньше нужно было делать несколько выборок, а потом сочетать таблицы на AS, то теперь можно всё сделать одним селектом), да и HANA тянет ранее тяжёлые селекты «на ура». Если переносить всё в CDS, то особого роста производительности не заметно (обычно даже наоборот), для сдс, включённых в segw (через reference) всё равно всё приходит на AS в CL_SADL_SQL_EXECUTOR==========CM00A (с довольно странным селектом, имхо). А вот отладка и сопровождение – со слезами на глазах.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Ср, дек 01 2021, 10:30 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:38
Сообщения: 1246
LAT написал(а):
Если переносить всё в CDS, то особого роста производительности не заметно (обычно даже наоборот), для сдс, включённых в segw (через reference) всё равно всё приходит на AS в CL_SADL_SQL_EXECUTOR==========CM00A (с довольно странным селектом, имхо). А вот отладка и сопровождение – со слезами на глазах.


Странное утверждение. Проверил в 2ух системах (7.5 и 7.52) ни в одной нет такого класса

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Ср, дек 01 2021, 11:53 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, май 12 2011, 16:06
Сообщения: 347
Нет класса CL_SADL_SQL_EXECUTOR?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Чт, дек 02 2021, 10:20 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:38
Сообщения: 1246
Ага

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Вс, дек 05 2021, 20:48 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
pberezin написал:
Parazit написал:
Не нужно читать таблицы по отдельности. Пишите сложные выборки с join и packed size. Open cursor with hold поможет сохранять данные порциями. В идеале из БД вы должны получать только необходимые данные, ничего лишнего. Если у вас много селектов с for all entries, это верный признак, что делаете что-то не так.

Хм. А разве это не путь обратно в двухзвенку? Нагружая СУБД сложными джойнами (с километровыми планами выполнения) мы разве не садим общую производительность системы, ценой ускорения работы одного конкретного пользователя данного отчёта/транзакции?
Почемуто думал, что архаичная декомпозиция джойнов на отдельные операции с таблицами через сервер приложения и последующие абап-циклы "джойнов", это какраз то, чем исторически сильна сап-коробка. :?

Во-первых, самой темой задано снижение нагрузки с сервера приложений.
Во-вторых, за трёхзвенку не беспокойтесь, сервер приложений без работы не останется. Сами же знаете, что задачи обычно сложнее простой выборки и отображения простого отчёта. Иначе было бы достаточно Report Painter, а нас разогнать. :)
В-третьих, разумеется SQL-запросы должны писаться максимально грамотно - оптимизация, ключи, индексы и т.д. Но начинать надо с грамотного проектирования БД, что, к сожалению, не всегда осуществимо. Т.н. "декомпозиция джойнов" не сильная сторона, а вынужденная мера, например, для связки таблиц пула (а ля BSEG) или нестыкуемых полей связи (ошибки проектирования БД). В целом же такой подход всегда работает хуже - медленнее и больше нагружает все узлы системы (СУБД, шины данных, каналы связи, серверы приложений). Во всяком случае за свою практику исключений не встречал, и даже споры выигрывал. :)

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Ср, янв 19 2022, 16:08 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, мар 29 2007, 11:51
Сообщения: 330
Откуда: Yugorsk.RU
Пол: Мужской
Parazit написал:
Т.н. "декомпозиция джойнов" не сильная сторона, а вынужденная мера, например, для связки таблиц пула (а ля BSEG) или нестыкуемых полей связи (ошибки проектирования БД). В целом же такой подход всегда работает хуже - медленнее и больше нагружает все узлы системы (СУБД, шины данных, каналы связи, серверы приложений).
Во всяком случае за свою практику исключений не встречал, и даже споры выигрывал. :)


Полагал, что эта вынужденная мера позволяла сап-коробке не одно десятилетие сознательно замедлять и нагружать работу единичного пользователя (и евоного отчёта ... ну и абапера, кто это всё декомпозирует и отлаживает :) ),
но за счёт возможности давать толктись на ноде тысячам такихже активных пользователей. Чтобы они все дружно колом не вставали на блокировках СУБД, если 50ти тяжёлые коммиты "вот ща последнюю фактуру допровожу", а у остальных 100 экземпляров годовой отчётности уже запущены "вот прям щас надо" :)

А щас получается обратно в дремучее двухзвенное прошлое.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация использования памяти
СообщениеДобавлено: Пт, янв 28 2022, 16:15 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, дек 20 2007, 18:21
Сообщения: 1613
У транзакционной ханы очень низкая нагрузка по CPU обычно. Вот и решили догрузить ее немного...

_________________
я твой сап эфай внедрял
BAdI-позитив
Взять немножечко абопу, сунь туда кошачью *опу, RFC лапки, БТ старой бабки, на медленном базиснике переносить, тестовое окружение материть, снимать SAT пенку, биться головой о стенку, охапка тайм-шитов, отчет готов!


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 16 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: Google [Bot], Yandex [Bot]


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB