Каково оптимальное количество потоков для выполнения операций IO в Java?

Защищенная память. Перед защищенной памятью, если Ваша программа сделала ошибку, Вы могли бы начать выполнять код где угодно - фактически всегда зависание всей машины. Правильно, время перезагрузки!

Низкая стоимость аппаратных средств. Мой первый компьютер стоил 500$ в 1978-огромная сумма в то время. Понижение затрат поместило ПК на каждый стол.

16
задан 6 August 2009 в 17:21
поделиться

7 ответов

На практике приложения с привязкой к вводу-выводу все еще могут существенно выиграть от многопоточности, поскольку чтение или запись нескольких файлов может быть намного быстрее, чем последовательно. Это особенно актуально, когда общая пропускная способность снижается из-за задержки сети. Но также бывает, что один поток может обрабатывать последнее, что он прочитал, в то время как другой поток занят чтением, что позволяет повысить загрузку ЦП.

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

11
ответ дан 30 November 2019 в 21:46
поделиться

Да, 20 потоков определенно могут записывать на диск быстрее, чем 4 потока на машине с 4 ЦП. Многие реальные программы связаны с вводом-выводом больше, чем с процессором. Однако это во многом зависит от ваших дисков и от того, сколько работы ЦП выполняют ваши другие потоки, прежде чем они тоже закончат ожидание на этих дисках.

Если все ваши потоки только записывают на диск и больше ничего не делают, тогда вполне может быть, что 1 поток на машине с 4 процессорами на самом деле является самым быстрым способом записи на диск. Это полностью зависит от того, сколько у вас дисков, сколько данных вы пишете и насколько хорошо ваша ОС выполняет планирование ввода-вывода. Ваш конкретный вопрос предполагает, что вы хотите, чтобы все 4 потока писали в один и тот же файл. Это не имеет особого смысла, и в любом практическом сценарии я не могу представить, как это будет быстрее. (Вы' Если вам нужно выделить файл заранее, тогда каждый поток будет искать () в другой позиции, и вы закончите тем, что просто перебейте головку записи, когда каждый поток попытается записать несколько блоков.)

Преимущество многопоточности намного проще, когда вы привязаны к сети. То есть: ожидание на сервере базы данных, или в веб-браузере, и т.п. Здесь вас ждут несколько внешних ресурсов.

4
ответ дан 30 November 2019 в 21:46
поделиться

Как и все, что связано с производительностью, это зависит.

Если вы ограничены вводом-выводом, то добавление потоков вам вообще не поможет. (Хорошо, как указывает Стивен Судит , вы можете получить повышение производительности, но оно будет небольшим) Если вы не привязаны к вводу-выводу, то добавление потоков может помочь

Не пытайтесь быть умным, но лучший способ выяснить это - профилировать его и посмотреть, что работает в ваших конкретных обстоятельствах.

Изменить: Обновлено на основе на комментарии

3
ответ дан 30 November 2019 в 21:46
поделиться
3
ответ дан 30 November 2019 в 21:46
поделиться

Ncpu + ожидаемое количество одновременных операций ввода-вывода - мое обычное число.

Дело не в том, что 20 потоков могут записать один файл на диск быстрее, чем 4 потока. Если у вас есть только 1 поток на ЦП, то во время записи на диск ваш процесс не сможет использовать ЦП, на котором размещен поток, выполняющий ввод-вывод файла. Этот ЦП фактически ожидает записи файла, тогда как, если у вас есть еще один поток, он может использовать ЦП для выполнения реальной обработки в промежутке.

1
ответ дан 30 November 2019 в 21:46
поделиться

Это ошибка в Rails 2.3.3:

В 2-3-стабильной есть исправление (но неполное?) для этого:

У вас есть несколько вариантов решения проблемы:

  • Вернуться к Rails 2.3.2 , дождитесь выхода 2.3.4, вероятно, в конце августа. В 2.3.3 есть пара плохих проблем, так что это может быть лучше всего.
  • Проблема не должна возникать в производственном режиме, а также в режиме разработки на Тонком сервере . Если у вас возникла эта проблема в Google Engines в рабочем режиме, патч - ваша единственная надежда. Если это только в режиме разработки, вы можете просто запустить свой локальный сервер с помощью Thin вместо Mongrel.
  • Если это Google Engines, вы можете выйти из Google Engines и разместить свое приложение другим способом . Хотя это кажется большой работой.

Удачи, это действительно плохая ошибка, с которой сталкиваются многие люди.

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

Например, представьте, что вы отправляете несколько файлов множеству разных получателей по сети. Вы по-прежнему привязаны к сети, поэтому ваша максимальная скорость не будет выше, чем, скажем, 100 Мбит / с, но если вы используете 20 потоков, то процесс будет намного более справедливым.

0
ответ дан 30 November 2019 в 21:46
поделиться

Если вы используете синхронный ввод-вывод, тогда у вас должен быть один поток для каждого одновременного запроса ввода-вывода, который может обрабатывать ваша машина. В случае одного жесткого диска с одним шпинделем это 1 (вы можете читать или писать, но не оба одновременно). Для диска, который может обрабатывать множество запросов ввода-вывода одновременно, это будет столько запросов, сколько он может обрабатывать одновременно.

Другими словами, это не ограничено счетчиком ЦП, поскольку ввод-вывод на самом деле не влияет на ЦП помимо отправки запросов и ожидания. Более подробное объяснение см. Здесь.

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

тогда у вас должен быть один поток для каждого запроса одновременного ввода-вывода, который может обрабатывать ваша машина. В случае одного жесткого диска с одним шпинделем это 1 (вы можете читать или писать, но не оба одновременно). Для диска, который может обрабатывать множество запросов ввода-вывода одновременно, это будет столько запросов, сколько он может обрабатывать одновременно.

Другими словами, это не ограничено счетчиком ЦП, поскольку ввод-вывод на самом деле не влияет на ЦП помимо отправки запросов и ожидания. Более подробное объяснение см. Здесь.

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

тогда у вас должен быть один поток для каждого запроса одновременного ввода-вывода, который может обрабатывать ваша машина. В случае одного жесткого диска с одним шпинделем это 1 (вы можете читать или писать, но не оба одновременно). Для диска, который может обрабатывать множество запросов ввода-вывода одновременно, это будет столько запросов, сколько он может обрабатывать одновременно.

Другими словами, это не ограничено счетчиком ЦП, поскольку ввод-вывод на самом деле не влияет на ЦП помимо отправки запросов и ожидания. Более подробное объяснение см. Здесь.

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

это будет столько запросов, сколько он может обрабатывать одновременно.

Другими словами, это не ограничено счетчиком ЦП, поскольку ввод-вывод на самом деле не влияет на ЦП, кроме отправки запросов и ожидания. Более подробное объяснение см. Здесь.

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

это будет столько запросов, сколько он может обрабатывать одновременно.

Другими словами, это не ограничено счетчиком ЦП, поскольку ввод-вывод на самом деле не влияет на ЦП, кроме отправки запросов и ожидания. Более подробное объяснение см. Здесь.

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

2
ответ дан 30 November 2019 в 21:46
поделиться
Другие вопросы по тегам:

Похожие вопросы: