Linux / proc / sys / vm / drop_caches в гостевых виртуальных машинах
Вопрос: Было бы неплохо отключить кеш страниц внутри гостевой виртуальной машины, а вместо этого полагаться на ZFS ARC (и L2ARC на основе SSD) хоста?
Контекст: Я спрашиваю, так как я использую кластер Proxmox, который всегда показывает около 90% использования ОЗУ для всех виртуальных машин, независимо от того, сколько им действительно нужно. Этого следовало ожидать из-за того, что гостевое ядро использует кеш страниц. Поскольку я слышал много хороших отзывов о ZFS ARC, я подумал, что, возможно, я мог бы больше полагаться на них и уменьшить зависимость от кеша страниц гостей. По сути, ARC будет своего рода общим кешем страниц для всех виртуальных машин.
Сделав это, я получил бы дополнительное преимущество в виде более точной статистики и графиков proxmox, что дало бы мне лучшее представление о том, сколько памяти на самом деле требуется каждой виртуальной машине. Это, в свою очередь, предоставит мне информацию, которая мне нужна, чтобы лучше настроить размеры ОЗУ каждой виртуальной машины, и позволит мне увеличить размер ARC хоста на ту же величину.
На самом деле я не пробовал ничего из этого, я думал, что сначала вы, ребята, попробую это сделать. Итак, неужели я глуп, что так думаю?
Дополнительный вопрос : КАК я могу отключить (или ограничить) кеш страницы в виртуальной машине Linux? ОДИН метод - использовать задание cron и регулярно записывать «3» в / proc / sys / vm / drop_caches, например, раз в минуту или что-то в этом роде.Но это кажется хакерским, разве нет лучшего способа?
P.S. Да, я понимаю, что говорю только о кэше чтения, а не о кеше записи, на который влияет количество грязных страниц. Так что мне, вероятно, все равно понадобится некоторое количество свободного места в ОЗУ, чтобы учесть это (но это должно быть видно в статистике использования ОЗУ виртуальной машины в Proxmox, поэтому все, что указано выше, все равно должно применяться).
Я часто (но не всегда, см. Ниже) оптимизирую свои гипервизоры аналогично тому, что вы предлагаете: позволить виртуальным машинам в значительной степени ретранслировать на общий дисковый кеш хоста.
Однако, используя Подход drop_caches кажется мне слишком тяжелым, поскольку он может лишить гостя слишком много кэш-памяти. В то же время я не знаю никакого метода ограничения кеширования страниц (кроме настройки вашего приложения для использования прямого ввода-вывода). Итак, ключ в правильном размере ресурсов RAM вашей виртуальной машины: попробуйте выделить только ту память, которая действительно нужна гостю, плюс 1 или 2 ГБ, чтобы иметь некоторую «передышку».
Такое управление памятью имеет некоторые важные преимущества:
- управляемая хостом, кэш-память может динамически выделяться гостям в зависимости от их требований к вводу-выводу;
- благодаря динамическому управлению, рассматривая вашу память как истинный пул ресурсов, вы сокращаете потери ресурсов и повысить эффективность;
- при использовании ZFS на вашем хосте вы задействуете очень продвинутый ARC / L2ARC и его устойчивое к мусору поведение
Но есть и некоторые недостатки:
- то, что он является общим ресурсом, кеш вашего хоста память может быть уничтожена мошеннической виртуальной машиной (что влияет на другие, более важные, виртуальные машины);
- расположение некоторых переключателей контекста и
vmexit / vmenterпиковая и устойчивая скорость любого кэша на основе хоста будет быть ниже, чем коррумпированный кеш на стороне гостя (и это причина, по которой я предлагаю вам избегать повторяетсяdrop_cachesв гостевой системе); - хотя и более продвинутый и с гораздо более высокой частотой попаданий, ARC медленнее, чем кэш страниц Linux , когда рабочая нагрузка полностью помещается в кеш. Таким образом, для максимальной гостевой скорости на гостевых системах, критичных к производительности, вы, вероятно, захотите выделить виртуальной машине достаточно памяти для кэша страниц.