Где лучше размещать swap: на хосте или ВМ?

ИМХО, лучше на ВМ. ОСи виднее, где горячие данные и что нельзя свопить

overselling памяти можно использовать, только если на гостях работает memory balooning. Не знаю, есть ли он в KVM

ИМХО, лучше на ВМ. ОСи виднее, где горячие данные и что нельзя свопить

У меня примерно такие же рассуждения. Но они актуальны до момента пока сам хост в своп не ушёл. А вот когда он уже начал свопиться, не факт, что он правильно распределяет память.

Но они актуальны до момента пока сам хост в своп не ушёл. А вот когда он уже начал свопиться, не факт, что он правильно распределяет память.

А он и не должен уходить в своп. Либо не выдавай виртуалкам больше памяти, чем есть на хосте, либо убедись, что balooning настроен и работает

Лучше в гостях. А память распределять так, что бы такого " Машины, естественно, сидят в свопе (в прочем, как и хост)." не допускать. Я честно говоря не знаю как вы с этим работаете, даже если и на «супербыстром ssd».

ksm включить не забудь. А вот balloning memory, ИМХО - бесполезен, и даже вреден. Ибо ОС, будет стремиться занять максимальный объём ОЗУ.

Проблема в том, что на хосте изначально работают свои приложения. Т.е. он там не только для виртуализации. Переносить всё с хоста на отдельную ВМ очень муторно, да и почти не нужно, т.к. сами ВМ там временно.

Попробую изучить balooning, спасибо.

Это очень маленькая машина. Её максимум - 8ГБ памяти. Сами виртуальные машины там временно (лучше работа с тормозами, чем их совсем бы не было).

О, спасибо за подсказку.

А вот balloning memory, ИМХО - бесполезен, и даже вреден. Ибо ОС, будет стремиться занять максимальный объём ОЗУ.

С «ОС, будет стремиться занять максимальный объём ОЗУ» не совсем согласен, потыкал в рабочие серверные виртуалки (linux), вполне себе свободная память есть, да и та которая занята больше cached.
Насчет «ballooning memory» в чем-то согласен, во всяком случае я в его сторону смотрю с осторожностью, т.е. знаю что возможность есть, но использовать пока не собираюсь. При планировании отталкиваюсь от физической памяти и соответственно потребностей виртуалок, в сами виртуалки, при необходимости, отдаю память с перезакладом.

Попробую изучить balooning, спасибо.

ИМХО, не стоит траты времени. Если у тебя внутри виртуалки, что-то крутится, и отъедает под кеши - балонинг не поможет. Как-то так. Все забили на него. А на виндовых машинах так и тем более не советуют его.

ОСи виднее, где горячие данные и что нельзя свопить

Мнение ОС в виртуалке может не сопадать с реальностью.

ИМХО, на хосте.

Я делаю аналогично. Но в документации на ovirt, чётко написано: или крестик снимайте, или трусы одевайте. - То есть или балонинг, или ksm. Но вот цимис в том, что балонинг по дефолту отключен, а ksm включен. Ибо во-первых не требует поддержки гостём, а во вторых при хоть сколько-нибудь одинаковых вирт. машинок - даёт определённый профит. Считай с двух одинаковых чисто запущеных линуксов, 100-300 метров уже может помочь сэкономить.

Для общего развития всё равно поковыряю :)

Была ещё такая мысль: т.к. везде Debian, примонтировать диски ВМ к хосту и запустить не виртуализацию, а через systemd-nspawn. Правда не знаю, чем это может обернуться когда они обратно на полноценный хост переедут.

Её максимум - 8ГБ памяти.

Для многих задач, это вполне приемлемо, можно и несколько виртуалок держать и хосту для работы оставлять. Но опять-таки все от задач зависит, например несколько вин гостей уже не прокатит :)

лучше работа с тормозами

«работа с тормозами» - чаще чем хотелось бы означает «отсутствие работы». Периодические задачи, когда время выполнения начинает превышать отпущенное, т.е. сервер просто не успевает обработать все данные. Клиент серверные, когда клиент отвалиться по таймауту. Да и просто варианты когда мне результат выполнения через 20 минут уже не нужен, вобщем много чего.

Мнение ОС в виртуалке может не сопадать с реальностью.

Сильно сомневаюсь, что это возможно. Именно потому, что задача ядра - знать где что лежит и как давно туда не было обращений :) Ладно, пусть. А если хост выгрузит в своп память ядра гостя?

