Pull to refresh

Comments 4

«Код простой и последовательный, без volatile, Atomic*, contention и прочего»
А AtomicBoolean хорошо спрятался?

Действительно, единственный AtomicBoolean присутствует в абстрактном Actor, от которого наследуются все прикладные акторы. Правильнее было бы сказать, что в прикладном коде никакой синхронизации нет.

Интересная статья. Судя по тому, что на 56 ядрах работают 200 потоков, блокирующие операции все-таки имеются. И я подозреваю, что это блокирующим является jni вызов sendfile. Небольшое гугление показывает, что у sendfile есть асинхронный аналог под FreeBSD, разработанный компанией Netflix. Очевидно, у них в этом же месте был ботлнек. Возможно под линуксом это тоже уже появилось, но я не в курсе.

Спасибо.
Действительно, вызов sendfile() блокируется на время чтения с диска (при отсутствии данных в дисковом кеше). Но по результатам профилирования раздатчика под нагрузкой sendfile() не является проблемой — он обслуживает proxy-запросы (HTTP) и ненадолго блокируется только в 10-20% случаях (page cache miss) на чтении с SSD.
В нашем случае количество потоков большее числа ядер в первую очередь объясняется использованием независимых пулов для различных стадий конвейера, чтобы повысить управляемость и наблюдаемость системы.
Но и блокирующие операции, конечно, присутствуют — в частности, в докладе рассматривается чтение блоков с дисков для отправки в клиентский SSL-сокет, когда мы не можем использовать sendfile(). Кроме того, запись блоков из OBS/OCS на диск при cache miss является блокирующей.

Sign up to leave a comment.