How many Tabs with 1.5 TB of RAM? Windows VS. Linux

[00:00:00]Somewhere in a lab right now sits a computer with one and a half terabytes of memory, more RAM than most people will ever see in an entire career of upgrading personal computers. And the only question anyone actually wants answered is embarrassingly simple. How many browser tabs can it open before the whole thing falls over? That is genuinely the test. And it just got run again. This time with a brand new twist that changes the entire shape of the experiment. Instead of just maxing out one operating system and calling it a day, the test runs the exact same brutal punishment on both Windows and Linux back to back on the exact same absurd hardware. And the results tell you something far more interesting than just a big number on a screen. Let's start with the machine itself because before you even open a single tab, this hardware alone is worth understanding.

[00:00:44]And it genuinely helps to picture exactly what kind of machine we are talking about before diving into any of the software side of this comparison. At the heart of the build sit two AMD EPYC 9684X processors, server grade chips built specifically for the kind of workloads that make ordinary consumer computers look like calculators by comparison. Each of those chips alone packs 96 cores, meaning the full dual socket system offers a combined 192 physical cores and with simultaneous multi-threading enabled roughly 384 logical threads for the operating system to juggle work across. Layer on top of that a genuinely staggering one and a half terabytes of DDR5 memory and you're looking at a machine built less like a gaming PCI and more like the kind of server that would normally be tucked away in a data center running database queries or scientific simulations for a Fortune 500 company, not opening browser tabs for a YouTube video. So why build something this extreme just to open Chrome tabs? The honest answer is that this exact experiment has a history, and it is worth understanding where it came from before diving into what makes this new version so interesting. Tech reviewers have been chasing the specific question for years now, using progressively more absurd hardware to push browsers past every reasonable limit anyone could imagine. One of the most famous versions of this test happened back when a prominent Apple focused reviewer took a Mac Pro loaded with roughly the same one and a half terabytes of system memory and set out to see exactly how many Chrome tabs it could handle before something broke.

[00:02:11]That test ended with the machine cracking open around 6,000 tabs, consuming nearly the entire memory pool in the process before one of Chrome's background processes finally seized up and dragged the whole browser down with it when it was force closed. That earlier test set a kind of informal benchmark that has been quietly nagging at tech content creators ever since because it left an obvious follow-up question hanging in the air. What happens if you run the exact same brutal stress test, but instead of comparing different hardware, you compare different operating systems running on the exact same hardware. That is precisely the gap this newest experiment sets out to fill. taking that same one and a half terbyte memory ceiling and running the identical automated tab flooding process on both Windows 11 and a Linux distribution on the exact same dual EPYC monster machine to see which operating system actually manages memory processes and chaos more gracefully when pushed to a genuinely absurd extreme.

[00:03:05]Before getting into the operating system comparison itself, it helps to understand exactly why opening browser tabs turns into such a punishing stress test in the first place. because the mechanics behind it are more interesting than most people realize. Modern Chrome, unlike many older browsers, does not treat tabs as simple, lightweight documents sitting passively inside one shared program. Each tab in Chrome typically spins up as its own separate operating system process complete with its own chunk of allocated memory, its own security sandbox, and its own independent connection to the browser's rendering and JavaScript engines. That architecture exists for genuinely good reasons. If one tab crashes because of a broken website or a memory leak, isolating it inside its own process means the rest of your browser keeps running normally instead of taking the whole application down with it. The trade-off for that stability, though, is memory overhead. Every single tab carries its own baseline cost just to exist before it has even loaded a single image or run a single line of website code. And that overhead multiplies relentlessly as the tab count climbs into the thousands. This is exactly why simply having a huge pool of RAM available does not automatically translate into an equally huge number of tabs you can actually open. Memory is only one piece of a much larger puzzle.

[00:04:18]As tab counts climb into the thousands, the operating system itself has to juggle an enormous number of simultaneous processes. Each one competing for CPU scheduling time. Each one making its own network requests.