Поверь, своппинг снаружи ВМ _гораздо_ сильнее влияет на производительность и приводит к рандомным тормозам ( у меня несколько кластеров vsphere суммарно на несколько десятков Тб памяти, время от времени встречаю такое, если неправильно выставлены лимиты ). Просто потому, что ядро гостя не знает, что вот эта свободная память - на самом деле в глубокой свопе и при попытке её записать начнутся адские тормоза.

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

Мнение ОС в виртуалке может не сопадать с реальностью.

Сильно сомневаюсь, что это возможно.

А я не понимаю, как может быть иначе (balooning не рассматриваем). Каждое ядро думает только о себе (о других ядрах оно просто не знает) и не имеет никаких причин сливать, например, неиспользуемый кэш. Ядро же хоста видит этот кэш как неиспользуемую память и свопит ее.

А если хост выгрузит в своп память ядра гостя?

Это случится только тогда, когда ядро гостя вообще неактивно. А при минимальной активности мы получим paged kernel на халяву (а когда-то AIX очень этим гордился).

Поверь, своппинг снаружи ВМ _гораздо_ сильнее влияет на производительность

Объясни мне механизмы.

А я не понимаю, как может быть иначе (balooning не рассматриваем).

Именно что рассматриваем.

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

Да. Но если процесс отбора никак не контролируется ядром гостя, то мы ловим проблемы.

overselling вообще зло и до отбора памяти у гостя доходить не должно. Если по-хорошему

Если уж дошло до отбора памяти, то единственный цивилизованный вариант - отобрать через baloon драйвер. Драйвер в ядре гостя говорит - эта память теперь моя. А ядерная память не подвержена своппингу по определению и главное модуль может сказать, где она прямо ( а не через трансляцию виртуальных адресов ) расположена. В результате, отбор памяти у гостя идёт под управлением хоста, но при этом гость знает, сколько памяти у него отобрали и где этот отобранный кусок расположен )

Если же у хоста нет механизма воздействия на гостя, то ядро гостя рано или поздно по необходимости будет проводить доступ к этой памяти. И скатываться в дикие тормоза. Что прикажешь делать хосту? Доставать из свопа и тут же убирать в своп другие данные?

А если хост выгрузит в своп память ядра гостя?

Это случится только тогда, когда ядро гостя вообще неактивно. А при минимальной активности мы получим paged kernel на халяву (а когда-то AIX очень этим гордился).

Меня эта гордость аикса в прошлом месяце задрала. Ораклоиды внезапно разучились правильно считать SGA и отдали под инстансы _чуть_ больше, чем было нужно. В результате в своп пошли именно что page table area, и результат был страшноватым. своп начинал жраться медленно, но верно, в результате - out of memory на любую команду админа даже на vterm, а ssh вообще не подключался.

Поверь, своппинг снаружи ВМ _гораздо_ сильнее влияет на производительность

Объясни мне механизмы.

См. выше. Ядро гостя не знает, что вот этот кусок памяти в свопе. Оно считает, что он свободен. И никак не отделяет его от других свободных. Но на стороне хоста он в свопе. Ядро гостя выделяет его приложению. Хост вытаскивает его из свопа, кидает в своп другую память ( нехватка же ). В результате на пустом месте две операции своппинга. Если бы использовался balooning, из этих двух не произошло бы ни одной - ядро не может просто так взять и отобрать память у baloon драйвера. Хост сказал занято, значит занято

Хост вытаскивает его из свопа, кидает в своп другую память ( нехватка же ).

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

Ну то есть ты напираешь на balooning. Окей, но выше уже сказали, что с ним не всё шоколадно.

В результате в своп пошли именно что page table area, и результат был страшноватым. своп начинал жраться медленно, но верно, в результате - out of memory на любую команду админа даже на vterm, а ssh вообще не подключался.

Если весь своп израсходовался - это тупо утечка памяти, и paged ядро просто позволило системе придти в негодность несколько позже.

Ну то есть ты напираешь на balooning. Окей, но выше уже сказали, что с ним не всё шоколадно.

В kvm - возможно. Но это же проблемы kvm, а не технологии ;)

Если весь своп израсходовался - это тупо утечка памяти, и paged ядро просто позволило системе придти в негодность несколько позже.

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

Если подключить второй своп того же размера, первый отключить, то в результате окажется, что в свопе пусто, всё выгружено обратно в память

Несколько странное решени VMM, но вполне может быть допустимым.

Ибо ОС, будет стремиться занять максимальный объём ОЗУ.

а что, такое будет при любом планировщике памяти?