Гуру кеш как связаться с оператором
Обновлено: 02.07.2024
Язык VCL – это небольшой предметно-ориентированный язык, предназначенный для определения политик обработки запросов и кэширования документов для Varnish Cache.
Когда загружается новая конфигурация, процесс управления лаком переводит код VCL на язык C и компилирует его в общий объект, который затем динамически связывается с серверным процессом.
СИНТАКСИС¶
Синтаксис VCL очень прост и намеренно похож на C и Perl. Блоки разделяются фигурными скобками, операторы заканчиваются точкой с запятой, а комментарии могут быть написаны как на C, C++ или Perl в соответствии с вашими предпочтениями.
Помимо C-подобных операторов присваивания (=), сравнения (==, !=) и логических (!, && и ||) операторов, VCL поддерживает как регулярное выражение, так и сопоставление ACL с использованием ~ и !~ операторы.
Основные строки заключаются в " . " и не могут содержать символы новой строки.
Длинные строки заключены в . Они могут содержать любые символы, включая ", перевод строки и другие управляющие символы, кроме символа NUL (0x00).
В отличие от C и Perl, символ обратной косой черты () не имеет специального значения в строках в VCL, поэтому его можно свободно использовать в регулярных выражениях без дублирования.
Строки объединяются с помощью оператора "+".
Назначения вводятся с помощью ключевого слова set. Пользовательские переменные отсутствуют; значения могут быть присвоены только переменным, прикрепленным к объектам бэкэнда, запроса или документа. Большинство из них являются типизированными, и присваиваемые им значения должны иметь совместимый суффикс единиц измерения.
Вы можете использовать ключевое слово rollback, чтобы отменить любые изменения в req в любое время.
Ключевое слово synthetic используется для создания синтетического тела ответа в vcl_error. В качестве аргумента принимает одну строку.
Вы можете вызвать сбой клиентского процесса с помощью ключевого слова panic. panic принимает строку в качестве аргумента.
Ключевое слово return(action) завершает подпрограмму. действие может быть, в зависимости от контекста, одним из
Пожалуйста, просмотрите список подпрограмм, чтобы узнать, какие действия возврата доступны и где.
В VCL есть проверки if, но нет циклов.
Содержимое другого файла VCL можно вставить в любой момент кода, используя ключевое слово include, за которым следует имя другого файла в виде строки в кавычках.
Бэкенд-объявления¶
Объявление серверной части создает и инициализирует именованный внутренний объект:
Впоследствии объект бэкенда можно использовать для выбора бэкэнда во время запроса:
Чтобы избежать перегрузки внутренних серверов, в параметре .max_connections можно задать ограничение максимального количества одновременных внутренних подключений.
Параметры тайм-аута можно переопределить в объявлении серверной части. Параметры тайм-аута: .connect_timeout для времени ожидания соединения с серверной частью, .first_byte_timeout для времени ожидания первого байта от серверной части и .between_bytes_timeout для времени ожидания между каждым полученным байтом.
Они могут быть установлены в объявлении следующим образом:
Чтобы пометить серверную часть как неработоспособную после того, как в ее список SaintMode было добавлено определенное количество элементов, .saintmode_threshold можно установить на максимальный размер списка. Установка значения 0 полностью отключает проверку режима святого для этого бэкэнда. Значение в объявлении серверной части переопределяет параметр.
Директора¶
Директор – это логическая группа внутренних серверов, сгруппированных вместе для обеспечения избыточности. Основная роль директора состоит в том, чтобы позволить Varnish выбрать внутренний сервер из нескольких, чтобы, если один вышел из строя, можно было использовать другой.
Существует несколько типов директоров. Разные типы режиссеров используют разные алгоритмы для выбора используемой серверной части.
Настройка директора может выглядеть следующим образом:
Семейство случайных директоров¶
Есть три директора, использующих одинаковую логику: случайный директор, клиентский директор и хэш-директор. Каждый из них распределяет трафик между назначенными ему бэкэндами, используя случайное распределение, задаваемое либо идентификатором клиента, либо случайным числом, либо хэшем кеша (обычно URL-адресом). За пределами начального семени они действуют одинаково.
Для каждого бэкенда требуется параметр .weight, который устанавливает объем трафика, который будет получать каждый бэкэнд по сравнению с другими. Равный вес означает равный трафик. Серверная часть с меньшим весом, чем другая, получит пропорционально меньше трафика.
Директор имеет необязательный параметр .retries, который по умолчанию указывает количество бэкендов, которые есть у директора. Директор попытается найти исправную серверную часть .retries раз, если первая попытка не удалась. Каждая попытка повторно использует предыдущее начальное число итеративно. Для случайного директора эта деталь не имеет значения, так как каждый раз будет давать разные результаты. Для хеш-директора и клиента это означает, что один и тот же URL-адрес или один и тот же клиент будут постоянно возвращаться к одному и тому же серверу.
Случайный директор¶
При этом используется случайное число для заполнения выборки серверной части.
Директор по работе с клиентами¶
Директор по работе с клиентами выбирает серверную часть на основе личности клиентов. Вы можете установить переменную VCL client.identity, чтобы идентифицировать клиента, получая значение файла cookie сеанса или аналогичного.
Хэш-директор¶
Режиссер хеширования выберет серверную часть на основе хеш-значения URL.
Это полезно, если вы используете Varnish для балансировки нагрузки перед другими кэшами Varnish или другими веб-ускорителями, поскольку объекты не будут дублироваться в кэшах.
Он будет использовать значение req.hash, как и обычные методы поиска в кэше.
Круговой директор¶
Руководитель циклического перебора не принимает никаких вариантов.
Он будет использовать первую серверную часть для первого запроса, вторую серверную часть для второго запроса и т. д. и снова начнет сначала, когда дойдет до конца.
Если бэкенд неисправен или Varnish не может подключиться, он будет пропущен. Директор циклического перебора попробует все серверные части один раз, прежде чем сдаться.
Директор DNS¶
Директор DNS может использовать серверные части двумя разными способами. Либо как случайный или циклический директор, либо с использованием .list:
Это укажет 384 бэкенда, все используют порт 80 и время ожидания соединения 0,4 с. Параметры должны стоять перед списком IP-адресов в операторе .list. Метод .list не поддерживает IPv6. Это не белый список, это фактический список бэкендов, которые будут созданы внутри Varnish — чем больше подсеть, тем больше накладных расходов.
Файл .ttl определяет продолжительность поиска DNS в кэше.
Приведенный выше пример добавит "internal.example.net" к входящему заголовку хоста, предоставленному клиентом, перед его поиском. Все настройки являются необязательными.
Проверки работоспособности не полностью поддерживаются.
Поддерживается циклическая балансировка DNS. Если имя хоста разрешается в несколько бэкэндов, директор будет делить трафик между ними по кругу.
Запасной директор¶
Запасной директор выберет первый исправный сервер. Он рассматривает их в том порядке, в котором они перечислены в его определении.
Запасной директор не принимает никаких вариантов.
Пример резервного режиссера:
Внутренние проверки¶
Можно проверить серверные части, чтобы определить, следует ли считать их работоспособными. Статус возврата также можно проверить с помощью req.backend.healthy.
Зонды принимают следующие параметры:
Бэкенд с зондом можно определить следующим образом вместе с бэкендом или директором:
Или его можно определить отдельно, а затем сослаться на него:
Если у вас много бэкендов, это может значительно упростить настройку.
Объявление ACL создает и инициализирует именованный список управления доступом, который впоследствии можно использовать для сопоставления адресов клиентов:
Если в записи ACL указано имя хоста, которое Varnish не может разрешить, оно будет соответствовать любому адресу, с которым сравнивается. Следовательно, если ему предшествует знак отрицания, он отклонит любой адрес, с которым он сравнивается, что может быть не тем, что вы намеревались. Однако если запись заключена в круглые скобки, она просто будет проигнорирована.
Чтобы сопоставить IP-адрес с ACL, просто используйте оператор сопоставления:
Регулярные выражения¶
Varnish использует PCRE — Perl-совместимые регулярные выражения. Полное описание PCRE см. на справочной странице pcre(3).
Чтобы отправить флаги механизму PCRE, например, чтобы включить нечувствительность к регистру, добавьте флаг в круглых скобках после вопросительного знака, например:
Функции¶
Доступны следующие встроенные функции:
hash_data(str) Добавляет строку к хэш-входу. В default.vcl hash_data() вызывается для хоста и URL-адреса запроса. regsub(str, regex, sub) Возвращает копию str с заменой первого вхождения регулярного выражения регулярного выражения на sub. Внутри подгруппы \0 (которое также может быть записано как \&) заменяется всей совпадающей строкой, а \n заменяется содержимым подгруппы n в совпадающей строке. regsuball(str, regex, sub) То же, что и regsuball(), но заменяет все вхождения. ban(выражение запрета) Запрещает все объекты в кеше, которые соответствуют выражению. ban_url(regex) Запрещает в кэше все объекты, URL-адреса которых соответствуют регулярному выражению.
Подпрограммы¶
Подпрограмма используется для группировки кода для удобства чтения или повторного использования:
Подпрограммы в VCL не принимают аргументов и не возвращают значения.
Чтобы вызвать подпрограмму, используйте ключевое слово call, за которым следует имя подпрограммы:
Вызывается при загрузке VCL до прохождения через него каких-либо запросов. Обычно используется для инициализации VMOD.
ok Нормальный возврат, VCL продолжает загрузку. vcl_recv
Вызывается в начале запроса, после того как весь запрос получен и проанализирован. Его цель — решить, обслуживать ли запрос, как это сделать и, если применимо, какой сервер использовать.
Подпрограмма vcl_recv может завершиться вызовом return() для одного из следующих ключевых слов:
код ошибки [причина] Вернуть указанный код ошибки клиенту и отказаться от запроса. pass Переключиться в режим пропуска. В конечном итоге управление перейдет к vcl_pass. pipe Переключиться в режим трубы. В конечном итоге управление перейдет к vcl_pipe. lookup Поиск запрошенного объекта в кэше. В конечном итоге управление перейдет к vcl_hit или vcl_miss, в зависимости от того, находится ли объект в кеше. Значение bereq.request будет равно GET независимо от значения req.request . vcl_pipe
Вызывается при входе в конвейерный режим. В этом режиме запрос передается серверной части, а любые дальнейшие данные от клиента или серверной части передаются без изменений до тех пор, пока одна из сторон не закроет соединение.
Подпрограмма vcl_pipe может завершиться вызовом return() с одним из следующих ключевых слов:
код ошибки [причина] Вернуть указанный код ошибки клиенту и отказаться от запроса. pipe Перейти к режиму pipe. vcl_pass
Вызывается при входе в режим пропуска. В этом режиме запрос передается бэкенду, а ответ бэкенда передается клиенту, но не заносится в кеш. Последующие запросы, отправленные по тому же клиентскому соединению, обрабатываются обычным образом.
Подпрограмма vcl_pass может завершиться вызовом return() с одним из следующих ключевых слов:
код ошибки [причина] Вернуть указанный код ошибки клиенту и отказаться от запроса. pass Перейти в режим пропуска. vcl_hash
Вы можете вызвать функцию hash_data() для данных, которые хотите добавить в хэш.
Подпрограмма vcl_hash может завершиться вызовом return() с одним из следующих ключевых слов:
Продолжить. vcl_hit
Вызывается после поиска в кеше, если запрошенный документ был найден в кеше.
Подпрограмма vcl_hit может завершиться вызовом return() с одним из следующих ключевых слов:
deliver Доставить кэшированный объект клиенту. В конечном итоге управление перейдет к vcl_deliver. код ошибки [причина] Возвращает указанный код ошибки клиенту и отказывается от запроса. pass Переключиться в режим пропуска. В конечном итоге управление перейдет к vcl_pass. перезапустить Перезапустить транзакцию. Увеличивает счетчик перезапуска. Если количество перезапусков превышает max_restarts, лак выдает ошибку медитации гуру. vcl_miss
Вызывается после поиска в кеше, если запрошенный документ не был найден в кеше. Его цель — решить, следует ли пытаться получить документ из серверной части и какой сервер использовать.
Подпрограмма vcl_miss может завершиться вызовом return() с одним из следующих ключевых слов:
код ошибки [причина] Вернуть указанный код ошибки клиенту и отказаться от запроса. pass Переключиться в режим пропуска. В конечном итоге управление перейдет к vcl_pass. fetch Получить запрошенный объект из бэкенда. В конечном итоге управление перейдет к vcl_fetch. vcl_fetch
Вызывается после успешного извлечения документа из серверной части.
Подпрограмма vcl_fetch может завершиться вызовом return() с одним из следующих ключевых слов:
доставить Возможно вставить объект в кеш, а затем доставить его клиенту. В конечном итоге управление перейдет к vcl_deliver. код ошибки [причина] Возвращает указанный код ошибки клиенту и отказывается от запроса. hit_for_pass Пройти в выборке. Это создаст объект hit_for_pass. Обратите внимание, что значение TTL для объекта hit_for_pass будет равно текущему значению beresp.ttl. Управление будет передано vcl_deliver в текущем запросе, но последующие запросы будут направляться непосредственно vcl_pass на основе объекта hit_for_pass. перезапустить Перезапустить транзакцию. Увеличивает счетчик перезапуска. Если количество перезапусков превышает max_restarts, лак выдает ошибку медитации гуру. vcl_deliver
Вызывается перед доставкой кэшированного объекта клиенту.
Подпрограмма vcl_deliver может завершаться одним из следующих ключевых слов:
доставить Доставить объект клиенту. перезапустить Перезапустить транзакцию. Увеличивает счетчик перезапуска. Если количество перезапусков превышает max_restarts, лак выдает ошибку медитации гуру. vcl_error
Вызывается, когда мы сталкиваемся с ошибкой, явным или неявным образом из-за серверных или внутренних ошибок.
Подпрограмма vcl_error может завершиться вызовом return с одним из следующих ключевых слов:
deliver Доставить объект ошибки клиенту. перезапустить Перезапустить транзакцию. Увеличивает счетчик перезапуска. Если количество перезапусков превышает max_restarts, лак выдает ошибку медитации гуру. vcl_fini
Вызывается, когда VCL отбрасывается только после того, как все запросы вышли из VCL. Обычно используется для очистки VMOD.
ok Обычный возврат, VCL будет удален.
Если одна из этих подпрограмм останется неопределенной или завершится без принятия решения об обработке, управление будет передано встроенной функции по умолчанию. Список кодов по умолчанию см. в разделе ПРИМЕРЫ.
Несколько подпрограмм¶
Если определено несколько подпрограмм с именем одной из встроенных, они объединяются в том порядке, в котором они появляются в исходном коде. Версии по умолчанию, распространяемые вместе с Varnish, будут неявно объединены в качестве последнего средства в конце.
Переменные¶
Хотя подпрограммы не принимают аргументов, необходимая информация предоставляется подпрограммам-обработчикам через глобальные переменные.
Всегда доступны следующие переменные:
сейчас Текущее время в секундах с начала эпохи. При использовании в строковом контексте возвращает отформатированную строку.
В внутренних объявлениях доступны следующие переменные:
.host Имя хоста или IP-адрес серверной части. .port Имя службы или номер порта серверной части.
При обработке запроса доступны следующие переменные:
Установите период, чтобы включить отсрочку.
Известное ограничение в версии 3.0: отключение отсрочки путем установки для req.grace или beresp.grace значения 0 с не дает желаемого эффекта, а скорее устанавливает для времени отсрочки значение default_grace. Чтобы отключить отсрочку для запроса, либо установите параметр default_grace = 0s, либо установите req.grace = 0,000001s в VCL.
req.xid Уникальный идентификатор этого запроса.
Следующие переменные доступны при подготовке внутреннего запроса (либо для промаха кеша, либо для режима прохода или конвейера):
Следующие переменные доступны после того, как запрошенный объект был извлечен из серверной части, прежде чем он будет введен в кеш. Другими словами, они доступны в vcl_fetch:
После того, как объект введен в кеш, доступны следующие (в основном только для чтения) переменные, когда объект находится в кеше, обычно в vcl_hit, или при построении искусственного ответа в vcl_error:
При определении хеш-ключа объекта доступны следующие переменные:
req.hash Ключ хеша, используемый для ссылки на объект в кэше. Используется как при чтении, так и при записи в кэш.
При подготовке ответа клиенту доступны следующие переменные:
Следующие переменные только для чтения сообщают о состоянии именованного стивидора хранилища. Не все стивидоры реализуют все переменные:
Значения могут быть присвоены переменным с помощью ключевого слова set:
Режим благодати и святого¶
Если серверу требуется много времени для создания объекта, существует риск накопления потоков. Чтобы предотвратить это, вы можете включить льготность. Это позволяет лаку обслуживать просроченную версию объекта, в то время как новый объект создается серверной частью.
Следующий код vcl заставит Varnish обслуживать просроченные объекты. Все объекты будут храниться до двух минут после истечения срока их действия или будет создан новый объект.
Режим Saint аналогичен льготному режиму и использует ту же инфраструктуру, но работает иначе. Вы можете добавить код VCL в vcl_fetch, чтобы узнать, понравился ли вам ответ, исходящий от серверной части. Если вы обнаружите, что ответ не подходит, вы можете установить для beresp.saintmode ограничение по времени и вызвать restart. После этого Varnish попытается снова получить объект с других бэкендов.
Если бэкендов больше нет или если вы нажали max_restarts и у нас есть объект моложе, чем то, что вы установили для beresp.saintmode, Varnish будет обслуживать объект, даже если он устарел.
ПРИМЕРЫ¶
Следующий код эквивалентен конфигурации по умолчанию с внутренним адресом, заданным как "backend.example.com", и без указания внутреннего порта:
В следующем примере показано, как поддерживать несколько сайтов, работающих на разных бэкендах в одном и том же экземпляре Varnish, путем выбора бэкэндов на основе URL-адреса запроса:
В следующем фрагменте показано, как установить минимальное значение TTL для всех документов. Обратите внимание, что это не то же самое, что установка параметра времени выполнения default_ttl, так как это влияет только на документ, для которого серверная часть не указала TTL:
СМОТРИ ТАКЖЕ¶
ИСТОРИЯ¶
VCL был разработан Poul-Henning Kamp в сотрудничестве с Verdens Gang AS, Redpill Linpro и Varnish Software. Эта страница руководства была написана Даг-Эрлингом Смёргравом, а затем отредактирована Полом-Хеннингом Кампом и Пером Буэром.
АВТОРСКИЕ ПРАВА¶
Этот документ находится под той же лицензией, что и сам Varnish. Подробнее см. в ЛИЦЕНЗИИ.
Если вы используете Varnish Cache на своем веб-сайте или посещаете веб-сайт, который кэширует контент с помощью Varnish Cache, есть вероятность, что в какой-то момент вы столкнетесь с ошибкой сервера Varnish Cache: Ошибка 503 Служба недоступна / Медитация гуру с номером XID. Ошибка 503 означает, что запрашиваемый веб-сервер недоступен. Это может быть связано с тем, что он перегружен, отключен для обслуживания или не полностью функционирует по другой причине.
Если вы видите эту ошибку в отношении Varnish Cache, это означает, что веб-сайт использует Varnish Cache для кэширования и обслуживания контента, и этот Varnish Cache не может получить доступ к внутреннему серверу. Varnish Cache выдает ошибку Guru Meditation, когда время ожидания соединения истекло или сервер Varnish Cache сделал слишком много запросов к внутреннему серверу, не получив ответа. Вместо того, чтобы делать бесконечное количество запросов к неработоспособной серверной части, Varnish Cache выдает ошибку 503, чтобы сообщить посетителю (и владельцу веб-сайта), что менеджер веб-сайта, вероятно, уже работает над исправлением, и вам лучше повторить попытку позже. . Если вы являетесь менеджером или владельцем веб-сайта и не знаете, почему вы получаете этот ответ, прочитайте ниже, чтобы узнать.
Исправление ошибки сервера Varnish Cache
Итак, если ваш веб-сайт выдает ошибку 503 Guru Meditation через Varnish Cache, как ее исправить? Сначала вам нужно просмотреть журналы для всех ошибок 503 с помощью лакилога. Вы можете заставить лаклог регистрировать ошибки 503, используя следующую команду из Varnish Cache:
Если серверная часть работает, но ошибка 503 Varnish Cache по-прежнему возникает, значит, что-то не так с подключением вашего веб-сервера к Varnish Cache или с конфигурацией Varnish Cache.
Если ваша серверная часть отвечает, но Varnish Cache обслуживает 503, мы часто обнаруживаем, что это связано с тайм-аутами. Вы можете изменить или добавить .connect_timeout = Xs и .first_byte_timeout = Xs в разделе VCL по умолчанию для серверной части на длину тайм-аута, которая работает для вашего веб-сервера. Программное обеспечение Varnish Cache содержит дополнительную информацию о различных тайм-аутах, которые могут возникать в Varnish Cache. Еще один совет — отключить KeepAlive, чтобы неиспользуемые соединения были сброшены. Это будет выглядеть следующим образом:
Для получения дополнительной информации о Varnish Cache загрузите руководство Section Varnish Cache 101 или свяжитесь с нами, если вам нужна помощь в устранении неполадок при настройке Varnish Cache.
Примечание. Этот пост в блоге датирован 2017 годом. Некоторый контент может быть устаревшим, хотя и не обязательно. То же самое со ссылками и последующими комментариями от меня или других. Поправки приветствуются, в комментариях. И я могу пересмотреть содержание по мере необходимости.
Был ли у вас когда-нибудь веб-сайт, который "затемнялся" на вас? или обнаружили, что данная страница на сайте каким-то образом исчезла? Возможно, это временное явление (может быть даже сообщение «Мы не работаем», хотя сайт или сервер могут вообще не отвечать), а может быть, сбой страницы или сайта будет постоянным.
- кеш Google (по крайней мере, чтобы увидеть последнюю версию, которую Google мог кэшировать)
- интернет-архив, "путевая машина", которая часто позволяет просмотреть историю страницы или всего сайта на ГОДЫ назад, в том числе давно исчезнувшую.
- и еще пара вариантов
Чтобы узнать больше, читайте дальше, поскольку я делюсь советами (и подсказками) по использованию обоих инструментов.
Нет ГАРАНТИИ, что страница, которую вы ищете, будет у них, но я обнаружил, что примерно в 99 % случаев, когда я их использую (а я использую их часто, потому что часто добываю золото в старых сообщения в блогах или статьи, которые исчезли на многих сайтах, которые я посетил).
[Обновлено 9 июня различными способами, в основном незначительными, но с некоторыми дополнениями в обсуждении «путешествия по переулку памяти».)
Кэш Google (и кеш: ключевое слово)
Итак, во-первых, если интересующий вас контент проиндексирован Google, обратите внимание, что у вас будет два способа увидеть последнюю версию страницы в том виде, в котором она была проиндексирована (и это верно для многих поисковых систем, таких как Bing и т. д.).
Доступная ссылка в поиске Google
Во-первых, при поиске контента Google всегда показывает заголовок страницы в виде ссылки, а под ней URL-адрес страницы. Справа от этого URL-адреса вы, возможно, никогда не замечали, но есть небольшой треугольник, указывающий вниз, который, если вы щелкнете по нему, обычно предложит «кэшированный» в качестве опции. См. пример ниже, где я сделал снимок экрана после нажатия на него:
< бр />
И если вы выберете эту опцию "кешировать", страница будет отображаться так, как она выглядела, когда Google в последний раз посещал сайт (чтобы захватить его содержимое и сохранить в своей базе данных). Часто это будет именно то, что вы искали, даже если «настоящая» страница не работает.
- иногда изображения в кэшированной форме страницы будут повреждены.причин может быть много, но ничего с этим не поделаешь
- возможно, что к тому времени, когда Google снова посетит сайт, он увидит новый контент, который заменит то, что БЫЛО там раньше (то, что вы искали), так что вы, возможно, не сможете увидеть контент, который вы надеялись найти.
- связано с вышеизложенным, конечно, если вы ищете страницу, которая, как вы знаете, когда-то существовала, и вы используете некоторые ключевые слова, которые, как вы ЗНАЛИ, были на этой странице в прошлом, но Google не находит ее, это возможно, Google НАШЕЛ новое содержание на странице и больше не считает, что оно должно быть найдено на основе ключевых слов, которые вы использовали для поиска.
Ключевое слово Google "cache:"
Прежде чем перейти к этому, я хотел бы поделиться еще одним советом, касающимся использования кеша Google для поиска предыдущих версий некоторых страниц. Знаете ли вы, что существует ключевое слово «cache:», которое вы можете использовать для поиска любой кэшированной версии данного URL-адреса? Конечно, это полезно только в том случае, если вы ЗНАЕТЕ URL-адрес страницы и просто хотите найти ее кэшированную версию.
Но это имеет значение. Подумайте, если сайт, который вы пытаетесь посетить, просто *временно* недоступен? Вы можете перейти по ссылке на него и получить ошибку о том, что страница недоступна. Но у вас есть URL-адрес в вашем браузере (или вы можете получить его по ссылке, по которой вы щелкнули). В этом случае просто используйте ключевое слово Google cache: перед URL-адресом, чтобы узнать, может ли Google показать вам то, что ИТ-отдел считал последней хорошей версией страницы. Так, например, с той страницей, которую я предложил выше, я мог получить кешированную версию, используя:
Опять же, для ясности: я говорю, что вы должны использовать ЭТО в качестве критерия поиска в Google. Но есть несколько советов, которые помогут сделать это проще.
Обновление: Adobe наконец-то воссоздала свой блог на новом портале CF, и URL-адреса, подобные приведенным выше, теперь перенаправляют на соответствующий правильный URL-адрес на портале, например, этот новый URL-адрес для этого. Тем не менее, то, что я предлагаю в этом посте, может по-прежнему приносить пользу людям, получающим доступ к другим URL-адресам, которые «темнеют» на них.
Советы по кэшу Google: ключевое слово
Также полезно то, что большинство современных браузеров позволяют выполнять поиск непосредственно с панели инструментов URL (поле, в котором вы вводите URL-адреса), поэтому вам не нужно посещать сайт Google или даже использовать окно поиска Google, предоставленное браузером. Таким образом, вы не только можете просто ввести свои ключевые слова для поиска там, где вводите свои URL-адреса, вы часто можете обнаружить, что, когда вы получаете такую неудачную страницу (для введенного вами URL-адреса, который вы знаете или предполагаете, является действительным URL-адресом), снова вы можно просто добавить ключевое слово «cache:» перед ним, нажать Enter и бац, вы перейдете к кешированной версии с помощью выбранной вами поисковой системы (если она существует).
(И да, вы можете изменить поисковую систему, используемую по умолчанию в браузере, но это выходит за рамки данной статьи.)
Я также добавлю, что многие браузеры предлагают подключаемые модули для более легкого доступа к странице, кэшированной в поисковой системе, благодаря чему во время просмотра какой-либо страницы вы можете просто щелкнуть правой кнопкой мыши содержимое страницы или нажать какую-либо кнопку, и плагин автоматически перенесет вас на кешированную версию страницы.
Интернет-архив (archive.org) "wayback machine"
Наконец, хотя кеш Google (или кеш вашей любимой поисковой системы) — это круто, проблема заключается в том, что почти во всех случаях вы можете просмотреть только одну предыдущую версию. Итак, опять же, если сайт сильно изменился или исчез навсегда, вскоре Google (и другие поисковые системы) перестанут находить страницу, или то, что они найдут, скоро не будет основано на содержании, которое БЫЛО там.
Просто вставьте свой URL-адрес в предложенное там поле, и вы увидите (если страница была заархивирована ими), что будет показана последняя заархивированная версия страницы. Что еще более важно, он также будет отображать календарный индикатор того, когда предыдущие версии страницы были заархивированы. Вы можете выбрать любую, чтобы просмотреть страницы того времени в прошлом, что очень здорово, когда работает.
Советы по обратному пути:
И обратите внимание, что в большинстве случаев вы можете щелкнуть ссылку на заархивированной странице, и вы попадете на архивную версию этой ссылки. Действительно, я использовал это как способ получить доступ к старым загружаемым файлам или носителям, поскольку даже такие двоичные файлы обычно архивируются.
И, конечно же, это работает для любой веб-страницы, а не только для доменного имени, так что вы можете использовать это, чтобы просмотреть прошлые версии этого блога:
Результат не всегда идеален, так как вы посещаете очень старые версии страницы. Со временем могут быть изменения в поддержке html браузерами или, возможно, другие аспекты старого сайта, которые не «выглядят хорошо», если смотреть сейчас, годы спустя. Но контент там есть, если он был заархивирован, что часто является «золотым в их холмах».
Отключение воспоминаний:
Чтобы развлечься и окунуться в воспоминания, посмотрите, как выглядел веб-сайт Google в 1998 году. Поговорим о старой школе. :-)
Но эй, мне нужно остерегаться горшка, называющего чайник черным. Вот одна из первых архивных версий моего сайта примерно 10-летней давности. Не так уж много изменилось, должен признать. кроме возраста этого лица на картинке. и, конечно же, сотни созданных с тех пор ресурсов, скрытых под всеми этими ссылками и кнопками. :-)
Или вот домен, которым я пользовался (это название компании я использовал с 1995 по 2003 год), и то, как он выглядел при первом кэшировании 19 лет назад. Фу. :-) Но вы можете видеть, что тогда я создавал контент для CF, включая ссылку слева «Советы по CF», которая была моей формой раннего блога (до того, как блоги стали чем-то особенным). И будьте терпеливы, когда вы нажимаете на ссылку для получения советов: поскольку я изменил URL-адреса тогда, по какой-то причине он перенаправляет на версию страницы, выпущенную позже в этом году (подробнее о еще худших потенциальных подводных камнях чуть позже).
Некоторые подводные камни:
Причина отсутствия сайта или страницы может быть связана с техническими или юридическими причинами. Или это может быть просто ошибка.
(Я разместил обсуждение/жалобу по этому поводу на их форуме в прошлом году, если вам интересна эта тема и вы хотите добавить свой голос.)
Итак, вы не всегда можете полагаться на обратную машину, чтобы получить страницу, которую вы ищете.
Еще другие варианты
Попробуйте их, если вы обнаружите, что что-то «исчезло» из веб-архива или кеша Google.
Что побудило вас написать этот пост?
Я собирался поделиться этой информацией в течение многих лет, так как обнаружил, что помогаю людям узнать об этом при устранении неполадок моего сервера CF. Я также мимоходом упомянул об этом в некоторых из моих прошлых сообщений в блоге, например, чтобы найти какую-то старую страницу или файл, который я хотел выделить.
Но некоторые читатели согласятся с тем, что я создал этот пост на этой неделе, особенно в связи с внезапным, неожиданным и длительным исчезновением около 2 недель назад блога команды ColdFusion, который в течение многих лет был отличным источником ( Совсем недавно я опубликовал пост о 100 самых интересных постах из блога команды CF за последние 3 года.)
Я решил НЕ открывать этот пост с таким упоминанием, так как искренне надеюсь, что это будет временная проблема и что вскоре мы снова сможем увидеть весь контент.
Но до тех пор, и если, к сожалению, контент каким-либо образом будет потерян, у нас будут средства, указанные выше, чтобы увидеть большую часть контента сайта, и, возможно, это поможет, если вы столкнетесь с подобной проблемой на другом сайте.
[Обновление от 9 июня: менеджер по продуктам CF Ракшит Нареш подтвердил в комментарии, что действительно исчезновение блога носит не только временный характер — как я действительно надеялся на это — но также и то, что «каждый пост» будет сохранен. Будем надеяться, что это относится и к комментариям, которые зачастую не менее ценны. Но если нет, опять же, у машины обратного пути они будут для всех, кому они нужны.]
Получите полный доступ к Начало работы с Varnish Cache и более 60 000 других игр с бесплатной 10-дневной пробной версией O'Reilly.
Есть также прямые онлайн-мероприятия, интерактивный контент, материалы для подготовки к сертификации и многое другое.
Как упоминалось ранее, Varnish — это прокси-сервер обратного кэширования. Есть много других обратных прокси, которые кэшируют даже в экосистеме с открытым исходным кодом. Основной причиной популярности Varnish, без сомнения, является язык конфигурации Varnish (VCL) — язык предметной области, используемый для управления поведением Varnish.
Гибкость, которую предлагает VCL, беспрецедентна для такого рода программного обеспечения. Это скорее вопрос выражения и управления поведением путем его программирования, а не объявления в файле конфигурации. Благодаря богатому API, доступному через объекты в VCL, уровень детализации, с которым вы можете настроить Varnish, не имеет себе равных.
Фигурные скобки, точки с запятой в конце операторов и стиль комментариев в VCL напоминают вам о таких языках программирования, как C, C++ и Perl. Возможно, поэтому VCL кажется таким интуитивно понятным; это определенно лучше, чем определение правил в XML-файле.
Язык конфигурации Varnish не просто похож на C, он на самом деле компилируется в C и динамически загружается как общий объект, когда файл VCL загружается средой выполнения Varnish. Мы даже можем назвать это транспилированием, поскольку мы преобразуем часть исходного кода в исходный код на другом языке программирования.
Если вам интересно, как выглядит код C, просто запустите программу lacted с параметром -C, чтобы увидеть результат.
В этой главе вы узнаете, как VCL позволит вам подключиться к конечному автомату Varnish, чтобы программно расширить его поведение. Мы рассмотрим различные подпрограммы, объекты и переменные, позволяющие расширить это поведение.
Я уже намекал на встроенный VCL в главе 3. В этой главе вы увидите фактический код встроенного VCL.
VCL — это не тот язык, где вы начинаете печатать в пустом файле или в основном методе; это на самом деле ограничивает вас и позволяет вам подключиться только к определенным аспектам потока исполнения Varnish. Этот поток выполнения определен в конечном автомате.
Крюки представляют определенные этапы потока Varnish. Поведение Varnish на этих этапах выражается с помощью различных встроенных подпрограмм. Вы определяете подпрограмму в файле VCL, расширяете поведение кэширования в этой подпрограмме и перезагружаете этот файл VCL, чтобы включить это поведение.
Каждая подпрограмма имеет фиксированный набор операторов возврата, которые представляют изменение состояния в потоке.
Предупреждение
Если вы не определите оператор return явно, Varnish будет использовать встроенный VCL, который жестко запрограммирован в системе. Это потенциально может отменить расширенное поведение, определенное вами в файле VCL.
Я действительно советую вам свести к минимуму использование пользовательского VCL и максимально полагаться на встроенный VCL.
Когда вы пишете VCL, вы тратите около 90 % своего времени на vcl_recv, 9 % на backend_response и оставшийся 1 % на различные другие подпрограммы.
Клиентские подпрограммы
Вот список клиентских подпрограмм:
Выполняется в начале каждого запроса.
Передайте запрос напрямую серверной части, не заботясь о кэшировании.
Передайте запрос непосредственно серверной части. Результат не сохраняется в кеше.
Вызывается при успешном поиске в кэше.
Вызывается, когда объект не найден в кеше.
Вызывается после vcl_recv для создания хеш-значения для запроса. Используется как ключ для поиска объекта в Varnish.
Вызывается, когда для объекта была выполнена очистка, и этот объект был успешно удален из кэша.
Выполняется в конце запроса, когда вывод возвращается клиенту.
Вернуть синтетический объект клиенту. Этот объект не был получен в результате выборки из серверной части, а был искусственно составлен в VCL.
Внутренние подпрограммы
А вот список внутренних подпрограмм:
Вызывается перед отправкой запроса на внутренний сервер.
Вызывается непосредственно после успешного получения ответа от внутреннего сервера.
Выполняется, когда выборка из серверной части не удалась или когда превышено максимальное количество повторных попыток.
Подпрограммы инициализации и очистки
И, наконец, есть две подпрограммы, которые используются для инициализации и очистки VMOD:
Вызывается при загрузке VCL. Здесь можно инициализировать VMOD.
Вызывается при выполнении VCL. VMOD можно очистить здесь.
Пользовательские подпрограммы
Вы также можете определить свои собственные подпрограммы и вызывать их из своего кода VCL. Пользовательские подпрограммы можно использовать для организации и модуляции кода VCL, в основном в попытке уменьшить дублирование кода.
Вот файл, содержащий пользовательскую подпрограмму:
Вот как вы называете эту подпрограмму:
В то время как подпрограммы VCL представляют различные состояния конечного автомата, оператор return в каждой подпрограмме позволяет изменять состояние.
Вот список допустимых операторов return:
Поиск объекта в кеше.
Передайте запрос серверной части, но не кэшируйте результат.
Передайте запрос серверной части и обойдите любую логику кэширования.
Удалить объект и его варианты из кеша. URL-адрес запроса будет использоваться в качестве идентификатора.
Передайте запрос серверной части и попытайтесь кэшировать ответ.
Перезапустите транзакцию и увеличивайте счетчик req.restarts, пока не будет достигнуто значение max_restarts.
Отправить ответ обратно клиенту.
Синхронно обновлять объект из серверной части, несмотря на обращение.
Используйте хэш для поиска объекта в кеше.
В главе 3 я говорил о встроенной VCL, а в предыдущем разделе я перечислил набор подпрограмм и операторов возврата. Пришло время собрать все кусочки головоломки вместе и составить поток выполнения Varnish.
В главе 1 я упоминал конечный автомат, который использует Varnish. Давайте посмотрим на это и посмотрим, как Varnish переходит между состояниями и что вызывает эти переходы.
На рис. 4-1 показана упрощенная блок-схема, поясняющая процесс выполнения.
Рисунок 4-1. Упрощенный поток выполнения в Varnish
Мы можем разделить поток на две части:
Выборка серверной части (серое поле)
Обработка запросов и ответов (остальная часть блок-схемы)
Целью разделения является асинхронная обработка серверных выборок.Делая это, Varnish может обслуживать устаревшие данные, пока извлекается новая версия кэшированного объекта. Это означает меньшее количество запросов в очереди, когда серверная часть работает медленно.
Теперь мы достигли точки, когда подпрограммы начинают обретать смысл. Подводя итог, повторим некоторые важные моменты потока выполнения:
Каждый сеанс начинается с vcl_recv .
Поиск кэша происходит в vcl_hash .
Некэшируемые запросы передаются серверу напрямую в vcl_pass . Ответы не кэшируются.
Элементы, найденные в кеше, обрабатываются vcl_hit .
элементы, которые не были найдены, обрабатываются vcl_miss .
Промахи кеша или пропущенные запросы извлекаются из серверной части через vcl_backend_fetch .
Ответы серверной части обрабатываются vcl_backend_response .
В случае сбоя выборки из бэкенда ошибка обрабатывается с помощью vcl_backend_error .
Действительные ответы, которые были кэшированы, переданы или пропущены, доставляются vcl_deliver .
Если вы хотите подключиться к потоку выполнения Varnish и расширить подпрограммы, вам лучше знать синтаксис. Что ж, давайте поговорим о синтаксисе.
Предупреждение
Varnish версии 4 отличается довольно значительным изменением синтаксиса VCL по сравнению с версией 3: каждый файл VCL должен начинаться с vcl 4.0; .
Многие примеры VCL в этой книге не начинаются с vcl 4.0; потому что я предполагаю, что это просто выдержки, а не полный файл VCL. Пожалуйста, имейте это в виду.
Полное справочное руководство по VCL можно найти на веб-сайте Varnish.
Операторы
В VCL есть множество операторов, которые можно использовать для присвоения, сравнения и сопоставления значений.
Вот пример, где мы объединяем некоторые операторы:
Мы используем оператор присваивания ( = ) для присвоения значений переменным или объектам.
Мы используем оператор сравнения ( == ) для сравнения значений. Он возвращает true, если оба значения равны; в противном случае возвращается false.
Мы используем оператор сопоставления ( ~ ) для выполнения сопоставления с регулярным выражением. Если значение соответствует регулярному выражению, возвращается true; в противном случае возвращается false.
Операция отрицания ( ! ) возвращает обратное логическое состояние.
В предыдущем примере мы проверяем:
Метод запроса равен PURGE или BAN .
Метод запроса не равен GET и HEAD .
URL-адрес запроса соответствует регулярному выражению, которое ищет URL-адреса продуктов.
Есть также оператор "меньше" (<), оператор "больше" (>) и оператор "меньше или равно" (=). Перейдите в раздел оператора на сайте документации Varnish, чтобы узнать больше.
Условные выражения
операторы if и else — вы, вероятно, знаете, что они делают. Опустим теорию и перейдем к примеру:
В основном VCL поддерживает if , else и elseif . Вот и все!
Комментарии
Комментарии — это части VCL, которые не интерпретируются, а используются для добавления комментариев, описывающих ваш VCL.
VCL предлагает три способа добавления комментариев в VCL:
Однострочные комментарии с двойной косой чертой //
Многострочные комментарии в блоке комментариев, разделенном символами /* и */
Вот фрагмент кода VCL, в котором используются все три стиля комментирования:
Скалярные значения
Вы можете использовать строки, целые числа и логические значения — типичные скалярные значения — в VCL. VCL также поддерживает время и продолжительность.
Давайте выясним, что мы можем сделать с этими так называемыми скалярными значениями.
Строки
Строки заключаются в двойные кавычки и не могут содержать новые строки. Двойные кавычки также нельзя использовать, очевидно. Если вы планируете использовать новые строки или двойные кавычки в своих строках, вам нужно использовать длинные строки, заключенные в двойные кавычки и фигурные скобки.
Давайте посмотрим код. Вот пример обычных и длинных строк:
Со строками работать легко — просто помните, что длинные строки позволяют использовать новые строки и двойные кавычки, а обычные строки — нет.
Целые числа
О целых числах особо нечего сказать — это просто числа. Когда вы используете целые числа в строковом контексте, они преобразуются в строки.
Вот пример допустимого использования целых чисел:
Первому аргументу функции синтезатора требуется целое число, поэтому мы дали ему целое число.
Предыдущий пример довольно бессмыслен; единственное, что он делает, это доказывает, что целые числа преобразуются в строки.
Булевы значения
Булевы значения могут быть либо истинными, либо ложными. Кроме примера кода добавить больше нечего:
Продолжительность
Еще один тип, поддерживаемый VCL, — длительность. Они используются для тайм-аутов, срока жизни, возраста, отсрочки, хранения и т. д.
Длительность выглядит как число со строковым суффиксом. Суффикс может быть любым из следующих значений:
Поэтому, если мы хотим, чтобы продолжительность составляла три недели, мы определяем продолжительность как 3 недели .
Вот пример VCL, в котором мы установили время жизни ответа на один час:
Продолжительность может содержать действительные числа. Вот пример, в котором мы кешируем 1,5 часа:
Регулярные выражения
VCL поддерживает Perl-совместимые регулярные выражения (PCRE). Регулярные выражения можно использовать для сопоставления с образцом с помощью оператора сопоставления ~.
Регулярные выражения также можно использовать в таких функциях, как regsub и regsuball, для сопоставления и замены текста.
Полагаю, вы хотите увидеть код? Дело в том, что я уже показывал вам пример регулярных выражений, когда говорил об операторе match. Поэтому я скопирую/вставлю тот же пример, чтобы доказать свою точку зрения:
Функции
Регсуб
regsub — это функция, которая сопоставляет шаблоны на основе регулярных выражений и может возвращать подмножества этих шаблонов. Эта функция используется для поиска и замены переменных VCL. regsub соответствует только первому вхождению шаблона.
Вот пример из реальной жизни, где мы ищем файл cookie языка и извлекаем его из заголовка файла cookie, чтобы выполнить вариант кэширования:
Заключая части регулярного выражения в круглые скобки, вы группируете эти части. Каждая группа может быть адресована в части sub. Вы обращаетесь к группе по ее классу. В предыдущем примере группа \1 представляет первую группу. Это группа, содержащая фактический язык, который мы хотим извлечь.
Регсубол
Единственная разница между regsub и regsuball заключается в том, что последний соответствует всем вхождениям, тогда как первый соответствует только первому вхождению.
Если вам нужно найти и заменить строку, которая содержит несколько вхождений искомого шаблона, функция regsuball — это то, что вам нужно!
Пример? Конечно! Посмотрите пример 4-1.
Функция regsuball будет искать все вхождения этих шаблонов и удалять их.
В определенных ситуациях выполнение программы не может быть продолжено четко определенным образом. В ESP-IDF такие ситуации включают:
Исключения ЦП: недопустимая инструкция, ошибка выравнивания загрузки/сохранения, ошибка загрузки/сохранения запрещена, двойное исключение.
Проверки и меры безопасности на системном уровне:
Ошибка доступа к кешу
Событие обнаружения перебоя в работе
Проверка защиты от разрушения стека
Проверка целостности кучи
Проверки дезинфицирующего средства неопределенного поведения (UBSAN)
Неудачные утверждения с помощью assert , configASSERT и подобных макросов.
В этом руководстве объясняется процедура, используемая в ESP-IDF для обработки этих ошибок, и приводятся рекомендации по устранению ошибок.
Обработчик паники¶
Каждая причина ошибки, указанная в обзоре, будет обрабатываться обработчиком паники.
Обработчик паники запустится, выведя на консоль причину ошибки. Для исключений ЦП сообщение будет похоже на
Для некоторых проверок системного уровня (прерывание сторожевого таймера, ошибка доступа к кэшу) сообщение будет похоже на
Во всех случаях причина ошибки будет напечатана в круглых скобках. Список возможных причин ошибок см. в разделе Ошибки медитации гуру.
Распечатать регистры и перезагрузиться ( CONFIG_ESP_SYSTEM_PANIC_PRINT_REBOOT ) — вариант по умолчанию.
Это распечатает значения регистров в точке исключения, напечатает обратную трассировку и перезапустит чип.
Распечатать регистры и остановить ( CONFIG_ESP_SYSTEM_PANIC_PRINT_HALT )
Аналогичен предыдущему варианту, но вместо перезагрузки останавливается. Для перезапуска программы требуется внешний сброс.
Тихая перезагрузка ( CONFIG_ESP_SYSTEM_PANIC_SILENT_REBOOT )
Не печатать регистры и не отслеживать, немедленно перезапустить чип.
Вызвать заглушку GDB ( CONFIG_ESP_SYSTEM_PANIC_GDBSTUB )
Запустите сервер GDB, который может обмениваться данными с GDB через консольный порт UART. Этот параметр обеспечивает только отладку только для чтения или отладку посмертно. Дополнительные сведения см. в заготовке GDB.
Вызов динамической заглушки GDB ( ESP_SYSTEM_GDBSTUB_RUNTIME )
Запустите сервер GDB, который может обмениваться данными с GDB через консольный порт UART. Эта опция позволяет пользователю отлаживать программу во время выполнения и устанавливать точки останова, изменять выполнение и т. д. Дополнительные сведения см. в разделе Заглушка GDB.
На поведение обработчика паники влияют два других параметра конфигурации.
Если параметр CONFIG_ESP_DEBUG_OCDAWARE включен (значение по умолчанию), обработчик паники определит, подключен ли отладчик JTAG. Если это так, выполнение будет остановлено, а управление будет передано отладчику. При этом регистры и трассировка не сбрасываются на консоль, а функции GDBStub/Core Dump не используются.
Если функция Core Dump включена, то состояние системы (стеки задач и регистры) будет выгружаться во флэш-память или UART для последующего анализа.
Если параметр CONFIG_ESP_PANIC_HANDLER_IRAM отключен (отключен по умолчанию), код обработчика паники помещается во флэш-память, а не в IRAM. Это означает, что в случае сбоя ESP-IDF при отключенном флэш-кэше обработчик паники автоматически повторно включит флэш-кэш перед запуском GDB Stub или Core Dump.Это добавляет небольшой риск, если во время сбоя состояние флэш-кэша также будет повреждено.
Если этот параметр включен, код обработчика паники (включая необходимые функции UART) помещается в IRAM, и, следовательно, уменьшается объем доступной памяти в SRAM. Но это может быть необходимо для отладки некоторых сложных проблем со сбоями при отключенном кэше флэш-памяти (например, при записи во флэш-память SPI) или при повреждении кэша флэш-памяти при срабатывании исключения.
На следующей диаграмме показано поведение обработчика паники:
Схема обработчика паники (нажмите, чтобы увеличить) ¶
Регистрация дампа и трассировки¶
Если параметр CONFIG_ESP_SYSTEM_PANIC_SILENT_REBOOT не включен, обработчик паники выводит на консоль некоторые регистры ЦП и трассировку.
Выводимые значения регистров — это значения регистров в кадре исключения, т. е. значения на момент возникновения исключения ЦП или другой фатальной ошибки.
Дамп регистра не печатается, если обработчик паники был выполнен в результате вызова abort().
В некоторых случаях, например, по тайм-ауту сторожевого таймера прерывания, обработчик паники может распечатать дополнительные регистры ЦП (EPC1–EPC4) и регистры/обратную трассировку кода, работающего на другом ЦП.
Строка обратной трассировки содержит пары PC:SP, где PC – счетчик программ, а SP – указатель стека для каждого кадра стека текущей задачи. Если внутри ISR происходит фатальная ошибка, трассировка может включать пары ПК:SP как из прерванной задачи, так и из ISR.
Если используется монитор IDF, значения счетчика программ будут преобразованы в местоположения кода (имя функции, имя файла и номер строки), а выходные данные будут аннотированы дополнительными строками:
Чтобы найти место, где произошла неустранимая ошибка, просмотрите строки, следующие за строкой "Backtrace". Место фатальной ошибки — это верхняя строка, а последующие строки показывают стек вызовов.
Заглушка GDB¶
Если параметр CONFIG_ESP_SYSTEM_PANIC_GDBSTUB включен, обработчик паники не будет сбрасывать чип при возникновении фатальной ошибки. Вместо этого он запустит сервер удаленного протокола GDB, обычно называемый заглушкой GDB. Когда это происходит, экземпляр GDB, работающий на хост-компьютере, может получить указание подключиться к порту ESP32 UART.
Если используется монитор IDF, GDB запускается автоматически при обнаружении приглашения-заглушки GDB на UART. Вывод выглядит следующим образом:
Подсказку GDB можно использовать для проверки регистров ЦП, локальных и статических переменных и произвольных участков памяти. Невозможно установить точки останова, изменить ПК или продолжить выполнение. Чтобы сбросить программу, выйдите из GDB и выполните внешний сброс: Ctrl-T Ctrl-R в мониторе IDF или с помощью кнопки внешнего сброса на макетной плате.
Ошибки медитации гуру¶
В этом разделе объясняется значение различных причин ошибок, напечатанных в скобках после сообщения «Ошибка медитации гуру: основная паника».
См. статью Википедии о медитации гуру, чтобы узнать об историческом происхождении «медитации гуру».
Недопустимая инструкция¶
Это исключение ЦП указывает на то, что выполняемая инструкция не является допустимой. Наиболее распространенные причины этой ошибки:
Функция задачи FreeRTOS возвращена. В FreeRTOS, если функции задачи необходимо завершить, она должна вызывать vTaskDelete() и удалять себя, а не возвращаться.
Не удалось прочитать следующую инструкцию из флэш-памяти SPI. Обычно это происходит, если:
Приложение переконфигурировало контакты флэш-памяти SPI для выполнения какой-либо другой функции (GPIO, UART и т. д.). Подробную информацию о выводах флэш-памяти SPI см. в Руководстве по проектированию оборудования и в техническом описании чипа или модуля.
Какое-то внешнее устройство было случайно подключено к контактам флэш-памяти SPI и помешало обмену данными между ESP32 и флэш-памятью SPI.
В коде C++ выход из непустой функции без возврата значения считается поведением undefined. Когда оптимизация включена, компилятор часто опускает эпилог в таких функциях. Это чаще всего приводит к исключению IllegalInstruction. По умолчанию система сборки ESP-IDF включает -Werror=return-type, что означает, что отсутствующие операторы возврата рассматриваются как ошибки времени компиляции. Однако если в проекте приложения отключены предупреждения компилятора, эта проблема может остаться незамеченной, и во время выполнения возникнет исключение IllegalInstruction.
InstrFetchProhibited¶
Это исключение ЦП указывает на то, что ЦП не смог прочитать инструкцию, поскольку адрес инструкции не принадлежит допустимой области в ОЗУ или ПЗУ инструкции.
Обычно это означает попытку вызвать указатель на функцию, который не указывает на корректный код.В качестве индикатора можно использовать регистр PC (счетчик программ): он будет равен нулю или будет содержать мусорное значение (не 0x4xxxxxxx ).
LoadProhibited, StoreProhibited¶
Эти исключения ЦП возникают, когда приложение пытается прочитать или записать в недопустимую область памяти. Адрес, который был записан/прочитан, находится в регистре EXCVADDR в дампе регистров. Если этот адрес равен нулю, это обычно означает, что приложение попыталось разыменовать указатель NULL. Если этот адрес близок к нулю, это обычно означает, что приложение пыталось получить доступ к элементу структуры, но указатель на структуру равен NULL. Если этот адрес какой-то другой (значение мусора, не в диапазоне 0x3fxxxxxx - 0x6xxxxxxx), это, вероятно, означает, что указатель, используемый для доступа к данным, либо не инициализирован, либо поврежден.
Целое деление на ноль¶
Приложение попыталось выполнить целочисленное деление на ноль.
LoadStoreAlignment¶
Приложение попыталось прочитать или записать ячейку памяти, и выравнивание адресов не соответствует размеру загрузки/хранения. Например, 32-битное чтение можно выполнить только с адреса, выровненного по 4 байтам, а 16-битную запись можно выполнить только по адресу, выровненному по 2 байтам.
LoadStoreError¶
Это исключение может произойти в следующих случаях:
Если приложение попыталось выполнить запись в доступную только для чтения область памяти, например IROM или DROM.
Необработанное исключение отладки¶
За этим обычно следует сообщение типа:
Эта ошибка указывает на то, что приложение выполнило запись за конец стека задачи с именем имя_задачи. Обратите внимание, что не каждое переполнение стека обязательно вызывает эту ошибку. Возможно, задача записывает данные в память за пределы канареечного расположения стека, и в этом случае точка наблюдения не сработает.
Прервать тайм-аут wdt на CPU0 / CPU1¶
Указывает, что истекло время ожидания прерывания. Дополнительную информацию см. в разделе Сторожевые таймеры.
Кэш отключен, но доступ к кэшированной области памяти есть¶
В некоторых случаях ESP-IDF временно отключает доступ к внешней SPI Flash и SPI RAM через кэши. Например, это происходит, когда API-интерфейсы spi_flash используются для чтения/записи/стирания/мммапирования областей SPI Flash. В этих ситуациях задачи приостанавливаются, а обработчики прерываний, не зарегистрированные в ESP_INTR_FLAG_IRAM, отключаются. Убедитесь, что все обработчики прерываний, зарегистрированные с этим флагом, имеют весь код и данные в IRAM/DRAM. Дополнительные сведения см. в документации по SPI flash API.
Другие фатальные ошибки¶
Потемнение¶
ESP32 имеет встроенный детектор отключения питания, который включен по умолчанию. Детектор отключения может инициировать сброс системы, если напряжение питания падает ниже безопасного уровня. Детектор пониженного напряжения можно настроить с помощью параметров CONFIG_ESP_BROWNOUT_DET и CONFIG_ESP_BROWNOUT_DET_LVL_SEL.
При срабатывании детектора отключения выводится следующее сообщение:
Чип сбрасывается после печати сообщения.
Обратите внимание, что если напряжение питания падает с большой скоростью, на консоли может отображаться только часть сообщения.
Повреждённая куча¶
Реализация кучи ESP-IDF содержит ряд проверок структуры кучи во время выполнения. Дополнительные проверки («Heap Poisoning») можно включить в menuconfig. Если одна из проверок не пройдена, будет напечатано сообщение, подобное следующему:
Дополнительную информацию см. в документации по отладке динамической памяти.
Разрушение стека¶
Защиту от разрушения стека (на основе флагов GCC -fstack-protector*) можно включить в ESP-IDF с помощью параметра CONFIG_COMPILER_STACK_CHECK_MODE. Если обнаружено разрушение стека, будет напечатано сообщение, подобное следующему:
Отслеживание должно указывать на функцию, в которой произошло разрушение стека. Проверьте код функции на неограниченный доступ к локальным массивам.
Проверки дезинфицирующего средства на неопределенное поведение (UBSAN)¶
Дезинфекция неопределенного поведения (UBSAN) — это функция компилятора, которая добавляет проверки во время выполнения на наличие потенциально неверных операций, таких как:
переполнение (переполнение умножения, переполнение целого числа со знаком)
ошибки сдвига основания или экспоненты (например, сдвиг более чем на 32 бита)
ошибки целочисленного преобразования
Полный список поддерживаемых проверок см. в документации GCC по параметру -fsanitize=undefined.
Включение UBSAN¶
По умолчанию UBSAN отключен. Его можно включить на уровне файла, компонента или проекта, добавив параметр компилятора -fsanitize=undefined в систему сборки.
При включении UBSAN для кода, который использует файлы заголовков аппаратного регистра SOC ( soc/xxx_reg.h ), рекомендуется отключить дезинфицирующее средство на основе смещения с помощью параметра -fno-sanitize=shift-base. Это связано с тем, что файлы заголовков регистров ESP-IDF в настоящее время содержат шаблоны, которые вызывают ложные срабатывания для этого конкретного параметра дезинфицирующего средства.
Чтобы включить UBSAN на уровне проекта, добавьте следующий код в конец файла CMakeLists.txt проекта:
В качестве альтернативы можно передать эти параметры через переменные среды EXTRA_CFLAGS и EXTRA_CXXFLAGS.
Включение UBSAN приводит к значительному увеличению объема кода и данных. Большинство приложений, кроме тривиальных, не помещаются в доступную оперативную память микроконтроллера, когда для всего приложения включен UBSAN. Поэтому вместо этого рекомендуется включить UBSAN для конкретных тестируемых компонентов.
Чтобы включить UBSAN для определенного компонента ( component_name ) из файла CMakeLists.txt проекта, добавьте следующий код в конец файла:
Дополнительную информацию о свойствах сборки и свойствах компонентов см. в документации по системе сборки.
Чтобы включить UBSAN для определенного компонента ( имя_компонента ) из файла CMakeLists.txt того же компонента, добавьте в конец файла следующее:
Вывод UBSAN¶
Когда UBSAN обнаруживает ошибку, печатается сообщение и трассировка, например:
При использовании IDF Monitor обратная трассировка будет декодирована в имена функций и местоположения исходного кода, указывая на место, где возникла проблема (здесь это main.c:128 ):
Типы ошибок, о которых сообщает UBSAN, могут быть следующими:
Неверное значение указателя: null, невыровненное, несовместимое с данным типом.
add_overflow, sub_overflow, mul_overflow, negate_overflow
Целочисленное переполнение при сложении, вычитании, умножении, отрицании.
Целочисленное деление на 0 или INT_MIN .
Переполнение в операторах сдвига влево или вправо.
Доступ за пределы массива.
Выполнен недостижимый код.
Непустая функция достигла своего конца, не возвращая значения (только C++).
Размер массива переменной длины не является положительным.
Значение переменной bool или enum (только C++) недопустимо (за пределами допустимого диапазона).
Нулевой аргумент передается функции, объявленной с ненулевым атрибутом.
Нулевое значение, возвращаемое функцией, объявленной с атрибутом return_nonnull.
Читайте также: