Я читал документацию, пытаясь понять, когда имеет смысл увеличить размер пула асинхронных потоков с помощью переключателя + A N.
Я отлично готов к тестированию, но мне было интересно, было ли правило большого пальца, когда нужно было подозревать, что увеличение размера пула от 0 до N (или от N до N + M) было бы полезно.
Спасибо
BEAM запускает код Erlang в специальных потоках, который он вызывает планировщиком. По умолчанию он запустит планировщик для каждого ядра вашего процессора. Это можно контролировать и запускать, например, если вы не хотите запускать Erlang на всех ядрах, но "резервируете" некоторые для других вещей. Обычно, когда вы выполняете операцию ввода-вывода файла, она запускается в планировщике и, поскольку операции ввода-вывода файлов относительно медленны, они будут блокировать этот планировщик во время работы. Это может повлиять на свойства реального времени. Обычно вы не делаете много ввода/вывода файлов, поэтому это не проблема.
Асинхронный пул потоков - это потоки ОС, которые используются для операций ввода-вывода. Обычно пул пуст, но если вы используете +A во время запуска, BEAM создаст потоки extra для этого пула. Эти потоки будут использоваться только для операций ввода-вывода файлов, что означает, что потоки планировщика больше не будут блокировать ожидание ввода-вывода файлов и улучшены свойства в реальном времени. Конечно, это связано с тем, что потоки ОС не являются бесплатными. Нити не смешиваются, так что потоки планировщика - это потоки планировщика, а асинхронные потоки - это просто асинхронные потоки.
Если вы пишете связанные драйверы для портов, они также могут использовать пул потоков async. Но вы должны обнаружить, когда они были запущены.
Сколько вам нужно, это очень важно для вашего приложения. По умолчанию ни один из них не запускается. Как и @demeshchuk, я также слышал, что Riak любит иметь большой пул потоков async, поскольку они открывают много файлов. Мой единственный совет - попробовать и измерить. Как и при всей оптимизации?
По умолчанию количество потоков в запущенной Erlang VM равно числу логических ядер процессора (если вы используете SMP, конечно).
По моему опыту, увеличение параметра + A может дать некоторое улучшение производительности, когда у вас много операций ввода-вывода файлов. И я сомневаюсь, что увеличение + A может увеличить общую производительность процессов, поскольку планировщик BEAM чрезвычайно быстр и оптимизирован.
Говоря о точных цифрах - это все зависит от вашего приложения, я думаю. Скажем, в случае Riak, где максимальное количество открытых файлов более или менее предсказуемо, вы можете установить + A на этот максимум или в несколько раз меньше, если он слишком большой (по умолчанию это 64, BTW). Если ваше приложение содержит, например, миллионы файлов, и вы обслуживаете их для веб-клиентов - это другая история; скорее всего, вам может понадобиться запустить некоторые тесты с помощью собственного кода и вашей собственной среды.
Наконец, я считаю, что я никогда не видел + Более ста. Не означает, что вы не можете установить его, но в этом, вероятно, нет смысла.