[00:04:29]Each one holding its own file handles and system resources open at the same time. Long before you ever technically run out of raw memory capacity, other [snorts] bottlenecks tend to show up first. Exactly the kind of thing the earlier Mac Pro test hinted at when Chrome itself started struggling well before the full memory pool was exhausted. This is where the Windows versus Linux comparison becomes genuinely fascinating from a technical standpoint rather than just being a fun stunt for a video thumbnail. The two operating systems handle memory management, process scheduling, and resource allocation using fundamentally different underlying architectures shaped by decades of very different design philosophies. Windows as a commercial operating system built primarily around broad hardware compatibility and a polished desktop experience for hundreds of millions of ordinary users makes certain trade-offs in how aggressively it manages memory caching, how it schedules processes across dozens or hundreds of CPU cores, and how it handles a system running under this kind of extreme sustained load. Linux, particularly in server oriented configurations, has been refined for decades, specifically around exactly this kind of workload with a kernel that gives administrators granular control over memory allocation, process scheduling, and resource limits that Windows simply does not expose in the same way. One of the most important differences between the two systems shows up in something called the out of memory killer, a Linux kernel mechanism specifically designed to handle exactly the kind of scenario this test creates.

[00:05:56]When a Linux system genuinely starts running out of available memory rather than allowing the entire system to grind to a complete unresponsive halt, the colonel's out of memory killer steps in and deliberately terminates specific processes, usually targeting whichever process is consuming the most memory in order to free up resources and keep the rest of the system functional. Windows historically has not had a direct equivalent to this mechanism, working in quite the same automated aggressive way, which means a Windows system pushed toward its absolute memory ceiling can sometimes behave very differently under extreme pressure, potentially becoming sluggish and unresponsive across the board rather than surgically killing off the single worst offending process the way Linux tends to. There's also a deeper architectural difference worth understanding involving something called non-uniform memory access or NUMA for short, which becomes especially relevant on a dual socket system exactly like the one used in this test. When you have two separate physical processors, each with its own directly attached bank of memory, the system as a whole has to make constant decisions about which processor accesses which portion of that 1 and a half terbyte memory pool.

[00:07:02]Accessing memory that is physically attached to your own processor happens faster than reaching across to memory attached to the other processor. And how gracefully an operating system handles that distinction called numa awareness can meaningfully affect performance once a workload scales up to genuinely enormous levels. Linux has historically offered administrators more direct granular control over Numa behavior or through kernel level tools and configuration options while Windows tends to handle NUMA balancing more automatically behind the scenes with less direct manual control exposed to the end user on a test specifically designed to push memory allocation to its absolute breaking point across 192 physical cores. That architectural difference is not just a trivia detail.

[00:07:45]It is potentially one of the single biggest factors separating how each operating system actually performs under this exact kind of load. It is worth pausing here to explain exactly how a test like this actually gets executed in practice because opening thousands of tabs one by one by hand would obviously be impossible. Tests of this scale rely on automation, typically using scripts that programmatically instruct the browser to open a fresh tab, navigate it to a specific web page, wait for that page to finish loading, and then immediately repeat the entire process again over and over for as many iterations as the test requires. This automated approach ensures a consistent, repeatable methodology, letting testers compare results across different operating systems or different hardware configurations without introducing the kind of human error or inconsistency that manually clicking through thousands of browser tabs would inevitably create.

[00:08:35]It also means the test can track exactly how memory consumption, CPU load, and overall system responsiveness change in real time as the tab count steadily climbs rather than only capturing a single snapshot at the very end.

[00:08:46]Something else worth understanding is exactly what these thousands of tabs are actually displaying while all of this is happening because that detail meaning floats. Light changes how demanding the test really is. Opening thousands of completely blank tabs would be a fairly trivial test since a blank tab consumes only a tiny fraction of the memory that a fully loaded mediarich web page requires. A genuinely meaningful stress test needs those tabs loading real complex websites, pages packed with images, embedded videos, JavaScript heavy interactive elements, and all the modern web. Technology that makes a typical web page today dramatically heavier than pages were even just five or six years ago. That distinction is precisely why earlier versions of this experiment specifically emphasized using real functioning web pages rather than simple placeholder content. Since the entire point of the exercise is measuring how the system behaves under conditions that actually resemble genuine if extreme real world browsing behavior. Let's talk about what actually tends to break first in tests like this.

