Авторы тестов в блоге Kubernetes проверили сборку ядра Linux, браузеры без графического интерфейса и изолированные среды Python со swap, подкачкой памяти на диск. В тесте Python подкачка позволила увеличить число одновременных изолированных сеансов на одном узле с 80 до 240.

Для подкачки использовали локальные SSD, твердотельные накопители, на которые переносили неиспользуемые данные из оперативной памяти. В тесте браузеров с gVisor, средой для изолированного запуска контейнеров, число одновременно работающих контейнерных задач выросло с 80 до 160.

Авторы отмечают, что при максимальном числе сеансов Python задержки росли главным образом из-за конкуренции за процессор. При снижении лимита памяти до 200 МБ время сборки ядра увеличилось более чем на 40%.

Проверка утверждений:

  • Авторы статьи в блоге Kubernetes проверили swap на локальных SSD на трёх типах нагрузки и получили рост числа задач на узле до трёх раз в тесте изолированных сеансов Python. (подтверждено самой публикацией: доказательство; «This post explains how we benchmarked that approach across three workloads, including CI/CD kernel builds, sandboxed headless browsers, and isolated Python runtimes; we found density gains of up to 3×, often with little or no latency cost.»)
  • Для подкачки использовали локальные SSD, на которые переносили неиспользуемые данные из оперативной памяти. (подтверждено самой публикацией: доказательство; «Enabling Local SSD swap offloaded dormant anonymous memory, freeing up physical RAM and preserving the node’s page cache.»)
  • В тесте Python подкачка позволила увеличить число одновременных изолированных сеансов на одном узле с 80 до 240. (подтверждено самой публикацией: доказательство; «Without swap, heavy concurrent bursts exhausted physical memory, causing the node to hit a hard RAM limit and fail at 80 concurrent sessions. Enabling Local SSD swap offloaded dormant anonymous memory, freeing up physical RAM and preserving the node’s page cache. This allowed the node to scale to 240 concurrently isolated Python sandboxes—a 3× density improvement.»)
  • В тесте браузеров с gVisor число одновременно работающих контейнерных задач выросло с 80 до 160. (подтверждено самой публикацией: доказательство; «Without swap, a gVisor environment hit a hard limit at 80 pods. Local SSD swap doubled that capacity, which allowed 160 concurrent gVisor pods on a single node.»)
  • Авторы отмечают, что при максимальном числе сеансов Python задержки росли главным образом из-за конкуренции за процессор. (подтверждено самой публикацией: доказательство; «As with the browser workloads, the latency rise at peak density comes mainly from the sandboxes competing for CPU rather than from swap itself.»)
  • При снижении лимита памяти до 200 МБ время сборки ядра увеличилось более чем на 40%. (подтверждено самой публикацией: доказательство; «However, as an explicit tradeoff, compressing the limit further to 200 MB forced the active working set into swap, causing long I/O wait times and increasing execution time by over 40%.»)

Первоисточники:

оценка 52,8 из 100 · тип: исследование