Cloudflare Freed 100 TB of Memory: When a Server Needs Optimization, Not a New Plan

18 сентября 2026 года Cloudflare рассказала, как сократила расход оперативной памяти более чем на 100 ТБ в своей инфраструктуре. Причиной перерасхода оказалась структура данных в сервисе распределения нагрузки на базе Pingora. Исправление алгоритма дало эффект, который на тысячах серверов превратился в огромную цифру.

Для небольшого интернет-магазина масштаб другой, но вопрос тот же: почему памяти не хватает? Я бы начинала разговор о новом тарифе с ответа на него. Дополнительные гигабайты полезны, когда растёт полезная нагрузка. Если же приложение бесконтрольно удерживает данные, увеличение лимита только отодвигает следующий сбой.

График с высоким потреблением сам по себе мало что объясняет. Часть памяти может занимать полезный кеш. Тревожнее, когда одновременно растёт время ответа, система начинает активно использовать диск вместо RAM или завершает процессы из-за нехватки ресурсов.

Попросите администратора показать потребление по службам: база данных, обработчики сайта, поиск, фоновые задания. Нужен период с обычной работой и пиком посещаемости. Снимок в спокойный воскресный вечер не отвечает на вопрос, что происходит во время рекламной кампании.

Первый вариант: память заканчивается только при обмене с учётной системой. Тогда стоит изучить размер пакета товаров, параллельность загрузки и расписание. Если одновременно стартуют импорт, резервное копирование и пересчёт каталога, проблема может быть в организации работ.

Второй вариант: расход постепенно увеличивается даже при ровном трафике, а после перезапуска резко падает. Это повод искать удерживаемые объекты, незавершённые задачи и неограниченные кеши. Регулярный перезапуск способен временно поддержать работу, но причину он не объясняет.

Третий вариант: каждый процесс ведёт себя предсказуемо, однако покупателей стало больше и все ресурсы заняты полезной работой. Здесь увеличение мощности или разделение служб может быть обоснованным. Экономить на сервере ценой потерянных заказов тоже неразумно.

Хорошее задание содержит исходные измерения, проблемный сценарий и критерий приёмки. Например: при одновременной загрузке каталога и оформлении заказов сайт сохраняет согласованное время ответа, а обработчики не завершаются аварийно. Само по себе снижение занятой памяти ещё не доказывает улучшение.

После изменения сравнивают одинаковые условия: число посетителей, объём каталога, включённые интеграции. Иначе легко приписать оптимизации результат, полученный просто потому, что закончилась распродажа.

Если сайт уже теряет заказы, временный запас ресурсов может быть самым быстрым способом восстановить работу. Важно записать, какую проблему он закрывает и когда команда вернётся к диагностике. А для длительных изменений пригодятся тестовая копия и возможность отката.

Цифра Cloudflare — результат конкретной инженерной работы, а не обещание такой же экономии для любого VPS. Полезный вывод для владельца сайта проще: до постоянного увеличения расходов стоит выяснить, что именно покупают дополнительные гигабайты — рост бизнеса или отсрочку исправления ошибки.

On September 18, 2026, Cloudflare announced it had reduced its operational memory consumption by more than 100 TB across its infrastructure. The culprit was a data structure in its Pingora-based load balancing service. Fixing the algorithm produced an effect that, across thousands of servers, translated into a massive figure.

For a small online store, the scale is different, but the question remains the same: why is memory insufficient? I would start any conversation about a new plan by answering that. Additional gigabytes are useful when actual workload increases. However, if an application hoards data uncontrollably, raising the limit only delays the next outage.

A graph showing high consumption explains little on its own. Part of the memory may be occupied by useful cache. It is more concerning when response times rise simultaneously, the system starts heavily using the disk instead of RAM, or processes are terminated due to resource shortages.

Ask the administrator to show resource consumption by service: database, site handlers, search, and background jobs. You need data from both normal operation and peak traffic periods. A snapshot taken on a quiet Sunday evening does not answer what happens during a promotional campaign.

First scenario: memory runs out only when interacting with the accounting system. In this case, examine the product package size, upload concurrency, and scheduling. If imports, backups, and catalog recalculation start simultaneously, the issue may lie in how the tasks are organized.

Second scenario: memory usage gradually increases even with steady traffic, then drops sharply after a restart. This is a sign to look for retained objects, unfinished tasks, and unbounded caches. Regular restarts can temporarily sustain operations, but they do not explain the root cause.

Third scenario: each process behaves predictably, but the number of buyers has grown and all resources are now fully utilized for productive work. Here, increasing server capacity or separating services may be justified. It is unwise to save on server costs at the expense of lost orders.

A good task includes baseline measurements, the problematic scenario, and acceptance criteria. For example: when the catalog loads and orders are placed simultaneously, the site maintains consistent response times, and handlers do not terminate abnormally. Merely reducing memory usage does not prove an improvement.

After making changes, compare identical conditions: visitor count, catalog size, and enabled integrations. Otherwise, it is easy to attribute results to optimization when they actually occurred simply because a sale ended.

If the site is already losing orders, temporarily increasing resources may be the fastest way to restore operations. It is important to document which issue this resolves and when the team will return to diagnostics. For long-term changes, a test copy and the ability to roll back are essential.

The Cloudflare figure is the result of specific engineering work, not a promise of similar savings for any VPS. A more practical takeaway for a site owner is this: before committing to permanent cost increases, determine what the additional gigabytes are actually buying—business growth or a delay in fixing a bug.