VSM: Логирование и статистика в общей памяти

Varnish использует общую память для экспорта параметров, логирования и статистики, так как это быстрее и эффективнее, чем обычные файлы.

«Varnish Shared Memory» или VSM — это общий механизм, поддерживающий наборы файлов общей памяти, каждый из которых представляет собой блок памяти, идентифицируемый двухкомпонентным именем (класс, идентификатор).

Класс указывает тип данных, хранящихся в блоке, например, «Arg» для аргументов командной строки, полезных для установления подключения CLI к varnishd, «Stat» для счётчиков статистики (VSC) и «Log» для записей логов (VSL).

Часть имени ident в основном используется со счётчиками статистики, где они идентифицируют динамические счётчики, такие как:

SMA.Transient.c_bytes

Хранение в общей памяти

Общая память быстрее обычных файлов, но она также немного сложнее в использовании, чем обычный лог-файл.

При открытии файла в режиме «добавления» операционная система гарантирует, что всё, что вы записываете, не будет перезаписывать существующие данные в файле. Прекрасным результатом этого является то, что несколько процессов или потоков, записывающих в один и тот же файл, даже не должны знать друг о друге; всё работает так, как вы ожидаете.

С логом в общей памяти мы не получаем такой помощи от ядра; записывающим процессам необходимо убедиться, что они не перезаписывают друг друга, и сделать доступ к данным безопасным для читающих процессов.

«Базовый» способ решения этой проблемы — введение блокировок, и много времени уходит на изучение достоинств различных типов блокировок.

Внутри процесса varnishd (рабочий процесс) мы используем мьютексы для обеспечения согласованности, как с выделением памяти, так и с записями логов и счётчиками статистики.

Мы не хотим, чтобы varnishncsa пытался передать данные через приостановленное SSH-соединение, чтобы замедлить доставку контента, поэтому читатели подобного типа являются только читательными; они не могут повлиять на процесс varnishd, а это означает отсутствие блокировок для них.

Вместо этого мы используем концепции «устойчивого хранения», чтобы убедиться, что вид, видимый читателями, всегда согласован.

До тех пор, пока вы только добавляете данные, это тривиально, но удаление данных, например, когда бэкенд удаляется из конфигурации, требует дать читателям возможность обнаружить это — период «охлаждения».

Подход Varnish:

При запуске varnishd открываются заблокированные файлы общей памяти; рекомендуется использовать разные аргументы -n, если есть попытка запустить несколько экземпляров varnishd с одинаковым именем.

Дочерние процессы каждый используют свои собственные файлы общей памяти, поскольку перезапуск рабочего процесса помечает чистый разрыв в работе.

В максимально возможной степени старые файлы общей памяти помечаются как заброшенные, устанавливая поле alloc_seq в ноль, которое должны отслеживать все читатели VSM.

Процессы, подписанные на файлы VSM в течение длительного времени, должны заметить, если файл VSM становится «немым», и проверить, не было ли переименовано файл из-за перезапуска дочернего процесса.

Блоки в файле общей памяти образуют связанный список, и всякий раз, когда этот список изменяется, изменяется поле alloc_seq.

Связанный список и другие метаданные в файле VSM работают со смещениями относительно начального адреса отображения в памяти файла VSM, поэтому его не нужно отображать по какому-либо конкретному адресу.

Когда выделяются новые блоки, например, при добавлении нового бэкенда, они добавляются в конец списка, независимо от их расположения в файле VSM.

Когда блок освобождается, он удаляется из связанного списка выделений, его длина устанавливается в ноль, а alloc_seq изменяется, чтобы указать изменение структуры. В течение следующих 60 секунд блок не будет трогаться или повторно использоваться, давая другим подписчикам возможность обнаружить освобождение.

Файл заголовков <vapi/vsm.h> предоставляет поддерживаемую API для доступа к файлам VSM.