Do Have a look at the following note:
590370 Too many uncompressed request (f table partitions)
That will explain why some processes on partitioned objects take longer the more partitions the system has.
And then execute SE38 report RSORAVDV variant. This will show you all table that have too many partitions. If these are F tables, you need
to massively compress the cubes to less than 30 partitions. And you must do so regularly, because this is very important.
Usually Summarization factor of 10 or more is taken as fine.
Also Transaction RSA1 -> Cube -> Manage -> Performance , Check Aggregate Indexes
To check the InfoCube index consistency on other cubes, call transaction RSRV -> 'All Elementary Tests' -> 'Database'.Double-click "Database
Indices of an InfoCube and Its Aggregates" and enter the corresponding InfoCube.To correct the problems, choose "Correct Error" and then "YES"
in the popup. If this does not solve the problem, check SAP Note 401242 and consider scheduling report SAP_INFOCUBE_INDEXES_REPAIR.
4) To reduce the runtime of the change run, you can distribute adjustment of the aggregates across several work processes running in
parallel. Refer to SAP Note 534630.
5) Finally (critical setting for performance):
Check in RSCUSTV8 transaction the current Delta limit and Block size set.
If there is no delta make it to 20% and please have a look at the detailed information mentioned there in help for these settings.
Have a look at note:
903886 - Hierarchy and attribute change run