Akka jvm threads vs os threads при выполнении io

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

У меня вопрос о масштабировании потоков jvm vs os при использовании в akka для операций io. С сайта akka:

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

Актеры, основанные на событиях, в настоящее время потребляют ~ 600 байт на актер, что означает, что вы можете создать более 6,5 миллионов актеров в 4-граммовом ОЗУ.

В этом контексте вы можете помочь мне понять, как это важно на рабочей станции с одним процессором (для простоты). Итак, для моего примера использования, я хочу взять список из 1000 "Пользователи", а затем обратиться к базе данных (или нескольким) для получения различной информации о каждом пользователе. Итак, если бы я отправлял каждую из этих задач "получить" актеру, и этот актер собирается выполнять IO, не будет ли этот блок действий основан на пределе потока os для рабочей станции?

Как актерская модель акка подталкивает меня к подобному сценарию? Я знаю, что я, вероятно, что-то пропустил, потому что я не очень хорошо разбираюсь в взаимодействиях vm threads vs os threads, поэтому, если один из умных людей здесь может записать это для меня, это было бы здорово.

Если я использую Futures, не нужно ли использовать wait() или get() для блокировки и ждать ответа?

В моем случае использования, независимо от актеров, получилось бы просто "чувство", как будто я делаю 1000 последовательных запросов к базе данных?

Если код справки полезен, чтобы помочь мне понять это, Java будет предпочтительнее, поскольку я все еще набираю скорость на синтаксисе scala, но явное текстовое объяснение того, как эти миллионы потоков могут взаимодействовать на одном процессоре машина при выполнении базы данных IO тоже будет хорошо.

Ответ 1

Очень сложно понять, что вы на самом деле задаете здесь, но вот несколько указателей:

Если вы работаете в современной JVM, обычно существует связь один-к-одному между потоками Java и потоками ОС. (IIRC, Solaris позволяет вам делать это по-другому... но это исключение.)
Объем реального parallelism, который вы получите, используя потоки, или что-либо, построенное поверх потоков, ограничено количеством процессоров/ядер, доступных для приложения. Кроме того, вы обнаружите, что не все потоки фактически выполняются в любой момент времени.
Если у вас есть 1000 Актеров, пытающихся одновременно получить доступ к базе данных, большинство из них будут на самом деле ждать в самой базе данных или в планировщике потоков. Независимо от того, будет ли это делать 1000 последовательных запросов (т.е. Строгая сериализация), будет зависеть от базы данных и запросов/обновлений, которые делают актеры.

Суть в том, что компьютерная система имеет жесткие ограничения на ресурсы, доступные для работы; например количество процессоров, скорость процессоров, пропускную способность памяти, время доступа к диску, пропускную способность сети и т.д. Вы можете разработать приложение, чтобы быть умным в том, как он использует доступные ресурсы, но вы не можете заставить его использовать больше ресурсов, чем на самом деле есть.

При чтении текста, который вы цитировали, мне кажется, что речь идет о двух разных актерах:

Участники на основе потоков имеют отношение 1 к 1 с потоками. Невозможно иметь миллионы таких актеров в памяти 4Gb.

Участники, основанные на событиях, работают по-разному. Вместо того чтобы иметь поток во все времена, они в основном сидели в очереди, ожидая события. Когда это произошло, поток обработки событий захватит актера из очереди и выполнит "действие", связанное с событием. Когда действие закончено, поток перемещается на другую пару actor/event.

В цитируемом тексте говорится, что накладные расходы на память для актера, основанного на событиях, составляют ~ 600 байт. Они не включают поток событий... потому что поток событий разделяется несколькими участниками.

Теперь я не эксперт по Scala/Актерам, но довольно очевидно, что есть определенные вещи, которых следует избегать при использовании актеров, основанных на событиях. Например, вам, вероятно, следует избегать прямого обращения к внешней базе данных, поскольку это может блокировать поток обработки событий.

Ответ 2

Я думаю, там может быть опечатка. Я думаю, они хотели сказать:

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

Участники, управляемые событиями, используют пул потоков - все (потенциально миллионы) участников имеют один и тот же пул потоков. Я не знаком с акковыми акками, но, как правило, вы не хотели бы блокировать ввод-вывод с актерами, управляемыми событиями, иначе вы могли бы вызвать голод.