Repository navigation
Description
Hello,
I'm currently working with .NET 8.0 and have encountered a peculiar issue related to memory usage across different CPU architectures. Here's the context:
Setup: Two batches of VPS, each running an identical number of ASP.NET Core instances with similar workloads.
CPUs: One batch uses Intel Xeon CPU E5-2630 v4, and the other uses AMD EPYC 7282.
Issue: I've observed a significant difference in memory usage between these two setups. The VPS with AMD EPYC 7282 shows almost full memory utilization right from the start, whereas the Intel Xeon E5-2630 v4 setup uses only about half of the available memory.
This difference is quite striking, and I'm trying to understand what might be causing it. I've attached a screenshot for reference.
Could this be related to how .NET 8.0 interacts with different CPU architectures, or is there another factor I should consider? Any insights or suggestions would be greatly appreciated.
Thank you for your time and assistance.
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 40 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 24
On-line CPU(s) list: 0-23
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
CPU family: 6
Model: 79
Thread(s) per core: 1
Core(s) per socket: 24
Socket(s): 1
Stepping: 1
BogoMIPS: 4399.99
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb r
dtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpu
id tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse
4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c
rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpci
d_single pti ssbd ibrs ibpb stibp fsgsbase tsc_adjust bmi1 hle
avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat
umip md_clear arch_capabilities
Virtualization features:
Hypervisor vendor: KVM
Virtualization type: full
Caches (sum of all):
L1d: 768 KiB (24 instances)
L1i: 768 KiB (24 instances)
L2: 96 MiB (24 instances)
L3: 16 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-23
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: KVM: Mitigation: VMX unsupported
L1tf: Mitigation; PTE Inversion
Mds: Mitigation; Clear CPU buffers; SMT Host state unknown
Meltdown: Mitigation; PTI
Mmio stale data: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Hos
t state unknown
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and se
ccomp
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer saniti
zation
Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP disab
led, RSB filling, PBRSB-eIBRS Not affected
Srbds: Not affected
Tsx async abort: Mitigation; Clear CPU buffers; SMT Host state unknown
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 24
On-line CPU(s) list: 0-23
Vendor ID: AuthenticAMD
Model name: AMD EPYC 7282 16-Core Processor
CPU family: 23
Model: 49
Thread(s) per core: 1
Core(s) per socket: 24
Socket(s): 1
Stepping: 0
BogoMIPS: 5589.50
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_
opt pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_know
n_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe
popcnt tsc_deadline_timer aes xsave avx f16c rdrand hyperviso
r lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowpre
fetch osvw perfctr_core ssbd ibrs ibpb stibp vmmcall fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb
sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr wbnoinvd ara
t umip rdpid arch_capabilities
Virtualization features:
Hypervisor vendor: KVM
Virtualization type: full
Caches (sum of all):
L1d: 1.5 MiB (24 instances)
L1i: 1.5 MiB (24 instances)
L2: 12 MiB (24 instances)
L3: 384 MiB (24 instances)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-23
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Mitigation; untrained return thunk; SMT disabled
Spec rstack overflow: Mitigation; SMT disabled
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and se
ccomp
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer saniti
zation
Spectre v2: Mitigation; Retpolines, IBPB conditional, STIBP disabled, RSB
filling, PBRSB-eIBRS Not affected
Srbds: Not affected
Tsx async abort: Not affected
Intel(R) Xeon(R) CPU E5-2630 v4:

System Info:
Icon name: computer-vm
Chassis: vm
Machine ID: 502a92bb04b95032ffb20fa665850b69
Boot ID: 89f838f101f2406a9ebbf2f16888b6da
Virtualization: kvm
Operating System: Ubuntu 22.04.3 LTS
Kernel: Linux 5.15.0-91-generic
Architecture: x86-64
Hardware Vendor: QEMU
Hardware Model: Standard PC i440FX + PIIX, 1996

Activity
adityamandaleeka commentedon Jan 18, 2024
Are you using server GC? Server GC will use one heap per core, and it looks like your Xeon has 10 cores while the EPYC has 16 (and both with SMT 2). I'm not exactly sure how that's surfaced in your QEMU setup, but that could explain the difference.
In any case, I'll transfer this over to the runtime repo since this is most likely not related to ASP.NET Core itself.
adityamandaleeka commentedon Jan 18, 2024
@mangod9
mrsharm commentedon Apr 3, 2024
This issue might also be likely candidate to be susceptible to the same issue as: #100502.
@linqingfeng, can you please run the following command on your linux machine
getconf -a | grep LEVEL4_CACHEand let us know the output.Thank you!
mangod9 commentedon Jul 3, 2024
Closing for now assuming this is a dupe of #100502. @linqingfeng please reopen if this still repros on latest .NET 8 servicing release.