Video summary

How many Tabs with 1.5 TB of RAM?

Main summary

Key takeaways

Technology

Summary of Technological Concepts / Product Features / Analysis

Problem Being Tested

  • How many Google Chrome tabs a very high-memory server can handle before the system becomes unusable or crashes.

Hardware Platform

  • A “non-mortal” system built with:
    • Two AMD EPYC 9684X CPUs
      • 96 Zen 4 cores each
      • 192 total cores
    • Extremely large memory capacity:
      • ~1.5 TB DDR5 5600 MT/s memory (about 1.5 terabytes)

How This Build Differs From a Prior Run

  • The earlier attempt (implied to be ~6 years ago) was likely constrained by software, not raw RAM.
  • This time:
    • Windows 11 is used
    • A Linux run is also included

Operating Systems and Automation Tooling

Windows 11 Run

  • Chrome is stress-tested using a Python script that automates opening tabs.
    • This reduces manual tedium during large-scale testing.

Linux Run

  • Uses similar tab automation with Linux-specific setup:
    • Increases the open files limit to 65,535.

Script Behavior

  • Opens tabs in bulk.
  • Uses resource monitoring while staying lightweight:
    • It queries system resources rather than performing deep browser introspection.
  • Recommended operational mode:
    • Run Chrome in incognito mode to reduce overhead and side effects.

Memory / CPU / Platform Architecture Details (Why 1.5 TB Is Feasible)

Memory Type and Capacity Path

  • Earlier builds needed specialized LRDIMMs to reach extreme capacity.
  • This time:
    • EPYC memory controllers support 128GB RDIMMs, enabling large capacity without the same level of memory-module constraint (though at huge cost).

DDR5 R-DIMM / Channel Design Notes

  • Splits ECC channel width compared to older designs (a sub-channel structure).
  • DIMMs include:
    • Integrated power management
    • Equalization/filtering to reduce noise at high capacity

Memory Training Delays

  • The server spends significant time on memory training.
  • Training time scales with RAM size.

Observed Hardware Reality Check

  • Initially only 10 memory sticks were visible.
  • After remounting CPUs / fixing memory channels, the system correctly revealed the full ~1.5 TB.

Key Bottlenecks Discovered During Tab Scaling

RAM Is Not the Only Limiting Factor

  • Chrome tab scaling is not purely RAM-limited.
  • Heavy sites and video playback introduce additional bottlenecks, such as:
    • GPU / VRAM exhaustion
    • Cloud/security gating (e.g., Cloudflare blocking)

GPU Matters More Than Expected

  • In video-heavy tabs:
    • The GPU ran out of VRAM
    • The system became unresponsive
      • Example symptoms include:
        • mouse/taskbar issues
        • pages failing to load

Browser Heaviness Increases Over Time

  • Even with CPU/RAM headroom:
    • Websites continue to grow in complexity
    • The browser must manage more rendering, network activity, and session state

Windows vs Linux Behavior (What Differed)

Windows

  • Pretty well early on, but later:
    • Chrome and/or Windows became unresponsive under extreme loads.
  • After large-scale opening:
    • The run could degrade due to both:
      • system-level limits
      • service-level constraints

Linux

  • Initially looked more linear/smoother in memory usage patterns.
  • Monitoring differences:
    • Linux exposes metrics via procfs (noted as “everything is a file”)
    • Windows leans more on system APIs / WMI-style querying
  • Ultimately still hit a Chrome crash at extreme tab counts.
  • Disappointment noted: it didn’t surpass the previous record.

Tech Tip: ZRAM

ZRAM (Linux RAM compression) could help systems with less memory by compressing RAM contents instead of paging to slower storage.

  • Configurable on Linux and not enabled by default on Ubuntu.

Representative Test Outcomes (High-Level)

Early Progression

  • Successful runs up to:
    • ~500 tabs in one window (including heavy video)
    • then scaling to ~1,000 total tabs across two windows
      • with manageable system memory
      • and relatively low CPU at the time

Where It Started Failing

  • As batch sizes increased:
    • GPU VRAM exhaustion occurred in video-heavy scenarios
    • Cloudflare and similar gating prevented some sites from loading

Extreme Scale Attempts

  • At the very high end:
    • Chrome eventually hard-crashed on both OSes
  • They compare results to a prior “best record” run:
    • the new attempt fell short
    • due to crashes and/or instability
  • One observation:
    • after a Chrome crash, metrics became unreliable
    • due to a memory accounting discrepancy

Key “Tutorial / Guide / Tech Tips” Extracted

  • Use a Python-driven tab opener to benchmark browser scalability.
    • Incognito mode is recommended.
  • When pushing Chrome to extremes, expect GPU VRAM to become the first major limiter—especially with video playback—before system RAM does.
  • Linux monitoring differs from Windows:
    • Linux: procfs/file-like interfaces
    • Windows: system APIs / WMI
  • If memory-constrained on Linux, consider ZRAM for in-RAM compression.
  • Increase Linux open file limits to avoid resource limit issues during heavy tab counts.

Main Speakers / Sources

  • Linus (Linus Tech Tips / Linus S.)
  • Michael (mentioned as writing the Chrome tab test Python script)
  • Sponsor: War Thunder

Original video