Добрый день.

Подскажите пожалуйста, зашёл в SAP HANA Studio во вкладку expensive statement trace и увидел огромные значения memory_size (десятки гигабайт), cpu_time и duration для запроса call _SYS_STATISTICS.STATISTICS_SCHEDULABLEWRAPPER('Timer', ?, ?, ?, ?)

Это значит, что в статистик-сервере что-то криво ?
Читаю сап-ноту 2147247 - FAQ: SAP HANA Statistics Server, но пока не понял, что делать с этим запросом.

Читаю другие форумы, там пишут - читать сап-ноту

d6fd6678833f9a2e25e7b53239c50e9a CALL STATISTICS_SCHEDULABLEWRAPPER This procedure is a wrapper for all embedded statistics server actions like history collections and alert checks. This statement hash typically indicates that it is called by the statistics server based on the configured check time intervals. See SAP Note 2147247 ("How can the runtime and CPU requirements of the statistics server actions be analyzed and optimized?") for more information how to analyze and optimize the actions.
dc571bf5eb7cad9c313c20de904ab709 CALL STATISTICS_SCHEDULABLEWRAPPER This procedure is a wrapper for all embedded statistics server actions like history collections and alert checks. This statement hash typically indicates that it is called by SAP Solution Manager in order to extract history and alert information from SAP HANA. See SAP Note 2147247 ("How can the runtime and CPU requirements of the statistics server actions be analyzed and optimized?") for more information how to analyze and optimize the actions.

Все алерты, что генерируются Ханой - это продукт данной процедуры-обертки. Для того, чтобы понять высокое ли потребление памяти, надо понять в динамике, прирастает ли оно перманентно, или стабильно на этом уровне
Приведите статистику по


и те же самые значения из _sys_statistics.host_heap_allocators в агрегации за день, скажем, чтобы посмотреть динамику

Скриншот с продуктива на внешнюю почту переслать не могу, но вывод по вашему запросу показывает что-то типа

indexserver Pool/Statistics exclusive_size_in_use = 34 000 000 000
scriptserver Pool/Statistics exclusive_size_in_use = 80 000 000
остальные меньше.

В динамике всё более-менее постоянно, активного роста нет, но то, что SCHEDULABLEWRAPPER съедает где-то 120Гб из доступных 2Тб - это многовато, не ?

Многовато, конечно.
Но в целом, зависит от количества настроенных алертов - на каждый выделяется по сессии, которую статистик сервис держит открытой до перезагрузки бд.
Чем больше алертов, тем больше открытых сессий и тем выше потребление памяти.
Можете протестить, если есть система под рукой - понасоздавать алертов, посмотреть на потребление памяти, после того, как они отработают хотя б по разу,
затем удалить и посмотреть, релизится ли память
Вы же доп.алерты создавали, насколько понимаю?

Наткнулся на ноту, объясняющую причины высокого потребления Pool/Statistics
Для тех, кому актуально (as per 2532199):
SAP HANA database is using the allocator "Pool/Statistics" to cache statement hashes of prepared statements
To reduce the number of cached statements and hence reduce the heap memory usage of the allocator "Pool/Statistics" you can decrease the ABAP parameter dbs/hdb/stmt_cache_size. This parameter determines the number of the statements held in the client side cache. Its default value is set to 1000.

это актуально для ABAP
если для JAVA, то
2711824 - High Number of Prepared Statements Causing High Usage of Memory Allocator Pool/Statistics
проблема ещё не до конца разрешена. анализируют JAVA traces
локализовано для связки SLD on NW740