[00:09:45]Because it is rarely the memory itself that gives out and understanding why reveals something important about how modern computing systems actually behave under extreme stress. In the earlier Mac Pro version of this test, the machine technically still had memory headroom remaining even as Chrome itself began to visibly struggle with individual browser processes becoming unresponsive well before the full memory pool was exhausted. That pattern tends to repeat itself across most versions of this experiment regardless of which specific hardware or operating system gets tested. Browsers themselves, not the underlying operating system, frequently become the actual bottleneck as the sheer number of connections and background tasks eventually overwhelms the browser's own internal architecture long before the eye. Operating systems memory management genuinely runs out of resources to allocate. If you enjoy watching engineers push absurd hardware past every reasonable limit just to see what actually breaks first, go ahead and hit that like button right now. It genuinely helps this channel reach more people who love this kind of deep technical chaos as much as you clearly do. Let's dig a little deeper into why this particular test run identically across two different operating systems matters for reasons that go well beyond simple entertainment value. Server administrators, cloud infrastructure engineers, and anyone responsible for running memory intensive workloads at genuine scale deal with exactly these kinds of underlying operating system differences every single day, just usually with far less entertaining framing than a browser tab stress test.

[00:11:10]Choosing between Windows Server and a Linux distribution for a memoryheavy production workload is a genuinely consequential decision that companies make constantly. And tests like this one, however playful in presentation, actually surface real, measurable differences in how each operating system behaves once you push memory allocation and process scheduling to genuinely extreme levels. A browser opening thousands of tabs is in a sense just a fun visually intuitive standin for the exact same underlying stress that a database server or scientific computing cluster might experience when handling an enormous sudden spike in simultaneous workload demand. There is also a genuinely interesting economic angle buried inside this story worth understanding for anyone curious about why hardware like this exists at all outside of pure stress test entertainment. Dual socket EPYC systems with this kind of processor count and memory capacity are not niche curiosities built purely for content creation. They represent real commercially available server configurations that companies purchase and deploy for exactly the kind of memory intensive highly parallel workloads that modern businesses increasingly depend on. Things like in memory databases, large-scale virtualization platforms hosting hundreds of separate virtual machines simultaneously and increasingly infrastructure supporting artificial intelligence and machine learning workloads that demand enormous fast access memory pools. A system configuration costing tens of thousands of dollars, which is roughly the territory this kind of dual EPYC terabyte plus memory build occupies, sits well outside consumer territory entirely, existing specifically to serve exactly this category of demanding enterprise workload. It is also worth spending a moment on AMD's EPYC processor line specifically since the choice of this particular chip is not arbitrary. The EPYC9684X belongs to AMD's line of processors specifically built around what the company calls three-dimensional vc technology, a manufacturing approach that stacks additional cache memory directly on top of the processor die itself dramatically, increasing the amount of extremely fast low latency cache memory available to the chip compared to more conventional processor designs. That massive cache pool matters enormously for exactly the kind of workload this test creates. Since a system juggling thousands of simultaneous browser processes benefits enormously from being able to keep frequently accessed data sitting in ultraast cache memory rather than constantly reaching all the way out to the comparatively slower main memory pool for every single operation. In many ways, this specific processor choice was almost certainly deliberate, selected precisely because its architecture is unusually well suited to exactly the kind of massively parallel cache sensitive workload that opening thousands of simultaneous browser tabs actually creates. Think about the sheer scale of coordination required to even attempt a test like this successfully because it is easy to breeze past just how much genuinely has to work correctly simultaneously. You need an operating system capable of tracking and scheduling potentially thousands of separate processes without the underlying task management system itself collapsing under its own administrative overhead. You need network infrastructure capable of handling thousands of simultaneous outbound web requests without hitting router or firewall level connection limits that have nothing to do with the computer's own hardware at all. You need storage fast enough to handle the constant disk activity that browsers generate even when primarily operating in memory.

