Здравствуйте, Shmj, Вы писали:
S>А чем плохо пул из 1 млн. потоков? Они же не будут создаваться без необходимости?
Почему не будут. Когда у тебя стоит ограничение, то лишние задачи встают в очередь и новых потоков не создается,
а когда нет и много одновременных задач не встают в очередь и есть затраты на создание потока и на переключение между потоками http://rsdn.org/forum/philosophy/8038767.1
Здравствуйте, Shmj, Вы писали: S>А чем плохо пул из 1 млн. потоков
Caution
By default, the minimum number of threads is set to the number of processors on a system. You can use the SetMinThreads method to increase the minimum number of threads. However, unnecessarily increasing these values can cause performance problems. If too many tasks start at the same time, all of them might appear to be slow. In most cases, the thread pool will perform better with its own algorithm for allocating threads. Reducing the minimum to less than the number of processors can also hurt performance.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Ну да. Пул из 1000 потоков это коронное решение? S>>По моему мое решение с профайлером намного оптимальнее!
S>А чем плохо пул из 1 млн. потоков? Они же не будут создаваться без необходимости?
Один поток — 4MB на стек для x64. Множим на миллион и уходим в своп. Или точнее в никуда, 4 терабайта это серьезно
Здравствуйте, Shmj, Вы писали:
S>Создал 10 тыс. потоков в ожидании, заняло 270 Мб. памяти. Получается примерно по 27 Кб на поток. Так что не так страшен черт...
А можно скрин соотв. фото из Process Exploer'а, ибо 270Мб это физически потребленная память,
а виртуально там 10^4 * 10^6 байт (10Гб вроде?).
Здравствуйте, Sharov, Вы писали:
S>А можно скрин соотв. фото из Process Exploer'а, ибо 270Мб это физически потребленная память, S>а виртуально там 10^4 * 10^6 байт (10Гб вроде?).
Запустите код и сообщите что увидели, вам это тоже нужно знать:
private static List<Thread> _threads = new List<Thread>();
static async Task Main(string[] args)
{
ThreadPool.SetMinThreads(1000000, 1);
for (int i = 0; i < 10000; i++)
{
var t = new Thread(() =>
{
Thread.Sleep(100000);
})
{IsBackground = true};
t.Start();
_threads.Add(t);
}
Console.WriteLine("Done");
Console.ReadKey();
}
Здравствуйте, Shmj, Вы писали:
S>>А можно скрин соотв. фото из Process Exploer'а, ибо 270Мб это физически потребленная память, S>>а виртуально там 10^4 * 10^6 байт (10Гб вроде?). S>Запустите код и сообщите что увидели, вам это тоже нужно знать:
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Danchik, Вы писали:
S>>>А чем плохо пул из 1 млн. потоков? Они же не будут создаваться без необходимости? D>>Один поток — 4MB на стек для x64.
S>Вроде бы 1Мб всегда был? Или в core что-то поменялось?
Ну так что? Сколько реально потребили 10 тыс. потоков? Вряд ли у вас в приложении столько будет, верно?
S>Ну и, кучу виртуальной памяти зарезервировано.
Что жалко что ли на 64 битке она практически бесконечна.
Здравствуйте, Shmj, Вы писали:
S>Что жалко что ли на 64 битке она практически бесконечна.
Проблема не в памяти, а в создании и переключении потоков.
И не забывай в твоем варианте метод практически не использует данных, а вот если будет использовать стек то он и физически будет расти.
То есть ты сознательно тормозишь свое приложения. Вместо того что бы при большом одновременном количестве запросов ставить их в очередь ты запускаешь новые или берешь древние потоки.
Там и кэш процессора сбрасывается. Переключение контекста и производительность
Кроме того, что очень важно, при переключении контекста происходят следующие программно-незаметные аппаратные действия, влияющие на производительность:
Происходит очистка конвейера команд и данных процессора
Очищается TLB, отвечающий за страничное отображение линейных адресов на физические.
Кроме того, следует учесть следующие факты, влияющие на состояние системы:
Содержимое кэша (особенно это касается кэша первого уровня), накопленное и «оптимизированное» под выполнение одного потока, оказывается совершенно неприменимым к новому потоку, на который происходит переключение.
При переключении контекста на процесс, который до этого долгое время не использовался (см. Подкачка страниц), многие страницы могут физически отсутствовать в оперативной памяти, что порождает подгрузку вытесненных страниц из вторичной памяти.
Ну и если задачи короткие то они могут быть соизмеремы с временем переключения контекста
и солнце б утром не вставало, когда бы не было меня
D>Один поток — 4MB на стек для x64. Множим на миллион и уходим в своп. Или точнее в никуда, 4 терабайта это серьезно
Оно почти не кушает памяти само по себе, выделение страниц идет по требованию, а адресного пространства которое действительно выделяется -вагон.
S>>Что жалко что ли на 64 битке она практически бесконечна. S> Проблема не в памяти, а в создании и переключении потоков. S> И не забывай в твоем варианте метод практически не использует данных, а вот если будет использовать стек то он и физически будет расти. S>То есть ты сознательно тормозишь свое приложения. Вместо того что бы при большом одновременном количестве запросов ставить их в очередь ты запускаешь новые или берешь древние потоки. S>Там и кэш процессора сбрасывается.
По ссылке не ходил, но речь идет о процессах, а не о потоках -- потоки как раз придумали, чтобы не сбрасывать
кэш и т.п. Т.е. переключение процессов дорого, а потоков в процессе -- нет.
Здравствуйте, Sharov, Вы писали:
S>По ссылке не ходил, но речь идет о процессах, а не о потоках -- потоки как раз придумали, чтобы не сбрасывать S>кэш и т.п. Т.е. переключение процессов дорого, а потоков в процессе -- нет.
Согласен, но процессов то может быть и не один. И так гонок за процессорное время будет больше
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>По ссылке не ходил, но речь идет о процессах, а не о потоках -- потоки как раз придумали, чтобы не сбрасывать S>>кэш и т.п. Т.е. переключение процессов дорого, а потоков в процессе -- нет. S>Согласен, но процессов то может быть и не один. И так гонок за процессорное время будет больше
Речь идет о потоках в процессе. Остальное не интересно.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>По ссылке не ходил, но речь идет о процессах, а не о потоках -- потоки как раз придумали, чтобы не сбрасывать S>>>кэш и т.п. Т.е. переключение процессов дорого, а потоков в процессе -- нет. S>>Согласен, но процессов то может быть и не один. И так гонок за процессорное время будет больше
S>Речь идет о потоках в процессе. Остальное не интересно.
Да но, переключаться то приходится и на другие потоки процессов. Суть то в том, что хотят выделять пул потоков без ограничения.
А вот тут то как раз и возникают проблемы при переключении с на потоки с других процессов, гонки за потоки
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>Речь идет о потоках в процессе. Остальное не интересно. S>Да но, переключаться то приходится и на другие потоки процессов. Суть то в том, что хотят выделять пул потоков без ограничения. S>А вот тут то как раз и возникают проблемы при переключении с на потоки с других процессов, гонки за потоки
Переключение между потоками дешево по сравнению с процессами.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>Речь идет о потоках в процессе. Остальное не интересно. S>>Да но, переключаться то приходится и на другие потоки процессов. Суть то в том, что хотят выделять пул потоков без ограничения. S>>А вот тут то как раз и возникают проблемы при переключении с на потоки с других процессов, гонки за потоки
S>Переключение между потоками дешево по сравнению с процессами.
Еще раз, для других процессов разве не нужны ядра для переключения на свои потоки?
И разве не ббудет гонок за потками если бездумно выделять огромное количество в пуле потоков?
и солнце б утром не вставало, когда бы не было меня
