>Это просто пример, есть разные политики для пула потоков.
ну ок, 64/128/256k клиентов. вы же тредов не напасетесь.
>Если нужен асинхронный сервер, то можно попробовать интегрировать vert.x
вокруг этой штуки слишком много хайпа. ну и «A verticle instance is strictly single threaded.» доставляет. код внутри вертикля должен исполнятся очень быстро и никого не ждать(например, бд).
>Такой сервер довольно быстро отдает контент, я тестировал через утилиту ab и результаты впечатляют.
у меня вопрос: если к вам придёт 16к клиентов с gprs и будут мееедленно, по байту в минуту читать ответ, что станет с вашим сервером?
глядя на $service = ExecutorService::newFixedThreadPool(5); возникает стойкое ощущение, что на первых пяти клиентах всё и закончится.
А вы можете, как пхпист сказать чего плохого в этом коде и рассказать как бы вы сделали?
(как я понимаю, автор кода хотел собирать метрики производительности).
private static function write($message)
{
file_put_contents('/tmp/mw-benchmarks.log', "$message\n", FILE_APPEND);
}
это и есть реальный файл.
сделайте chroot /vz/private/7777777/fs/root
и у вас будет практически такой же эффект.
>но вот контейнер об этом совсем «не знает»
контейнер — это логическая сущность. для ядра процессы внутри контейнера практически ничем не отличаются от процессов вне его. все эти лимиты ubc — это предок cgroups.
>этот файл реально могут использовать десятки и сотни контейнеров, физически же он будет одним и тем же, при этом в памяти он будет подгружен тоже ровно один раз, вот-только изнутри контейнера вы никогда об этом не знаете
>в контейнерах можно крутить разные дистрибутивы систем, при этом каждый дистрибутив будет иметь вагон своих собственных системных либ, которые будут загружены в память как совершенно разные экземпляры, если конечно эти либы разные.
и? с таким же успехом это можно делать даже в chroot.
>Вас наверное немного запутала моя фраза «один и тот же системный файл»
нет, ни капли. меня запутала ваша фраза
>когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины
вы не могли бы пояснить, что значит «на внешнем уровне запрашивают»?
спасибо за развернутый комментарий!
сразу видно когда человек понимает о чем пишет :)
меня смутил исходный комментарий
>В Jelastic этот механизм используется также для оптимизации операций ввода-вывода.
т.к. никакой оптимизаций ввода-вывода не происходит и для чтения inode всё равно будет seek по диску.
pfcache больше похож на uksm, только оперирующий файлами(а не страницами, как uksm).
Кстати, а возможно ли лимитировать в Virtuozzo контейнер по iops'ам?
когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины
что значит «на внешнем уровне»?
ведь у контейнеров общее ядро(а значит, общие page cache и dentry cache, драйвера итп).
сам термин «профетч» не юниксовый, вот только на этом и сделал акцент ;)
с чего бы вдруг? наберите в гугле хотя бы «zfs prefetch».
думаю, если покопаться, можно найти упоминание этого слова еще во времена SunOS, когда windows еще просто не существовало.
но это всё лирика. в конце-концов, в системе команд IA-32 есть такая инструкция :)
если я не ошибаюсь, prefetcher — исключительно виндовая фича (http://en.wikipedia.org/wiki/Prefetcher)
ох, как всё грустно. вообще-то prefetch — это когда нужные вам данные находятся на медленном ресурсе( диски, сеть) и зная что они вам понадобятся в ближайшем будущем вы инициируете их загрузку заранее.
например, чем вам POSIX_FADV_WILLNEED не префетч?
читайте внимательнее пожалуйста пост, здесь же имеют ввиду случай, когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины, а не одно приложение внутри контейнера
вообще-то у контейнеров нет понятия «хост-машины».
cgroups — это просто счётчики/лимиты на разные ресурсы + иерархия процессов. вот упомянутый выше systemd каждый сервис сажает в отдельную cgroup.
cgroups не имеет отношения к контейнерам просто потому что контейнеры — это просто набор флажков( CLONE_NEWNET, CLONE_NEWPID etc) для вызова clone().
>Чтобы сделать использование ресурсов еще более рациональным, Jelastic использует механизм дедупликации памяти. Этот механизм собирает статистику о файлах, которые чаще всего запрашиваются контейнером, и помещает такие файлы в кэш-память.
что-то я не понял. речь про дедупликацию памяти, а в итоге речь про дисковые операции. wtf?
>Наши ближайшие конкуренты OpenShift и CloudFoundry уже по одному разу перепроектировали свои решения внедряя слой псевдо-контейнерной виртуализации cgroup + SElinux и Warden соответственно.
cgroups(а не cgroup) не имеют отношения к контейнерам вообще.
до того момента, пока вам не надо читать с диска.
ну ок, 64/128/256k клиентов. вы же тредов не напасетесь.
>Если нужен асинхронный сервер, то можно попробовать интегрировать vert.x
вокруг этой штуки слишком много хайпа. ну и «A verticle instance is strictly single threaded.» доставляет. код внутри вертикля должен исполнятся очень быстро и никого не ждать(например, бд).
у меня вопрос: если к вам придёт 16к клиентов с gprs и будут мееедленно, по байту в минуту читать ответ, что станет с вашим сервером?
глядя на $service = ExecutorService::newFixedThreadPool(5); возникает стойкое ощущение, что на первых пяти клиентах всё и закончится.
man 7 inotify
(как я понимаю, автор кода хотел собирать метрики производительности).
штоу?? прекрасно всё работает. что на ubuntu, что на gentoo или arch.
соберите вот это: code.google.com/p/linux-ftools/
точнее, нам понадобится только fincore & fadvise.
берем на hn создаём файл на 1Гб:
dd if=/dev/urandom of=/vz/private/7777777/fs/root/1gb bs=1M count=1024
внутри контейнера:
fincore --pages=false --summarize --only-cached /1gb
fadvise /1gb POSIX_FADV_DONTNEED
fincore --pages=false --summarize --only-cached /1gb
на hn:
fincore --pages=false --summarize --only-cached /vz/private/7777777/fs/root/1gb
fadvise /vz/private/7777777/fs/root/1gb POSIX_FADV_WILLNEED
внутри контейнера:
fincore --pages=false --summarize --only-cached /1gb
это и есть реальный файл.
сделайте chroot /vz/private/7777777/fs/root
и у вас будет практически такой же эффект.
>но вот контейнер об этом совсем «не знает»
контейнер — это логическая сущность. для ядра процессы внутри контейнера практически ничем не отличаются от процессов вне его. все эти лимиты ubc — это предок cgroups.
>этот файл реально могут использовать десятки и сотни контейнеров, физически же он будет одним и тем же, при этом в памяти он будет подгружен тоже ровно один раз, вот-только изнутри контейнера вы никогда об этом не знаете
а вот давайте проведем простой эксперимент.
соберите вот это: code.google.com/p/linux-ftools/
точнее, нам понадобится только fincore & fadvise.
берем на hn создаём файл на 1Гб:
dd if=/dev/urandom of=/vz/private/7777777/fs/root/1gb bs=1M count=1024
внутри контейнера:
fincore --pages=false --summarize --only-cached /1gb
/root/1gb bs=1M count=1024
внутри контейнера:
fincore --pages=false --summarize --only-cached /1gb
fadvise /1gb POSIX_FADV_DONTNEED
на hn:
fincore --pages=false --summarize --only-cached /vz/private/7777777/fs/root/1gb
я где-то выше писал про page/dentry cache.
>в контейнерах можно крутить разные дистрибутивы систем, при этом каждый дистрибутив будет иметь вагон своих собственных системных либ, которые будут загружены в память как совершенно разные экземпляры, если конечно эти либы разные.
и? с таким же успехом это можно делать даже в chroot.
>Вас наверное немного запутала моя фраза «один и тот же системный файл»
нет, ни капли. меня запутала ваша фраза
>когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины
вы не могли бы пояснить, что значит «на внешнем уровне запрашивают»?
вообщем, «каждая селедка — рыба. но не каждая рыба — селедка».
сразу видно когда человек понимает о чем пишет :)
меня смутил исходный комментарий
>В Jelastic этот механизм используется также для оптимизации операций ввода-вывода.
т.к. никакой оптимизаций ввода-вывода не происходит и для чтения inode всё равно будет seek по диску.
pfcache больше похож на uksm, только оперирующий файлами(а не страницами, как uksm).
Кстати, а возможно ли лимитировать в Virtuozzo контейнер по iops'ам?
речь не об этом. можете пояснить вот это:
что значит «на внешнем уровне»?
ведь у контейнеров общее ядро(а значит, общие page cache и dentry cache, драйвера итп).
с чего бы вдруг? наберите в гугле хотя бы «zfs prefetch».
думаю, если покопаться, можно найти упоминание этого слова еще во времена SunOS, когда windows еще просто не существовало.
но это всё лирика. в конце-концов, в системе команд IA-32 есть такая инструкция :)
ох, как всё грустно. вообще-то prefetch — это когда нужные вам данные находятся на медленном ресурсе( диски, сеть) и зная что они вам понадобятся в ближайшем будущем вы инициируете их загрузку заранее.
например, чем вам POSIX_FADV_WILLNEED не префетч?
вообще-то у контейнеров нет понятия «хост-машины».
>Этот механизм собирает статистику о файлах, которые чаще всего запрашиваются контейнером, и помещает такие файлы в кэш-память.
это обыкновенный prefetch.
cgroups не имеет отношения к контейнерам просто потому что контейнеры — это просто набор флажков( CLONE_NEWNET, CLONE_NEWPID etc) для вызова clone().
>Чтобы сделать использование ресурсов еще более рациональным, Jelastic использует механизм дедупликации памяти. Этот механизм собирает статистику о файлах, которые чаще всего запрашиваются контейнером, и помещает такие файлы в кэш-память.
что-то я не понял. речь про дедупликацию памяти, а в итоге речь про дисковые операции. wtf?
cgroups(а не cgroup) не имеют отношения к контейнерам вообще.