[00:14:33]Since browsers routinely write cache files, session data, and various logs to disk, even during ordinary operation, any one of these secondary systems becoming a bottleneck could artificially cap the tests results long before the actual 1 and a half terabytes of memory ever gets close to being fully utilized.

[00:14:51]Which is exactly why these tests tend to reveal so much more about overall system architecture than any single specification number ever could on its own. There is a specific technical limit worth explaining in more detail because it tends to surface in almost every version of this experiment regardless of which operating system or hardware gets used and it rarely gets the attention it deserves compared to the flashier memory numbers. Operating systems impose limits on how many files, network sockets, and other system resources a single process or the system as a whole can have open simultaneously. Often referred to as file descriptor limits. Every browser tab that opens a network connection to load a web page consumes one of these file descriptors. And every image, script, and embedded resource on that page potentially consumes several more.

[00:15:33]Linux, particularly in server configurations, typically ships with these limits configured far more generously than a default desktop installation, and system administrators can adjust them directly through straightforward configuration files.

[00:15:46]Windows manages equivalent resource limits through a different underlying mechanism entirely called handles. And while modern versions of Windows have dramatically raised these ceilings compared to decades past, the two operating systems still approach the underlying problem from meaningfully different architectural philosophies. A test pushing thousands of simultaneous tabs, each spawning multiple network connections is exactly the kind of scenario where these normally invisible configuration limits can suddenly become the actual deciding factor in how far the experiment manages to progress before something breaks. It is also worth explaining a bit more about how Chrome specifically tries to manage its own resource consumption once a system starts approaching its limits because the browser itself is not a passive victim in all of this. It actively fights back against exactly this kind of runaway resource consumption. Chrome includes an internal feature often referred to as tab discarding, where the browser automatically identifies tabs that have not been actively viewed or interacted with recently and unloads their content from active memory, keeping just enough information to reload the page quickly if the user switches back to that tab later. Under normal circumstances, this feature helps prevent exactly the kind of memory explosion this test is deliberately trying to trigger. Automated stress tests like this one typically have to work around or specifically account for this behavior. Since a naive testing script might inadvertently trigger Chrome's own self-preservation mechanisms, resulting in a test that technically opens thousands of tabs, but does not actually keep them all genuinely active and consuming memory simultaneously, which would undermine the entire point of the exercise.

[00:17:16]Getting genuinely comparable, meaningful results across two different operating systems requires carefully controlling for exactly this kind of browser level self-management, ensuring both test runs are measuring the same underlying phenomenon rather than accidentally measuring how effectively Chrome's own throttling behavior kicks in on each platform. Let's also talk about what this test reveals, even indirectly about the current state of enterprise and workstation computing more broadly because the hardware itself tells an interesting story on its own. A dual socket EPYC configuration with this much cache, optimized silicon, and this much memory capacity did not exist at anywhere close to this price point or power efficiency even just a handful of years ago.

[00:17:58]AMD's aggressive push into the server processor market over the past several years has fundamentally reshaped what kind of raw computing power is realistically available to researchers, small businesses, and yes, tech content creators willing to invest in genuinely serious hardware for testing purposes.

[00:18:14]The fact that a test like this can even be attempted with off-the-shelf commercially available components rather than requiring access to some exotic customuilt supercomput says something meaningful about how dramatically accessible extreme computing power has become in a relatively short span of time. Cost is worth addressing honestly here too because hardware at this scale carries a price tag that puts it firmly outside anything resembling a normal consumer purchase. Server grade processors like the EPYC9684X purchased in pairs for a dual socket configuration typically run into the tens of alone before accounting for the specialized server grade motherboard capable of supporting dual socket configurations. the substantial cost of one and a half terabytes of server grade DDR5 memory which itself represents a genuinely enormous expense given how memory pricing has behaved over the past couple of years and all the additional supporting infrastructure like power delivery a cooling and enterprisegrade storage needed to make a system like this actually function reliably all told a complete build matching this specification likely represents an investment well into six figures squarely positioning it alongside genuine enterprise server deployments ments rather than anything resembling even the most extreme consumer or proumer computing setup. That price tag actually reinforces something important about why tests like this carry more genuine value than they might initially appear to on the surface. Companies actually spending six figures on server hardware configurations like this one are making that investment specifically because they need to run genuinely demanding memory intensive workloads reliably at scale day after day without unexpected crashes or performance degradation costing them real money and lost productivity missed deadlines or service downtime that customers and stakeholders would immediately notice.

