Влияние на различные команды Linux на сервере Varnish

Я знаю, что Varnish использует технику отображения памяти для кэширования данных в памяти. Что если я выполню следующие команды на машине, есть ли какие-либо ограничения на общую производительность Varnish?

например

Общий объем памяти = 4 ГБ, произвольно сгенерированный файл test.txt = 2 ГБ

1. cat test.txt
2. mv test.txt /another-partition
3. cp test.txt /another-partition
4. mv test.txt /another-dir
5. cp test.txt /another-dir

2 ответа

Решение

Интересный вопрос!

Как ссылка, эта страница от автора подсистемы VM даст вам хорошее представление о том, что может произойти;

http://linux-mm.org/PageReplacementDesign

Обратите внимание, что на самом деле очень трудно ответить в его текущей форме (если вы говорите о кешированных файлах), потому что это зависит от того, насколько горячим является кеш, как долго вы кешируете элементы и "тепло" каждого объекта в кеше.,

Предполагая следующее:-

  • Кеш поддерживается файлом 10G и полностью заполнен.
  • 3% объектов в кеше составляют 90% всех попаданий.
  • У вас есть одновременность около 80 обработанных соединений в любой момент времени.
  • Вы не изменили свою политику VM по умолчанию.
  • Перед командой почти полностью заполняется кэш страниц страницами из вашего кэша лака.
  • 500 миллионов данных выделяется исключительно для анонимных страниц из других вещей, работающих в системе.

Поскольку размер кэша лака равен 10 ГБ, он никогда не будет полностью помещаться в памяти, поэтому следующая формула является относительно представительной

  • Существует 3500M кеш страниц.
  • Самый горячий 1750Mb кеша лака находится в "активном" списке и защищен от вытеснения Pagecache.
  • Кулер 1750Mb кеша лака находится в списке "неактивных" и не защищен от выселения.
  • Самый холодный 6500Mb кеша лака не находится в памяти и где-то живет на диске.

Таким образом, следующее, вероятно, результат для всех ваших команд, которые вы запускаете.

  1. Этот файл помещается в память и кэшируется, но все новые объекты в кэше по умолчанию отправляются в "неактивный" список.
  2. Это освобождает 1750 МБ вашей "кулер-неактивной" памяти из кэша лака и заменяет ее загруженным файлом.
  3. Теперь ядро ​​вынуждено записать 1750M этих данных обратно на диск (в худшем случае).
  4. Ожидание ввода-вывода и использование устройства получают удар, потому что вы читаете файл 2G и записываете файл 1750M.
  5. На 97% входящих запросов это не влияет, поскольку они хотят получить самые горячие 1750 МБ данных о лаке, которые находятся в активной части кэша страниц!
  6. 3% незадачливых клиентов хотят получить данные в кулере кулера. Эти парни видят задержку сейчас, потому что использование диска уже довольно высоко, и они стоят в очереди, чтобы снова вернуть страницы в кеш страниц! Поскольку загруженный файл никогда не перечитывается достаточно быстро, кеш страниц выгружает эти страницы в пользу 3% клиентов, которым нужны более прохладные данные.

Это абсолютно худший вариант развития событий. Итак, в широком смысле - как это влияет?

Для 97% ваших обслуживаемых запросов нет пренебрежимого влияния.

Из 3%, которые затронуты, ожидают большую задержку в обслуживании - вероятно, 500 миллисекунд.

НО из этих 3% неудачных запросов около 2% из них в любом случае были бы медленными, потому что они хотели что-то из кэша 6500 Мбайт, которого никогда не было в кэше страниц! Однако сейчас они страдают от высокой загрузки диска.

Итак, подведя итог моему надуманному и предполагаемому примеру, вы увидите в общих чертах потерю эффективности на 3%. (100% эффективности - все объекты для каждого запроса обслуживаются из памяти).

В "нормальном" режиме работы в этом надуманном примере эффективность будет примерно на 98% выше.

Неплохо для кеша, который не помещается в память!

Ответ зависит от того, какое хранилище использует ваш кеш.

Если вы настроили лак для использования файлового хранилища, ваши файловые операции могут повлиять на производительность.

На выделенной системе с 4 гигабайтами оперативной памяти я рекомендую использовать "malloc" размером около 3 гигабайт в качестве хранилища для кеша.

См.: https://www.varnish-cache.org/docs/trunk/users-guide/storage-backends.html

Другие вопросы по тегам