Forum Discussion
Lakehouse high CU usage, unknown source
Support finally got back to me with this reply. They admitted to it being a backend Microsoft issue, but no word on how and if they would be fixing it or if I would be reinbursed the lost CU's. The abbreviated 'DMS' is for Data Movement Services:
The increased CU usage was attributed to a disabled file system (FS) on the DMS side, which resulted in a significant number of “GetBlobProperties” API calls from DMS to the One Lake Client (OLC). This led to the observed spike in CU usage. After the FS was re-enabled on July 29th, CU usage decreased accordingly.
The spike occurred on 07/18 and subsided on 07/29, aligning with the period when the FS was disabled and subsequently re-enabled on the DMS side, which reduced the number of calls from DMS to OLC.
To take it one step further, Iterative Read via Proxy is 4798 Cu's per 10000 vs the 104 per 10000 for Other Operations via Redirect (see below).
Yet take one day example of ours, where we have 1.4 million operations of Iterative Read via Proxy vs. 692K Other Operations via Redirect so about half. Yet the total CU's is 607 thousand vs 4.2 million
If I do the math, 692 326 operations / 10 000 * 104 = 7200 CUs. Not sure where they are getting 4 217 837 from ? That would mean we are being charged 692 326 / 10000 * x = 4 217 837 ....therefore x = 60 918 CUs per 10000???