[00:19:59]understanding exactly how Windows and Linux each handle extreme resource pressure on hardware like this is not merely academic curiosity for a company making that kind of investment. It is directly relevant to practical information that could meaningfully influence which operating system they ultimately choose to deploy across their actual production infrastructure, even if the specific test scenario opening thousands of browser tabs is obviously far more playful and exaggerated than whatever genuine workload that company actually plans to run. There is also a fascinating human element buried inside tests like this one that is easy to overlook amid all the technical specifications. Someone had to actually sit down and design the automation scripts controlling exactly how tabs open, how quickly they open, and how the test tracks and records memory consumption, CPU load, and system responsiveness in real time throughout the entire process. Someone had to source, assemble, and configure this genuinely exotic hardware, troubleshooting whatever inevitable compatibility issues arise when you're working with dual socket server motherboards and enterprisegrade memory configurations that most consumer focused technicians rarely encounter in their dayto day work. And someone had to sit through what were almost certainly multiple lengthy test runs, watching tab counts climb into the thousands while carefully documenting exactly when and how each operating system eventually began to struggle. That behind-the-scenes engineering effort, largely invisible in the final polished video presentation, represents a genuinely impressive amount of technical work in service of answering what sounds on its surface like a fairly silly question. It is worth reflecting too on how this specific test fits into a much longer running tradition within technology content creation. One stretching back years before this particular experiment or this particular piece of hardware ever existed, pushing consumer and proumer technology toward genuinely absurd extremes. Whether that means opening an outrageous number of browser tabs, running a graphically demanding video game at a laughably high and unnecessary resolution, or benchmarking how many simultaneous virtual machines a single workstation can handle before buckling under the strain, has become a recognizable and consistently popular genre of technical content precisely because it scratches a very specific, very satisfying itch.

[00:22:08]There is something genuinely compelling about watching engineering limits get tested in real time. Watching numbers climb higher and higher until something inevitably gives way and learning something legitimately useful about how complex systems actually behave once pushed well beyond their comfortable everyday operating boundaries. Zooming back out to the operating system comparison specifically, it is worth emphasizing one final time just how significant it is that this test structure allows for a genuinely controlled apples to apples comparison between Windows and Linux. So much of the ongoing, often heated debate between Windows and Linux advocates online tends to rely on anecdotal experience, personal preference, or benchmarks run on entirely different non-comparable hardware configurations, making genuinely fair, direct comparisons frustratingly rare. Running the identical automated stress test using the identical hardware with the only meaningfully controlled variable being the operating system itself represents exactly the kind of rigorous scientifically minded approach that cuts through so much of the noise surrounding that broader often unproductive online debate. Regardless of which operating system ultimately demonstrates better resilience under this specific kind of extreme memory and process pressure. The methodology itself holding every other variable constant while isolating operating system behavior specifically represents genuinely valuable credible engineering insight rather than just another entry in an endless stream of subjective online arguments. Extreme stress tests like this one seemingly built purely around entertainment and curiosity consistently end up revealing genuinely useful engineering insights that more conventional controlled benchmarking simply cannot surface as clearly.

[00:23:46]Standard benchmarks tend to measure narrow, well- definfined metrics under carefully controlled conditions, which is valuable for consistent, repeatable comparison, but often fails to capture how a system actually behaves once you push it into truly chaotic, unpredictable memory management, process scheduling, and overall stability.

