Cloudflare освободила 100 ТБ памяти: когда серверу нужна оптимизация, а не новый тариф

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

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

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

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

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

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

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

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

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

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

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

On September 18, 2026, Cloudflare announced it had reduced memory (RAM) usage in its infrastructure by more than 100 TB. The cause of the overspend 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 number.

For a small online store, the scale is different, but the question remains the same: why is there not enough memory? I would start a conversation about a new plan by answering that. Additional gigabytes are useful when the workload grows. However, if an application holds data uncontrollably, increasing the limit only delays the next failure.

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 time increases simultaneously, the system starts using the disk heavily 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 a period of normal operation and a traffic peak. A snapshot taken on a quiet Sunday evening does not answer what happens during a promotional campaign.

First scenario: memory runs out only when exchanging data with the accounting system. In this case, examine the size of a single batch of imported products, the level of parallel loading, and the schedule. If import, backup, and catalog recalculation start simultaneously, the issue may lie in the organization of these tasks.

Second scenario: memory usage gradually increases even with steady traffic, then drops sharply after a restart. This is a sign to look for held objects, unfinished tasks, and unlimited 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 occupied with useful work. In this case, increasing server capacity or separating services may be justified. It is also unwise to save on the server at the cost of lost orders.

A good task includes initial measurements, a problematic scenario, and acceptance criteria. For example: when the catalog is loaded and orders are being placed simultaneously, the site must respond within the established time limit, and handlers must not terminate abnormally. A reduction in memory usage alone does not prove an improvement.

After a change, compare identical conditions: the number of visitors, catalog volume, and enabled integrations. Otherwise, it is easy to attribute the result to optimization when it actually occurred simply because a sale ended.

If the site is already losing orders, a temporary reserve of resources may be the fastest way to restore operations. It is important to record which problem this addresses 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 the same savings for any VPS. A useful takeaway for a site owner is this: before committing to permanent increased spending, determine exactly what the additional gigabytes are purchasing—business growth or a delay in fixing a bug.