что такое падение сервера
Как привести в порядок перегруженный сервер?
Материал, перевод которого мы сегодня публикуем, посвящён поиску узких мест в производительности серверов, исправлению проблем, улучшению производительности систем и предотвращению падения производительности. Здесь, на пути к решению проблем перегруженного сервера, предлагается сделать следующие 4 шага:
1. Оценка ситуации
Когда трафик перегружает сервер, узким местом производительности могут стать процессор, сеть, память, дисковая подсистема ввода-вывода. Определение того, что именно вызывает проблему, позволяет сконцентрировать усилия на самом важном. Рассмотрим некоторые особенности анализа важнейших серверных подсистем.
Начать работу по выявлению проблем сервера можно, воспользовавшись командой top. Если есть такая возможность, здесь можно прибегнуть к историческим данным хостинг-провайдера и к данным, собранным системами мониторинга.
2. Стабилизация сервера
Наличие в системе перегруженного сервера может быстро привести к каскадным отказам в других частях системы. В результате важно, после того, как стало известно о том, что сервер перегружен, стабилизировать его, а уже потом исследовать ситуацию на предмет внесения в систему неких серьёзных улучшений.
▍Ограничение скорости обработки запросов
Ограничение скорости обработки запросов позволяет защитить инфраструктуру, ограничивая количество входящих запросов. Это очень важно при падении производительности сервера. По мере того, как растёт время ответа сервера, пользователи имеют свойство агрессивно обновлять страницу, что ещё сильнее повышает нагрузку на сервер.
Хотя отказ от обработки запроса — мера простая и действенная, лучше всего снижать нагрузку на сервер, занимаясь ограничением числа поступающих к нему запросов средствами некоей внешней системы. Это может быть, например, балансировщик нагрузки, обратный прокси-сервер или CDN. Ниже приведены ссылки на инструкции по работе с несколькими системами такого рода:
▍HTTP-кеширование
Поищите способы улучшения кеширования содержимого. Если ресурс может быть отдан пользователю из HTTP-кеша (из кеша браузера или из CDN), тогда его не нужно запрашивать с сервера, что уменьшает нагрузку на сервер.
HTTP-заголовки наподобие Cache-Control, Expires и ETag указывают на то, как должен кешироваться тот или иной ресурс. Аудит и исправление этих заголовков могут помочь улучшить кеширование.
Хотя для кеширования можно прибегнуть к возможностям сервис-воркеров, они используют отдельный кеш. Это — помощь основной системе кеширования браузера, а не её замена. Поэтому при исправлении проблем перегруженного сервера усилия надо сосредоточить на оптимизации HTTP-кеширования.
Диагностика
Запустите Lighthouse и взгляните на показатель Serve static assets with an efficient cache policy для того чтобы увидеть список ресурсов с коротким и средним временем кеширования (Time To Live, TTL). Проанализируйте ресурсы, перечисленные в списке, и рассмотрите возможность увеличения их TTL. Вот ориентировочные сроки кеширования, применимые к различным ресурсам.
Настройка кеширования
Нужно записать в директиву max-age заголовка Cache-Control необходимое время кеширования ресурса, выраженное в секундах. Вот инструкции по настройке этого заголовка в разных системах:
▍Постепенное сокращение возможностей системы
Постепенное сокращение возможностей системы — это стратегия временного ограничения функционала, направленная на снятие с сервера чрезмерной нагрузки. Эта концепция может быть применена множеством различных способов. Например, выдача клиентам статической текстовой страницы вместо полномасштабного приложения, отключение поиска или возврат меньшего, чем обычно, количества результатов поиска. Сюда относится и отключение ресурсоёмких возможностей проектов, не влияющих на их основной функционал. Основное внимание тут должно быть уделено отключению функционала, от которого можно отказаться, не слишком сильно воздействовав на основные возможности приложения.
3. Улучшение системы
▍Использование CDN
Задача по обслуживанию статических ресурсов может быть переложена с сервера на сеть доставки контента (Content Delivery Network, CDN). Это позволит снизить нагрузку на сервер.
Основная функция CDN заключается в быстрой доставке материалов пользователям благодаря использованию большой сети серверов, расположенных поблизости от пользователей. Кроме того, некоторые CDN предлагают дополнительные возможности, связанные с производительностью. Среди них — сжатие данных, балансировка нагрузки, оптимизация медиа-файлов.
Настройка CDN
Преимущества CDN раскрываются в том случае, если компания, владеющая сетью, имеет большую группировку серверов, распределённых по всему миру. Поэтому поддержка собственного CDN-сервиса редко имеет смысл. Обычная настройка CDN — это достаточно быстрая процедура, занимающая около получаса. Она заключается в обновлении DNS-записей таким образом, чтобы они указывали бы на CDN.
Оптимизация использования CDN: исследование ситуации
Для того чтобы идентифицировать ресурсы, которые обслуживаются не с помощью CDN (но должны выдаваться пользователям с CDN), можно воспользоваться WebPageTest. На странице результатов щёлкните по прямоугольнику, подписанному как Effective use of CDN и просмотрите список ресурсов, которые следует обслуживать средствами CDN.
Результаты, выдаваемые WebPageTest
Решение проблем
Если ресурсы не кешируются с помощью CDN, выясните, выполняются ли следующие условия:
▍Масштабирование вычислительных ресурсов
Решение относительно масштабирования вычислительных ресурсов следует принимать с осторожностью. Хотя часто решить некие проблемы можно, прибегнув к масштабированию, сделав это несвоевременно, можно неоправданно усложнить систему и необоснованно повысить затраты на её поддержку.
Диагностика
Высокий показатель, характеризующий время до первого байта (Time To First Byte, TTFB), может быть признаком того, что сервер приближается к пределам своих возможностей. Найти сведения о TTFB можно в разделе Reduce server response times (TTFB) отчёта Lighthouse.
Для более глубокого исследования ситуации нужно воспользоваться каким-нибудь средством мониторинга и проанализировать использование процессора. Если текущее или прогнозируемое значение загрузки процессора превышает 80% — это значит, что нужно задуматься о повышении мощности сервера.
Решение проблем
Добавление в систему балансировщика нагрузки позволяет распределять трафик между множеством серверов. Балансировщик нагрузки находится перед пулом серверов и распределяет трафик на подходящие серверы. Облачные провайдеры предлагают пользователям балансировщики нагрузки (GCP, AWS, Azure), но можно пользоваться и собственным балансировщиком, применив HAProxy или NGINX. После того, как балансировщик нагрузки готов к работе, в систему можно добавлять дополнительные серверы.
В дополнение к балансировке нагрузки большинство облачных провайдеров предлагает услуги по автоматическому масштабированию вычислительных мощностей (GCP, AWS, Azure). Автоматическое масштабирование связано с балансировкой нагрузки. А именно, при автоматическом масштабировании ресурсов в моменты высокой нагрузки производится выделение дополнительных ресурсов, а в периоды низкой — отключение ненужных ресурсов. Но, даже учитывая это, нужно отметить, что автоматическое масштабирование — это тоже не универсальное решение. Для автоматического запуска серверов нужно время. Конфигурации автоматического масштабирования требуют серьёзной настройки. Поэтому до применения сложной системы автоматического масштабирования стоит опробовать сравнительно простую конфигурацию с балансировщиком нагрузки.
▍Использование сжатия данных
Текстовые ресурсы нужно сжимать с использованием алгоритма gzip или brotli. В некоторых случаях сжатие может помочь в сокращении размеров таких ресурсов примерно на 70%.
Диагностика
Для того чтобы найти ресурсы, нуждающиеся в сжатии, можете воспользоваться показателем Enable text compression из отчёта Lighthouse.
Решение проблем
Для включения сжатия нужно отредактировать настройки сервера. Вот подробности об этом:
▍Оптимизация изображений и других медиа-материалов
На изображения приходится основной объём материалов большинства веб-сайтов. Оптимизация изображений может привести к значительному уменьшению размеров материалов сайта. При этом такая оптимизация выполняется достаточно быстро.
Диагностика
В отчёте Lighthouse есть разные показатели, которые указывают на потенциальные возможности по оптимизации изображений. Для поиска крупных изображений, нуждающихся в оптимизации, можно воспользоваться и обычными инструментами разработчика браузера. Такие изображения вполне могут стать хорошими кандидатами на оптимизацию.
Вот список показателей отчёта LightHouse, на которые стоит обратить внимание, исследуя возможность оптимизации изображений:
Решение проблем
Сначала поговорим о том, что стоит предпринять в том случае, если у вас мало времени.
В такой ситуации стоит обратить внимание на большие изображения, и на изображения, которые загружаются чаще других. Обнаружив их, их надо подвергнуть ручной оптимизации, воспользовавшись инструментом наподобие Squoosh. Хорошими кандидатами на оптимизацию обычно являются большие фотографии. Например, взятые с ресурса вроде Hero Images.
Вот на что надо обращать внимание, оптимизируя изображения:
Если изображения составляют значительную долю материалов сайта — рассмотрите возможность использования для их обслуживания специализированного CDN-сервиса, рассчитанного на работу с изображениями. Такие сервисы позволяют снять нагрузку по работе с изображениями с основного сервера. Настройка проекта на использование подобного CDN-сервиса проста, но она требует обновления существующих ссылок на изображения таким образом, чтобы они указывали бы на CDN-ресурсы. Вот материал, посвящённый использованию специализированных CDN-сервисов, рассчитанных на изображения.
▍Минификация JavaScript- и CSS-кода
Минификация кода позволяет уменьшать его размер, удаляя ненужные символы.
Диагностика
Взгляните на показатели Minify CSS и Minify JavaScript отчёта Lighthouse для того чтобы выявить ресурсы, нуждающиеся в минификации.
Решение проблем
Если у вас мало времени — сосредоточьтесь на минификации JavaScript-кода. На большинстве сайтов объём JavaScript-кода превышает объём CSS-кода, поэтому такой ход даст лучшие результаты. Вот материал о минификации JavaScript, а вот — о минификации CSS.
4. Мониторинг сервера
Инструменты для мониторинга серверов поддерживают сбор данных и их визуализацию с использованием панелей управления. Они умеют оповещать пользователей о различных событиях, имеющих отношение к производительности серверов. Использование таких инструментов может помочь в предотвращении и смягчении проблем с производительностью серверов.
Настраивая систему мониторинга, стоит стремиться к как можно большей простоте. Сбор чрезмерного количества данных и слишком частые уведомления способны вызывать негативные эффекты. Чем шире диапазон собираемых данных и чем чаще осуществляется их сбор — тем дороже будет обходиться их сбор и хранение. А если того, кто отвечает за состояние сервера, будут заваливать сообщениями о незначительных событиях, то он, в итоге, будет эти сообщения игнорировать.
В уведомлениях должны содержаться метрики, которые последовательно и точно описывают проблемы. Например, время ответа сервера (latency) — это метрика, которая особенно хорошо для этого подходит: она позволяет выявить большое количество проблемных ситуаций и напрямую связана с тем, как сервер воспринимается пользователями. Уведомления, основанные на низкоуровневых метриках, вроде уровня использования процессора, могут играть роль полезного дополнения, но они способны указать лишь на небольшую часть возможных проблем. Кроме того, уведомления должны быть основаны не на средних показателях, а на показателях, соответствующих 95-99 перцентилям. В противном случае анализ средних значений может легко привести к пропуску проблем, которые не затрагивают всех пользователей.
Настройка мониторинга
Все основные облачные провайдеры предоставляют клиентам собственные инструменты мониторинга (GCP, AWS, Azure). Кроме того, тут можно отметить инструмент Netdata — отличную бесплатную опенсорсную альтернативу инструментам провайдеров. Вне зависимости от того, чем именно вы пользуетесь, вам понадобится установить на каждый сервер, который нужно мониторить, приложение-агент. После завершения настройки системы не забудьте настроить уведомления. Вот инструкции по настройке разных средств мониторинга:
Итоги
Сегодня мы поговорили о том, как выявлять и исправлять проблемы с производительностью серверов. Хочется верить, что ваши серверы будут работать стабильно и вам советы из этого материала не пригодятся. А если что-то пойдёт не так — надеемся, тут вы нашли что-то такое, что поможет вам как можно быстрее справиться с проблемой.
Уважаемые читатели! Что вы делаете в ситуации, когда сервер, на котором работает ваш проект, начинает «тормозить»?
Как понять почему упал сервер не подключая к нему монитор и клавиатуру?
Так бывает что сервер зависает, но к нему не подключена ни клавиатура, ни монитор.
У меня нет лишнего монитора, и обнаружив, что сервер не отвечает по сети,
снимать монитор с моего компьютера и подключать к серверу в кладовке нет никакого желания и сил.
В Linux есть такая возможность ядра как Netconsole.
Netconsole позволяет послать сообщения от ядра на удаленный компьютер.
Для настройки netconsole нужен другой (постоянно включенный) компьютер который примет сообщение по сети.
Проверено на Ubuntu 10.04
На сервере который отлаживаем выполняем:
1. В /etc/modules добавляем netconsole
2. В /etc/modprobe.d/netconsole.conf пишем
options netconsole netconsole=SRCPORT@SRCHOST/eth0,DSTPORT@DSTHOST/DSTMAC
Где SRCPORT и SRCHOST соответственно порт и IP адрес сервера который отлаживаем.
А DSTPORT и DSTHOST порт и IP адрес сервера который будет принимать сообщения.
DSTMAC — это MAC адрес сервера который будет принимать сообщения ЕСЛИ он в той же сети. Если он за роутером или где нибудь в интернете, то нужно указывать MAC адрес ближайшего роутера (Gateway).
Должно получится чтото типа
options netconsole netconsole=6666@192.168.1.2/eth0,6666@192.168.1.3/e0:91:f5:7d:e6:38
На сервере который будет принимать сообщения.
Нам нужно как то запустить программу которая будет слушать UDP порт DSTPORT и куда-либо записывать сообшения.
Самый просто способ — запустить netcat который будет выдавать на экран все что приходит на порт. Для того чтобы после закрытия окна данная программа не прекратила работать, можно запустить ее в screen.
Как понять что все работает?
Можно подождать какого нибудь события, но как убедится что сообщения реально ходят? Можно активировать SysRQ механизм ядра.
echo 1 > /proc/sys/kernel/sysrq
echo h > /proc/sysrq-trigger
После этого на сервере который принимает сообщения в окне с netcat появится текст типа
[ 7849.700372] SysRq : HELP : loglevel(0-9).
Мир был на грани краха: интернет показал свою уязвимость
Если, как Facebook, обрушатся Google, Amazon, Cloudflare, Microsoft и еще четыре-пять сервисов, случится коллапс мировой экономики, считают эксперты.
Вчера, по данным Downdetector, с массовыми сбоями столкнулись десятки соцсетей, мессенджеров и интернет-сервисов. В их числе Facebook, Instagram, WhatsApp, Telegram, Twitter, ВКонтакте, TikTok, Gmail, Bank of America, YouTube, Netflix, Snapchat, Tinder, Viber, Zoom, Southwest Airlines. Что произошло и может ли глобальный сбой повториться, «Росбалт» спросил экспертов.
Ведущий аналитик Российской ассоциации электронных коммуникаций (РАЭК) Карен Казарян:
© Facebook К.Казаряна
«Есть такой сетевой протокол — BGP. Это один из старейших протоколов. Наряду со всей системой DNS он составляет основу функционирования Сети. Он был создан, когда Интернет был другим. Когда сетей, которые он объединял, были десятки, а не десятки тысяч. Он предполагал несколько интимные знания работы Сети как таковой. Что он делает? Когда сети физически объединяются между собой, у них на границе есть, грубо говоря, роутер, который одну сеть связывает с другой. Протокол BGP объясняет этим пограничным роутерам, что в одной сети, что в другой, и как сигнал должен пройти между ними.
Что случилось вчера с Facebook? Поскольку это гигантская компания, фактически сам себе провайдер, пограничные роутеры у нее собственные. Вчера Facebook их обновлял, и что-то пошло не так. В результате, фактически вся подсеть Facebook исчезла из Интернета. Ее пограничные роутеры перестали получать маршруты, передали другим пограничным роутерам, что этих маршрутов больше нет, и дальше по цепочке. За короткое время все основные сетки мира перестали видеть подсеть Facebook в принципе.
Сбой в работе Facebook повлек за собой непредвиденные последствия. Сервисы и приложения компаний, которые были завязаны на авторизацию через Facebook или их DNS-резолверы, тоже перестали работать. Поскольку Facebook и его CDN-сети — большой магнит трафика, в результате сбоя резко выросла нагрузка на другие сети, и не все эту нагрузку выдержали. Получается, сбой в системах Facebook срикошетил на другие компании. Через шесть часов сотрудники Facebook, как говорят, смогли физически попасть в Центры обработки данных, обновить роутеры и начать их поднимать, и постепенно все снова заработало.
Хочу напомнить, что в 2006 году Пакистан хотел заблокировать YouTube у себя в стране. Тогда в правительстве как раз решили перенастроить пограничные роутеры основных своих телеком-операторов так, чтобы они просто прекратили принимать маршруты YouTube. А получилось, что он перестал работать во всем мире, потому что пограничные роутеры начали отдавать измененный маршрут по цепочке, и сбой стал глобальным. К подобным коллапсам мирового масштаба могут привести самые непредвиденные решения и обстоятельства, и прогнозировать их довольно сложно. Важно понимать: когда кто-то начинает делать что-то не то, эффект получается неожиданным для всех участвующих сторон».
Один из ведущих российских экспертов в области открытых данных, директор АНО «Инфокультура» Иван Бегтин:
© Фото из личного архива И. Бегтина
«Проблема возникла из-за того, что администраторы Facebook оказались криворукими и ошиблись в настройках подсети, которая относится к их серверам имен. Это DNS-сервера, благодаря которым, когда вы набираете facebook.com, ваш компьютер понимает, что надо обратиться именно к этому серверу, сопоставляет название домена с набором IP-адресов, за которыми он находится. Сервера, которые за это отвечают, оказались в этой подсети. Ее фактически исключили из обмена трафиком с Интернетом, и все те домены, которые были завязаны на эти DNS-сервера, Instagram, Facebook, WhatsApp и куча другой инфраструктуры, вышли из строя. Причем, это произошло в довольно короткие сроки. Проблема усугубилась тем, что из-за пандемии сократился штат инженеров, находящихся в Центрах обработки данных. В результате, специалисты Facebook не могли попасть в этот ЦОД несколько часов. У компании нашлась точка сбоя. Она сработала на 100%, и усугубилась пандемией. В итоге, восстановление работы заняло несколько часов.
Почему полетели все остальные сервисы? Facebook многие использовали как мессенджер, когда он «лег», люди стали переходить в Telegram, ВКонтакте и другие сервисы, на них одномоментно резко выросла нагрузка, и не все из них выдержали. Кроме того, огромное количество сервисов в Интернете так или иначе завязаны на серверы Facebook. Когда они не могут к ним обратиться, пользовательские устройства начинают долбиться и постоянно запрашивать информацию. Поэтому многие приложения и сайты, которые использовали авторизацию через Facebook, тоже стали сбоить. Основная причина в этом. Возможно, какие-то еще события совпали и наложились на эту историю. Возможно, проблема с подсетью оказалась более комплексной и могла затронуть что-то еще.
Мне кажется, даже если бы Facebook не работал месяц, никто кроме рекламодателей серьезно не пострадал бы, потому что слишком много альтернатив. Большинство людей держат обычно пять-шесть мессенджеров в телефоне. Так что случившееся вчера — еще не глобальная катастрофа. Но у нас есть Google, Amazon, Cloudflare, Microsoft и еще четыре-пять сервисов, кроме перечисленных, падение которых реально затронет весь мир. Всех, включая тех, кто играет в импортозамещение в российских госорганах. Если бы то же самое произошло с Google, и он оказался недоступен на несколько часов, это почувствовали бы все моментально. Аналогичное случилось бы при сбое в Microsoft. На них завязано очень много внутренней инфраструктуры большинства сервисов. Вчера, считайте, прошли интернет-учения, настоящие, а не те, что у нас устраивает Роскомнадзор. И они показали, что Facebook-зависимость не такая уж серьезная».
Контент-директор Gem4me Светлана Карачарова:
© Фото из личного архива С. Карачаровой
Глобальный сбой в работе Facebook, Instagram и WhatsApp продолжался более 5 часов, DNS Facebook заработал
По данным DownDetector, а также по многочисленным публикациям пользователей в Twitter, Telegram и других социальных платформах уже более пяти часов (с 18.13 мск) жалуются на недоступность Facebook, Instagram и WhatsApp по всему миру.
Представители проблемных социальных сервисов заявили в Twitter, что они занимаются устранением сбоя. Однако, оперативно его решить не удалось. Оказалось, что для этого нужно физическое присутствие подготовленных к устранению проблемы на маршрутизаторах сетевых инженеров в дата-центре Facebook. В это же время стало известно, что внутренняя сеть компании также стала недоступна, включая корпоративные сегменты, сервера DNS, сервисы и инструменты. Из-за этого специалисты не могут проникнуть внутрь периметра дата-центра — у них не срабатывают пропуски.
Предварительная причина инцидента — удаленное обновление конфигурации маршрутизаторов внутри сети компании, отвечающих за BGP-сессии и их анонсы, а также автономную систему Facebook, пошло не по плану. После этого перестали быть доступны NS-сервера компании и пропали DNS-записи. Список префиксов FB, с которыми пропала глобальная связность: IPv4, IPv6.
Журналисты Брайан Кребс и специалисты из Geek Factor 5 уточнили, что BGP-маршруты, обслуживающие авторитативный DNS-сервер Facebook, были специально отозваны по неизвестной причине, что сделало все домены Facebook недоступными никому.
Технический директор Cloudflare Джон Грэм-Камминг согласился, что после того, как Facebook восстановит свою сеть, то он ожидает длительного периода нестабильности в ее работе. По его пояснению, перезагрузить распределенную систему такого размера сложно, тем более, что компании придется использовать холодные кеши и системы, которым нужны другие системы для начальной загрузки.
В администрации США заявили, что отслеживают ситуацию. «Мы осведомлены о проблеме и следим за ней», — заявила пресс-секретарь Белого дома Джен Псаки в ходе встречи со СМИ.
Российский интернет-омбудсмен Дмитрий Мариничев пояснил «Интерфакс», что сбои в работе Facebook, Instagram и WhatsApp будут устранены менее чем через сутки, а работа сервисов может стабилизироваться уже этой ночью.
[обновление публикации]
Через 6 часов после аварии Cloudflare зафиксировала признаки повышенной активности анонсов BGP со стороны Facebook. Это может быть сигналом того, что они скоро вернутся в сеть. Также технические специалисты Cloudflare рассказали, как со стороны компании выглядел сбой в Facebook и почему это произошло. Также DNS-сервера Facebook начали подниматься.
Появилась заглушка на странице Facebook, правда прошлогодняя.
По информации The Guardian, сегодняшний сбой в работе Facebook стал самым серьезным инцидентом с 13 марта 2019 года, когда пользователи по всему миру более 24 часов не могли пользоваться Facebook, Instagram и WhatsApp.
Павел Дуров не остался в стороне инцидента и устроил опрос в Telegram.