S
все то же самое при контейнерах, только кэш не просто общий, а еще и не дуплицируется в гостях.
Нет. В конте нет полного окружения. Только минимум.
Size: a a a
2019 March 25
S
Это полезный оверхед, он ускоряет работу гостевой системы.
A
Это полезный оверхед, он ускоряет работу гостевой системы.
но не ускоряет работу приложения в целом.
A
суммарно оверхед получается выше
S
но не ускоряет работу приложения в целом.
Какого приложения?
A
того, которое запросило чтение данных
S
У меня ещё один слой буфера получается от тормозного диска.
A
ты же понимаешь, что буфферы тоже не бесплатны?
A
за каждый дополнительный слой буфера тоже платить надо
S
Понимаешь, всё зависит от задачи.
S
Иногда проще поставить 64 гига памяти ещё, чем поднимать железную реализацию, которая будет хуже, чем ещё одна виртуальная машина.
A
я не могу понять, как цепочка
app -> read disk block <=> guest kernel <=> guest cache <=> hypervizor <=> native kernel <=> native cache <=> block device
быстрее, чем
app -> read disk block <=> native kernel <=> native cache <=> block device
В обоих случаях native cache будет хранить ВСЕ кэши ВСЕХ гостей/контейнеров, однако в случае с контейнером не будет лишнего раундтрипа до хостового кэша (или не дай бог физического девайса) и не будет перерасхода памяти на кэш.
app -> read disk block <=> guest kernel <=> guest cache <=> hypervizor <=> native kernel <=> native cache <=> block device
быстрее, чем
app -> read disk block <=> native kernel <=> native cache <=> block device
В обоих случаях native cache будет хранить ВСЕ кэши ВСЕХ гостей/контейнеров, однако в случае с контейнером не будет лишнего раундтрипа до хостового кэша (или не дай бог физического девайса) и не будет перерасхода памяти на кэш.
S
я не могу понять, как цепочка
app -> read disk block <=> guest kernel <=> guest cache <=> hypervizor <=> native kernel <=> native cache <=> block device
быстрее, чем
app -> read disk block <=> native kernel <=> native cache <=> block device
В обоих случаях native cache будет хранить ВСЕ кэши ВСЕХ гостей/контейнеров, однако в случае с контейнером не будет лишнего раундтрипа до хостового кэша (или не дай бог физического девайса) и не будет перерасхода памяти на кэш.
app -> read disk block <=> guest kernel <=> guest cache <=> hypervizor <=> native kernel <=> native cache <=> block device
быстрее, чем
app -> read disk block <=> native kernel <=> native cache <=> block device
В обоих случаях native cache будет хранить ВСЕ кэши ВСЕХ гостей/контейнеров, однако в случае с контейнером не будет лишнего раундтрипа до хостового кэша (или не дай бог физического девайса) и не будет перерасхода памяти на кэш.
Посмотри как в аппаратуре вообще ускоряют работу кэшами. Книжку почитай, в которой это расписано.
EC
а если взять допустим плату с 2 лан портами, 1 сделать ван на приём от провайдера, 2 пустить на свич, а на свиче уже повесить там пару лан устройств, так прокнет? ну имею ввиду там назначать айпишки смогу или ето на себя свич возьмёт, и как по производительности ?
S
А так — да и пусть хранит, тебе-то какая разница, чего он хранит?
A
а если взять допустим плату с 2 лан портами, 1 сделать ван на приём от провайдера, 2 пустить на свич, а на свиче уже повесить там пару лан устройств, так прокнет? ну имею ввиду там назначать айпишки смогу или ето на себя свич возьмёт, и как по производительности ?
у меня сейчас примерно так и есть)
https://sinair.ru/i/3y51bU
https://sinair.ru/i/3y51bU
c
Посмотри как в аппаратуре вообще ускоряют работу кэшами. Книжку почитай, в которой это расписано.
так себе аргумент, на самом деле
c
вообще не про то
A
Посмотри как в аппаратуре вообще ускоряют работу кэшами. Книжку почитай, в которой это расписано.
я об этом и говорю - что кэши хороши, когда они не дублируются
S
так себе аргумент, на самом деле
Но вообще кэширование ускоряет, в определённых пределах.