Блог компании 3v-Hosting
12 мин.
Представьте ситуацию, когда ваш сайт или проект начал нещадно "тупить", страницы открываются медленно либо вообще падают, пользователи жалуются, конверсия падает. Если вам знакома такая ситуация, то в большинстве случаев ваша первая реакция - это залезть в код, попытаться оптимизировать SQL-запросы, включать и перенастраивать кеширование и т.д. и т.п. И, как ни странно, но часто эти действия и в правду помогают. Правда есть такой сценарий, который регулярно упускают даже опытные администраторы. Сценарий этот заключается в том, если проблема возникла не в приложении, а в ресурсах самого сервера на котором развёрнут проект.
И самое неприятное в этом то, что деградация инфраструктуры почти никогда не выглядит как "сервер просто упал". Это всегда носит характер постепенного ухудшения состояния системы, когда сегодня сайт работает чуть медленнее, чем вчера, завтра появляются пики на графиках загрузки в мониторинге, а потом появляются и жалобы пользователей на работу сервиса.
Давайте-же ниже попробуем разобраться, как распознать, что вам пора обновить железо и как не перепутать это с проблемами в коде или в логике работы вашего проекта.
Большинство технических разборов начинается одинаково, мы начинаем искать узкое место в коде. И это абсолютно правильная стратегия, так как в 70-80% случаев проблема действительно там. Например плохие SQL-запросы, отсутствие индексов в таблицах, лишние никому не нужные вычисления, неудачная архитектура приложения и многое многое другое - всё это является классикой. Но наступает момент, когда дальнейшее копание в коде перестаёт давать результат и превращается в бег по кругу.
Этот момент обычно наступает тогда, когда вы уже навели порядок в приложении, но поведение системы остаётся странным. То у вас всё работает быстро и без проблем, то внезапно появляются задержки, причём без очевидной причины, независимо ни от времени суток, ни от видимой нагрузки на сервер. В такие моменты важно остановиться, глубоко вдохнуть, сделать шаг назад и посмотреть не на код, а на среду, в которой он работает.
Итак, если вы уже:
, но сайт по прежнему продолжает "жить своей жизнью" - то это сильный сигнал, что проблема может находиться ниже уровня приложения.
Важно всегда держать в голове, что даже идеально написанный код не может работать быстро, если ему банально не хватает ресурсов. Это ведь как пытаться разогнать спортивный автомобиль по разбитой дороге - потенциал, в принципе есть, но вот условия не позволяют его реализовать в полной мере.
К сожалению железо при сбоях ведёт себя очень тихо, то есть оно не выдаёт громких понятных ошибок вроде stack trace или 500-ых ответов. А вместо этого начинают появляться некоторые косвенные симптомы, такие как:
Именно из-за этой неочевидности многие команды попадают в ловушку, когда они продолжают оптимизировать код, который уже работает нормально, вместо того чтобы устранить реальное узкое место, как например нехватку CPU, RAM или диска.
Теперь, когда мы обсудили суть проблемы, настало время поговорить детально о каждой составляющей отдельно.
Когда речь заходит о производительности, то процессор - это первое, на что обычно обращают внимание. И это логично, ведь именно CPU выполняет весь ваш код - от PHP-скриптов и Python-приложений до обработки запросов веб-сервером и работы базы данных. Но важный нюанс состоит в том, что проблема почти никогда не заключается просто в абстрактной высокой загрузке CPU. Гораздо важнее понять, как именно он загружается, каков преобладающий тип загрузки.
Тут многие ориентируются на простую метрику: если CPU загружен на 80-100% - значит это плохо и пора арендовать новый сервер. Но на практике это лишь часть картины и намного правильнее будет оценивать поведение нагрузки, равномерная ли она, возникают ли пики, насколько быстро CPU отпускает выполняемые задачи и т.д.
Если загрузка процессора стабильно держится на уровне 80-100% - то это, бесспорно, тревожный сигнал. Но ещё более показательным является сценарий, при котором на графике нагрузки появляются кратковременные, но частые пики при, казалось бы, обычных действиях пользователей, например, при открытии каталога или страницы товара.
Типичными признаками того, что CPU становится узким местом чаще всего являются:
Почему это происходит? Потому, что каждое действие пользователя является неким набором операций, таких как выполнение кода, работа с базой, обработка шаблонов или например иногда криптография. Так вот если таких операций становится слишком много одновременно, процессор просто не успевает их обрабатывать (ваш Кэп).
Классическим примером могут послужить сайты на CMS вроде WordPress или OpenCart. Вот вроде бы всё оптимизировано, плагинов по минимуму, кеш включён, запросы в порядке. Но почему-то при 20-30 одновременных пользователях сервер начинает "задыхаться". Это означает, что каждая страница всё ещё требует достаточно CPU-времени, и в сумме нагрузка превышает возможности процессора.
Отдельно стоит упомянуть ситуацию, когда нерадивые и/или жадные хостинг-провайдеры продают вам VPS с overselling, когда формально вам выделяют vCPU, но физически этот процессор делится между большим количеством других клиентов. В результате, в спокойное время всё работает нормально, но как только начинается нагрузка (у вас или у соседей), то доступное CPU-время резко уменьшается и в такие моменты вы получаете не полноценный процессор, а его "остатки", что сразу начинает сказываться на времени ответа вашего сайта.
На практике это выглядит так, что вы ничего не меняете в коде уже длительное время, трафик также находится в нормальных пределах, но ваш сайт вдруг начинает работать медленнее, появляются задержки, а CPU в метриках ведёт себя нестабильно. И если не учитывать фактор виртуализации, то это очень легко принять за проблему в приложении, хотя, как мы уже выяснили, причина тут чисто инфраструктурная.
С оперативной памятью ситуация гораздо менее очевидная, чем с CPU. Когда процессора не хватает - то это обычно видно сразу. А вот нехватка RAM может долго маскироваться под всевозможные странные тормоза, которые сложно объяснить. Сервер вроде не падает, ошибки не сыпятся, но сайт начинает вести себя медлительно и нестабильно.
Причина в том, что при нехватке памяти система не останавливается. Вместо этого она включает так называемый механизм подкачки - swap. Это означает, что часть данных выгружается из RAM на диск, чтобы освободить место в памяти под новые задачи. И формально всё продолжает работать, но фактически производительность падает в разы.
Почему это так критично? Потому что доступ к RAM измеряется наносекундами, а к диску - миллисекундами (в зависимости от типа диска). Разница, как видно, в тысячи раз. И как только система начинает активно использовать swap, то каждый запрос превращается в цепочку медленных операций чтения/записи (IO).
Исходя из сказанного, типичные признаки нехватки RAM выглядят так:
free -m или htop.
На практике это ощущается очень неприятно, когда сайт вроде бы жив, но периодически как будто замирает. Пользователь нажимает кнопку - и ждёт. Потом всё снова работает быстро, и через минуту ситуация повторяется.
Хорошая аналогия - это ваш письменный рабочий стол. Если у вас на столе достаточно места, то всё лежит под рукой, но если стол завален, вы начинаете складывать вещи в соседнюю комнату. И теперь каждое ваше действие требует дополнительного времени, ведь вам нужно встать, дойти, взять какой-то предмет и вернуться. Именно это и делает swap.
Особенно сильно от нехватки RAM страдают компоненты, которые активно работают с данными:
Если памяти не хватает, база начинает чаще обращаться к диску, кеш теряет эффективность, а процессы приложения начинают конкурировать за ресурсы. И в итоге тормозит всё сразу.
И здесь важный промежуточный вывод, что даже идеально оптимизированное приложение не сможет работать быстро, если ему банально негде хранить данные. Оперативная память - это не просто ещё один ресурс сервера, а без преувеличения фундамент всей производительности.
Про диск часто вспоминают в последнюю очередь. Обычно кажется, что главное - это CPU и RAM, а на диске ведь просто хранятся файлы. Но на практике проблемы с диском - это одна из самых частых причин скрытых тормозов, особенно в проектах с обширными базами данных.
Важно понимать, что диск - это не просто место хранения файлов, но и то, что каждый диск имеет свою скорость доступа к хранимым данным. И разница скорости записи/чтения между обычным HDD, обычным SSD и NVMe диском может быть в несколько раз. А самое главное, что если диск не успевает обрабатывать операции, то вся система начинает ждать. Конечно, бывают исключения, как например приложения, оптимизированные для работу исключительно на базе оперативной памяти. Но всё же, в большинстве проектов, рано или поздно данные должны будут сохраняться на диск.
Когда приложение делает запрос к базе или пишет лог, оно не может продолжить работу, пока диск не ответит. И если таких операций много - то начинает скапливаться очередь. В какой-то момент получается, что CPU может быть свободен, RAM - в полном порядке, но процессы просто стоят и ждут I/O (Input/Output).
Типичными признаками того, что вы упёрлись в диск являются:
Это легко перепутать с проблемами в коде или базе, но ключевая деталь тут абсолютная непредсказуемость. Иногда всё работает быстро, а иногда случаются внезапные задержки, хотя нагрузка, казалось бы, не изменилась.
Особенно чувствительными к скорости диска являются:
К сожалению, часто дешёвые SATA SSD могут упираться в I/O так же, как и старые HDD диски, особенно под большой нагрузкой. Поэтому настоящий скачок производительности обычно даёт переход на NVMe-диска, где задержки и throughput на порядок лучше. Именно поэтому мы в 3v-Hosting перешли на NVMe-диски.
Итак, запомнили, что если у вас низкая загрузка CPU, достаточно свободной оперативной памяти, но сайт всё равно тормозит, то очень велика вероятность, что узкое место именно в диске.
Но бывают случаи, когда ситуация выглядит максимально странно. Код давно не менялся, нагрузка на сервер та же, метрики CPU и RAM в полном порядке, диск почти не используется, но сайт то летает, то внезапно начинает безбожно тормозить. В такие моменты проблема может быть вообще не в вашем проекте, а в том, где он размещён.
Если вы используете VPS или облачную виртуализацию, то важно понимать, что в таком случае вы делите физические ресурсы одного физического сервера с другими клиентами. То есть все ресурсы сервера, процессор, диск, сеть - всё это общее. И если кто-то из ваших "соседей" начинает активно нагружать систему, то это может повлиять и на вас.
Этот эффект называется noisy neighbor или "шумный сосед". Он особенно заметен на недорогих VPS-тарифах, где ресурсы не гарантированы жёстко, а распределяются динамически. Также этим сильно страдают хостинги, использующие типы виртуализации со слабой изоляцией. Подробнее о типах виртуализации можно прочитать в этой статье.
На практике это может проявляться следующим образом:
Да, как вы видите, симптомы аналогичны тем, что мы описывали для других составляющих. Но на этот раз, главная сложность в том, что внутри самой своей системы вы можете не увидеть явных причин. Все ваши процессы выглядят нормально, но реальные задержки возникают на уровне гипервизора, то есть там, где вы уже не контролируете ситуацию.
Особенно часто это проявляется при нагрузке на диск или CPU со стороны других клиентов. Например, сосед запускает интенсивную обработку данных или создание бэкапа, а в этот момент вы внезапно получаете рост задержек, хотя у вас ничего не изменилось.
В этом и заключается коварство, ведь такие проблемы легко принять за так называемый "плавающий баг" в коде или нестабильную работу базы. Но если поведение хаотичное и не воспроизводится стабильно, то почти всегда стоит смотреть в сторону инфраструктуры.
Именно поэтому для проектов со стабильно высокой нагрузкой или общими требованиями к стабильности, важно учитывать не только характеристики VPS, но и политику провайдера, а именно выделяются ли гарантированные ресурсы, каков тип виртуализации, какой уровень overselling, какая дисковая подсистема используется.
Мы в 3v-Hosting давным давно отказались от оверселлинга в пользу гарантирования стабильности предоставляемой клиентам инфраструктуры, так как понимаем, что главной ценностью хостинга являются не цена или конкретные параметры сервера, а стабильность его работы на длительном промежутке времени. Это наша ценность, это наша философия.
После всех разборов CPU, RAM, диска и инфраструктуры можно свести диагностику к одному простому принципу, когда в большинстве случаев различие между "проблемой в коде" и "проблемой в ресурсах" видно по поведению системы во времени.
Код, как правило, ведёт себя предсказуемо и если в нём есть узкое место, то оно будет проявляться одинаково каждый раз при одних и тех же условиях (принцип воспроизводимости). Но вот железо, наоборот, даёт плавающие, нестабильные симптомы, которые усиливаются под нагрузкой и часто зависят от внешних факторов.
Итак, давайте соберём короткое саммари, на которое можно будет опираться в реальной работе:
Если проблема в коде:
Если проблема в ресурсах (CPU, RAM, диск, VPS):
Главный практический ориентир звучит просто: если вы ничего не меняли, но производительность "гуляет", то почти наверняка дело не в коде (снова ваш Кэп).
Теория - это конечно хорошо, но в реальной работе всё сводится к тому, чтобы зайти на сервер и понять, что именно происходит прямо сейчас. И здесь важно не просто запустить пару команд, а уметь связать их показатели между собой.
Никогда не смотрите на какую-то одну метрику. Вам нужно получить общую картину происходящего в системе, так как симптом почти всегда проявляется сразу в нескольких местах.
Ниже мы привели компактный набор стандартных проверок, который позволяет за пару минут понять, что происходит и локализовать проблему.
Начните с базы и посмотрите, чем занят процессор и нет ли явного упора.
top
Или более удобно:
htop
На что смотреть:
%CPU у процессов - кто именно грузит систему,load average - общая очередь задач,%us / %sy - пользовательская и системная нагрузка.
Интерпретация результатов:
Теперь проверяем память. Здесь важно не только количество свободной оперативки, но и наличие swap.
free -m
Дополнительно можно посмотреть в htop (там нагляднее).
На что смотреть:
available - сколько реально доступно памяти;swap - используется ли подкачка.
Интерпретация результатов:
Если CPU не загружен, а сайт всё равно тормозит, почти всегда стоит проверить диск.
iostat -x 1
На что смотреть:
%util - загрузка диска,await - время ожидания операций,%iowait (в top) - сколько CPU ждёт диск.
Интерпретация результатов:
await, значит диск отвечает медленно;%util близко к 100%, значит диск упёрся в предел;
Чтобы увидеть систему целиком, удобно использовать такой инструмент:
vmstat 1
На что смотреть:
r - очередь процессов (нагрузка на CPU);si/so - активность swap;wa - ожидание диска.
Интерпретация результатов:
wa, значит проблема с диском;si/so, значит система уходит в swap;r , значит CPU не справляется.
Иногда достаточно всего одной команды, чтобы понять, что происходит:
uptime
Она покажет такой параметр, как load average.
Интерпретация результатов:
Поработайте с данными командами, потренируйтесь делать выводы на основе их результатов, чтобы в критический момент быстро и уверенно определить суть проблемы и быстро устранить её.
Есть моменты в жизни, которые многие пытаются оттянуть - например поход к стоматологу или смена летней резины на зимнюю на автомобиле. Это же происходит и в случае с обновлением сервера - когда становится понятно, что проблема уже не в коде, а в ресурсах. Обычно перед этим все проходят классический путь оптимизации запросов, настройки кеша, переписывания отдельных частей логики. И это правильно! Но на каком-то этапе становится очевидно, что каждое следующее улучшение даёт всё меньший эффект.
Это и есть главный сигнал, значит вы упёрлись в потолок текущей инфраструктуры.
В этот момент важно правильно расставить приоритеты, ведь можно продолжать искать и исправлять микропроблемы в самом приложении, но если базовый уровень ресурсов не соответствует нагрузке, это будет борьба с симптомами, а не с причиной.
Железо в этом смысле является фундамент всей системы. А если этот фундамент слабый, никакая оптимизация сверху не сможет сделать систему по-настоящему быстрой и стабильной. Тем более решать этот вопрос становится намного проще, учитывая постоянно снижающиеся цены на серверы.
Чаще всего это связано с ростом нагрузки - либо вашей (больше пользователей), либо на уровне хоста (если это VPS с соседями). Код, очевидно, от времени суток не меняется, а вот доступные ресурсы - вполне могут.
Нет. Кеш снижает нагрузку, но не увеличивает ресурсы сервера. Если упор в CPU, RAM или диск, то кеш лишь временно сгладит проблему.
Достаточно посмотреть free -m. Если используется swap, то памяти уже не хватает, даже если система ещё вполне выглядит работоспособной.
Зависит от проекта. Но на практике для сайтов с базой данных чаще узким местом становится диск, а не CPU.
Скорее всего, процессы ждут диск (I/O) или упираются в RAM/swap. CPU может быть свободен, пока система стоит в ожидании.
Да. На дешёвых VPS часто проявляется эффект "шумных соседей". В этом случае производительность плавает без изменений в коде.
Когда сайт начинает тормозить, первое желание - лезть в код. Это правильная привычка, но важно вовремя остановиться и задать себе более широкий вопрос: а точно ли проблема в приложении, а не в ресурсах, на которых оно работает?
На практике очень часто оказывается, что узкое место - это не конкретный алгоритмы и не запросы, а банальная нехватка CPU, RAM или скорости диска. Причём такие проблемы проявляются неочевидно, что затрудняет их локализацию.
Самая частая ошибка - это продолжать оптимизировать то, что уже работает нормально. Можно потратить дни или недели, выжимая проценты производительности, хотя реальное решение состоит в увеличении ресурсов или смене инфраструктуры.
Хорошая инфраструктура не требует внимания. Она не создаёт лишнего шума, не даёт случайных просадок и не ограничивает рост проекта. Она просто позволяет системе работать так, как задумано.
Одной из самых частых ошибок, получаемых во время работы в интернете, с сайтами или приложениями - это ошибка 502 Bad Gateway и неопытного пользователя или адми...
Выбор оптимального сервера для хранения баз данных требует соблюдения баланса между производительностью, надежностью и масштабируемостью. Дело не только в мощно...
Думаю никто не будет спорить с тем, что в наше время у любой компании должно быть максимальное присутствие в интернете. И конечно это касается начинающих бизнес...
Proxy и VPN часто путают, но это разные инструменты. Разбираем, как они работают, в чём разница, когда использовать каждый и как правильно применять их в реальн...
Уязвимости WordPress на практике, как их находят через WPScan, где искать слабые места и какие ошибки чаще всего приводят к взлому сайта и потере контроля.
Пошаговая инструкция по настройке WireGuard на VPS: установка, генерация ключей, конфигурация сервера и клиента, запуск VPN и решение типичных проблем. Быстрый ...
