Меньше чем что? Я сравниваю с монолитными ядрами:
монолитное ядро, вызов io: RING3->RING0->RING3 без сброса кеша страниц
микроядро, вызов io RING3->RING0->RING3, Context switching -> RING0 -> RING3, Context switching
В случае с микроядрами думаю будет по другому:
RING3 -> RING0 -> RING2, Context switching -> RING1, Context switching -> RING0 -> RING3, Context switching
поскольку ядро не выполняет большую часть задач, а драйвера не могут быть в RING0 из-за особенностей.
Это не проблема микроядра, а проблема архитекторов систем на микрядре. В правильно спроектированной системе переключений контекста меньше. Микроядро L4 синхронное, откуда в синхронной системе взяться большему числу переключений контекста чем в асинхронной?
Все хорошо, Вы спроектировали систему и… в ней нету процессов? Тут у Вас выбор 1 из 2 — (1) консолидировать несколько процессов в один, что черевато или (2) 1 процесс = 1 процессу в ядре, для примера — посмотрите тот-же nginx
В этом и проблема — L4 синхронно, следовательно с новыми процессорами будут проблемы и сложность — если Вы слышали про SMP например…
Если говорить о микроядре L4 в целом, то профит легко находится в универсальных виртуальных страницах. Для описания региона памяти их требуется меньше, чем обычных виртуальных страниц фиксированного размера.
Причину по которой во всех современных ОС используется модель страниц фиксированного размера Вы найдете в любом документе по проектированию ОС, тут вообще без комментариев.
а если учесть что у всех микроядер все вынесено за рамки ядра — то переключение будет ОЧЕНЬ интенсивным, как и накладные расходы тоже.
P.S. микроядра хороши только в embedded где нужна супернадежность.
Это расчет брался по реальному проекту для Xen:
(1) Redis (в качестве кэша)
(2) PerconaDB (интенсивный транзакции)
(3) MongoDB
(4) 3 x nginx (highload)
(5) 3 x CentOS — служебные машины
смотря для каких БД — поскольку для некоторых (single file) можно вообще отдать блочное устройство и тогда не иметь проблем с накладными расходами от файловой системы.
P.S. при условии что:
— БД действительно может работать в таком режиме
— БД будет занимать меньше места чем размер блочного устройства
Давайте — обычно размер идет по принципу.
Кэш = 2 * локальный кэш диска в RAID (обычно 64MB) * N (число дисков в RAID)
Берем пример для 4 дисков = 2 * 64MB * 4 = 512MB
Учитывая что будет интенсивная нагрузка на запись то берем двойное значение — т.е. 512MB*2 = 1024MB это и есть нужное значение.
RING1 — драйвера
RING2 — врапперы и служебные библиотеки
RING3 — приложения
Меньше чем что? Я сравниваю с монолитными ядрами: монолитное ядро, вызов io: RING3->RING0->RING3 без сброса кеша страниц микроядро, вызов io RING3->RING0->RING3, Context switching -> RING0 -> RING3, Context switchingВ случае с микроядрами думаю будет по другому:
RING3 -> RING0 -> RING2, Context switching -> RING1, Context switching -> RING0 -> RING3, Context switching
поскольку ядро не выполняет большую часть задач, а драйвера не могут быть в RING0 из-за особенностей.
Это не проблема микроядра, а проблема архитекторов систем на микрядре. В правильно спроектированной системе переключений контекста меньше. Микроядро L4 синхронное, откуда в синхронной системе взяться большему числу переключений контекста чем в асинхронной?Все хорошо, Вы спроектировали систему и… в ней нету процессов? Тут у Вас выбор 1 из 2 — (1) консолидировать несколько процессов в один, что черевато или (2) 1 процесс = 1 процессу в ядре, для примера — посмотрите тот-же nginx
В этом и проблема — L4 синхронно, следовательно с новыми процессорами будут проблемы и сложность — если Вы слышали про SMP например…
Если говорить о микроядре L4 в целом, то профит легко находится в универсальных виртуальных страницах. Для описания региона памяти их требуется меньше, чем обычных виртуальных страниц фиксированного размера.Причину по которой во всех современных ОС используется модель страниц фиксированного размера Вы найдете в любом документе по проектированию ОС, тут вообще без комментариев.
P.S. микроядра хороши только в embedded где нужна супернадежность.
(1) Redis (в качестве кэша)
(2) PerconaDB (интенсивный транзакции)
(3) MongoDB
(4) 3 x nginx (highload)
(5) 3 x CentOS — служебные машины
В этом конфиге все очень даже хорошо.
P.S. при условии что:
— БД действительно может работать в таком режиме
— БД будет занимать меньше места чем размер блочного устройства
Кэш = 2 * локальный кэш диска в RAID (обычно 64MB) * N (число дисков в RAID)
Берем пример для 4 дисков = 2 * 64MB * 4 = 512MB
Учитывая что будет интенсивная нагрузка на запись то берем двойное значение — т.е. 512MB*2 = 1024MB это и есть нужное значение.
кстати для примера проще использовать несколько уровней кэширования
2GB (OS Cache) + 2GB (RAID Cache) + 3xRAID5 120GB (SSD Cache) = основная дисковая подсистема
насколько Я знаю там µs по average, также как и IOPS.