[00:24:04]Genuinely get pushed past every reasonable real world scenario tends to expose exactly the kind of subtle architectural differences and unexpected failure points that only ever show up under genuinely extreme pressure. the kind of pressure ordinary users and even most enterprise workloads will realistically never encounter in practice. That last point deserves a bit more emphasis because it is worth being honest about exactly how far removed this entire test is from anything resembling normal computer usage. No ordinary person and frankly very few enterprise workloads either will ever genuinely need to open thousands of simultaneous browser tabs on a single machine. This test exists specifically to explore an absurd extreme, deliberately pushing far past any realistic use case, precisely because doing so is the most effective way to reveal genuine architectural differences that stay comfortably hidden during normal everyday operation.

[00:24:55][clears throat] In that sense, tests like this one function almost like a stress test for curiosity itself. taking a question so exaggerated that it borders on absurd and using it as a lens to genuinely learn something real and useful about how two fundamentally different operating systems actually behave once pushed toward their absolute limits. It is also worth acknowledging honestly that testing methodology like this inevitably improves and evolves over time, which is part of why creators keep returning to essentially the same core question using progressively updated hardware and testing approaches, refining not just the raw specifications involved, but the actual rigor and fairness of the comparison itself with each successive attempt. Browser architecture itself has changed meaningfully over just the past several years with ongoing improvements to memory management, process isolation, and background tab handling arriving in regular browser updates. Operating systems themselves continue evolving too with both Windows and various Linux distributions regularly refining how they handle memory allocation, process scheduling, and resource management under heavy load. running on updated hardware with updated software and now with a genuinely new operating system comparison element layered on top is exactly how meaningful evolving insight gets built over time rather than treating any single test result as some kind of permanent unchanging final verdict. So what does all of this ultimately tell you? Stepping back from the individual technical details and looking at the bigger picture. A test like this is genuinely fun to watch precisely because it takes an ordinary, universally relatable frustration. Too many browser tabs slowing your computer down and pushes it to a scale so extreme that it becomes almost comedic while simultaneously surfacing real substantive engineering insight about how Windows and Linux fundamentally differ in their approach to memory management, process scheduling, and system stability under genuinely extreme pressure. Whether you personally care even slightly about NUMA architecture out of memory killer mechanisms or three-dimensional Vcash technology, watching an absurdly powerful computer get pushed toward its absolute breaking point twice on two different operating systems taps into something universally satisfying about watching engineering limits get tested in the most extreme unapologetic way imaginable. The deeper lesson embedded inside tests like this one is that raw specifications alone never tell the complete story of how a computer system actually performs. One and a half terabytes of memory sounds on paper like an essentially limitless resource, more RAM than any reasonable workload could conceivably exhaust. Yet, the actual results of tests like this one consistently demonstrate that plenty of other factors, browser architecture, operating system scheduling, network infrastructure, and dozens of other interconnected variables, tend to become the genuine limiting factor long before raw memory capacity itself ever gets fully exhausted. That insight matters well beyond the specific context of browser tabs extending into essentially every corner of modern computing where people assumed there is one more thing worth sitting with before wrapping up. Something that applies well beyond this specific test and touches. Almost everyone watching this video on some ordinary computer with a completely unremarkable amount of memory by comparison. The next time your own browser starts feeling sluggish with what probably amounts to a genuinely modest number of tabs open, somewhere between 10 and 30 for most people, remember that even a machine boasting 192 physical cores and a full terabyte and a half of memory still eventually hits its own breaking point. Just at a scale most of us will personally need to worry about the underlying architecture, the process overhead, the scheduling complexity, all of it scales up proportionally. meaning your own modest computer is fighting exactly the same fundamental battle just at a dramatically smaller and far more relatable scale. Before you go, if you want to see more of this exact kind of hardware pushed to genuinely absurd extremes just to answer questions nobody strictly needed answered, subscribe to the channel right now so you catch the next one the moment it goes live.

[00:28:46]Because tests this ridiculous and this genuinely informative are exactly the kind of content worth sticking around for. Keep watching for whichever operating system comes out ahead here and pay attention specifically to where each one starts to struggle because that breaking point, wherever it happens to land, is going to tell you far more about how Windows and Linux actually work under the hood than any spec sheet ever Good.