Updating `google-cloud-sdk` repo using `dnf` consumes around 1GB of RSS memory, which could lead to OOM events.
### Reproduction ### On a `n2-standard-4` test VM with `rocky-linux-8-optimized-gcp-v20250212` boot image:
1. Install the `time` tool to measure the maximum memory consumption.
2. Cleared the google-cloud-sdk repo: ``` $ dnf clean all --repo google-cloud-sdk 47 files removed ``` 3. Ran `dnf makecache` : ``` $ uname -r 4.18.0-553.16.1.el8_10.cloud.0.1.x86_64 $ /usr/bin/time -v dnf makecache Rocky Linux 8 - Cloud Kernel 4.3 MB/s | 1.0 MB 00:00 Rocky Linux 8 - AppStream 45 MB/s | 16 MB 00:00 Rocky Linux 8 - BaseOS 66 MB/s | 16 MB 00:00 Rocky Linux 8 - Extras 138 kB/s | 15 kB 00:00 Google Compute Engine 25 kB/s | 8.8 kB 00:00 Google Cloud SDK 47 MB/s | 137 MB 00:02 Google Cloud Ops Agent Repository 140 kB/s | 34 kB 00:00 Metadata cache created. Command being timed: "dnf makecache" User time (seconds): 44.54 System time (seconds): 1.18 Percent of CPU this job got: 93% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:48.97 Maximum resident set size (kbytes): 1104856 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 157212 Swaps: 0 Page size (bytes): 4096 ```
`Maximum resident set size (kbytes): 1104856` indicates that the process consumed approximately 1GB of RSS memory.
### Impact ### In some customer cases, we observed that the oom-killer event was triggered, leading to process termination or, in extreme cases, a kernel panic causing the VM to reboot. The likelihood of this issue increases, especially on machines with low memory.
### Request ###
Is there any possibility of optimizing or reducing the memory consumption of the `google-cloud-sdk` repo when running `dnf` related commands, such as `dnf makecache`?
Description
Updating `google-cloud-sdk` repo using `dnf` consumes around 1GB of RSS memory, which could lead to OOM events.
### Reproduction ###
On a `n2-standard-4` test VM with `rocky-linux-8-optimized-gcp-v20250212` boot image:
1. Install the `time` tool to measure the maximum memory consumption.
2. Cleared the google-cloud-sdk repo:
```
$ dnf clean all --repo google-cloud-sdk
47 files removed
```
3. Ran `dnf makecache` :
```
$ uname -r
4.18.0-553.16.1.el8_10.cloud.0.1.x86_64
$ /usr/bin/time -v dnf makecache
Rocky Linux 8 - Cloud Kernel 4.3 MB/s | 1.0 MB 00:00
Rocky Linux 8 - AppStream 45 MB/s | 16 MB 00:00
Rocky Linux 8 - BaseOS 66 MB/s | 16 MB 00:00
Rocky Linux 8 - Extras 138 kB/s | 15 kB 00:00
Google Compute Engine 25 kB/s | 8.8 kB 00:00
Google Cloud SDK 47 MB/s | 137 MB 00:02
Google Cloud Ops Agent Repository 140 kB/s | 34 kB 00:00
Metadata cache created.
Command being timed: "dnf makecache"
User time (seconds): 44.54
System time (seconds): 1.18
Percent of CPU this job got: 93%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:48.97
Maximum resident set size (kbytes): 1104856
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 157212
Swaps: 0
Page size (bytes): 4096
```
`Maximum resident set size (kbytes): 1104856` indicates that the process consumed approximately 1GB of RSS memory.
### Impact ###
In some customer cases, we observed that the oom-killer event was triggered, leading to process termination or, in extreme cases, a kernel panic causing the VM to reboot. The likelihood of this issue increases, especially on machines with low memory.
### Request ###
Is there any possibility of optimizing or reducing the memory consumption of the `google-cloud-sdk` repo when running `dnf` related commands, such as `dnf makecache`?