[noob] вопрос о потоках

вопрос тупейший, оптимальное кол-во нагруженных потоков == колво ядер

если надо часто создавать и убивать - то пул

Возьми да попробуй? Результаты отпиши. Если будет не лениво :) Думаю, остановишься где-то в пределах 5к. Дальше уже тяжело. Это на чем-то навроде 8ми ядерного ксеона средней паршивости. Опять же, это если потоки в массе своей ничего не делают но, скажем, гоняют данные из сокета в сокет. Если же каждый из них что-то считает и действительно кушает CPU, то остановишься на порядки раньше.

> Это на чем-то навроде 8ми ядерного ксеона средней паршивости.

Я недавно на работе любовался инженерным образцом 4-сокетного сервера с 8-ядерными зионами с поддержкой HT. Итого 64 логических процессора. Мечта гентуиста. :)

Я недавно на работе любовался инженерным образцом 4-сокетного сервера с 8-ядерными зионами с поддержкой HT. Итого 64 логических процессора. Мечта гентуиста. :)

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

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

в линуксе, как я помню, нормальных именно что тредов нету (поправьте если не прав).

если нужно именно чтобы была куча процессов - пиши на erlang, там green processes - можно сделать хоть мульйон, реально это будет виртуальная машина запущенная в количестве равном количеству ядер на твоей машине.

Максимальное количетсво потоков, которое держит ОС в пределах пройессе где то задается в конфигах ядра. Если нужно можно изменить. Вроде бы эту цифру можно посмотреть где то в /proc.

Согласен, но наверное с поправкой на гипертридинг еще.

А по поводу максимального количества - тоже просто, размер памяти поделить на размер стека потока. Это то, во что скорее всего упрешься. http://www.kegel.com/c10k.html#threaded - немного по теме.

>о остановишься на порядки раньше.

От жадности потоков к ЦПУ их количетсво не зависит. Просто другие будут получать меньше времени, но запускать ты их сможешь всеравно пока не достигнешь заданного ограничения.

От жадности потоков к ЦПУ их количетсво не зависит. Просто другие будут получать меньше времени, но запускать ты их сможешь всеравно пока не достигнешь заданного ограничения.

А ты попробуй запусти. Жадных. Хотя бы пару-тройку сотен.

в линуксе, как я помню, нормальных именно что тредов нету (поправьте если не прав).

Поправляю, я считаю что именно они в линуксе и есть. И спрашиваю, что такое «нормальные» треды? :-)

если нужно именно чтобы была куча процессов - пиши на erlang, там green processes

+1. Но зеленые есть не только в эрланге, их и на С хватает, вот только со стеком у них как сделано, вот в чем вопрос. Если у каждого потока свой ( а так чаще всего и делают в С ), то память может закончиться довольно быстро, никаких мульонов там не будет.

>А ты попробуй запусти. Жадных. Хотя бы пару-тройку сотен.

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

ты задачу лучше расскажи. может её проще написать без такого количества потоков.

Ядру как-то всеравно, процесс, поток...

Мужик, а в чем разница между потоком и процессом для Linux?

ты задачу лучше расскажи.

Не совсем понял, у меня нет никакой задачи, я не ТС, я отвечал на твой комент. И спрашивал, как в эрланге со стеком на процесс получается (подозреваю, что его там тупо нет).

> От жадности потоков к ЦПУ их количетсво не зависит. Просто другие будут получать меньше времени, но запускать ты их сможешь всеравно пока не достигнешь заданного ограничения.

А ты попробуй запусти. Жадных. Хотя бы пару-тройку сотен.

дело не в жадности потоков, а в их приоритете :)

Ядру как-то всеравно, процесс, поток...

рази? а мне казалось что процесс больше управляющих структур хавает под себя

но с идеологической точки зрения - ja :)

Хм, какие? Вот возьми и расскажи мне в чем разница!

Мужик, а в чем разница между потоком и процессом для Linux?

classic-way: shared flags, conditions etc.

nowdays-way: по последним веяниям (кто-то мне моск дрелил по теме, но не вспомню) поток != зашареный процесс

Ээээ, что значит shared flags?

И кстати, что значит зашареный процесс?

дело не в жадности потоков, а в их приоритете :)

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

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

И кстати, что значит зашареный процесс?

Ну да, есть cs или нет. Это охуенная разница!

> classic-way: shared flags, conditions etc.

nowdays-way: по последним веяниям (кто-то мне моск дрелил по теме, но не вспомню) поток != зашареный процесс

ЩИТО?

Мне всю жизнь казалось, что единственная разница - это адресное пространство сущности. У каждого процесса своё, а треды шарят.

пару флагов CLONE_*

О, тут есть адекватики!

Да, фактически разница только в том, выделаня ли vm или нет для task. Фактически разница в цене по переключению контекста будет определяться только этим.

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

А зачем мсье НЕСКОЛЬКО ТЫСЯЧ потоков, чтобы отправлять данные по сети? Асинхронные вызовы чем плохи?

Что такое флаги CLONE_*?

> вопрос тупейший, оптимальное кол-во нагруженных потоков == колво ядер

а почему тогда gcc советуют настраивать на кол-во ядер + 1 или +2?

Это надо понимать событийную модель. А когда на лоре тебя тролят, тебе не до этого. Тут главное побыстрее призвать через любимую асечку побольше друзей, что бы ссаными тряпками закидали обидчика!

Кто советует? Как это настроить gcc?

я имел ввиду разницу создания процессов потоков для ядра

А зачем мсье НЕСКОЛЬКО ТЫСЯЧ потоков, чтобы отправлять данные по сети? Асинхронные вызовы чем плохи?

Плохи их отсутствием в более высокоуровневых интерфейсах. Например к базе (mysql/pgsql/etc).

Смотри, я говорю про task в контексте userspace. Вопрос: чем отличаются task-proccess и task-thread?

> а почему тогда gcc советуют настраивать на кол-во ядер + 1 или +2?

Ой, а можно ссылочку на поподробней? /me сгорает от любопытства.

в сишном драйвере есть для mysql есть асинхронный режим. И там очень просто взять fd коннекта и сунуть его в epoll fd твоего приложения, например.

В чем проблема, чувак?

хм, ну в «венде» так:

поток держит объект ядра (для управления) и стек (для хранения параметров функций, локальных переменных etc.)

процесс, являющийся контейнером для исполнения потоков, хранит в себе довольно большую кучу служебной информации и управляющих структур, а именно там хранится, как минимум, таблица описателей объектов ядра (которые чтобы всем стало весело могут разделяться через проекции файлов для совместного использования различными потоками со всеми вытекающими), переменные окружения, куча барахла связанного собственно с организацией виртуального адресного пространства и самый шик, по этому всему ещё и считается статистика

ну и т.д.

А мы разве тут про windows?

В линуксе точно также. Только у линукса есть copy-on-write и потому fork дешёвый =)

в сишном драйвере есть для mysql есть асинхронный режим. И там очень просто взять fd коннекта и сунуть его в epoll fd твоего приложения, например.

А именно?

В чем проблема, чувак?

Тем, что база - это лишь часть системы? И сама по себе модель асинхронного доступа к базе мягко говоря влияет на весь дизайн? Причем ни разу нелинейно и не факт, что тривиально. А там в очереди влиятелей ещё десятка два кандидатов стоят и все нервно дышат в затылок..

В линупсе есть еще sendfile например, что позволяет не заниматься копированием даных за сискол!

Ээээ, что значит shared flags?

лень было морщить лоб, имелось в виду общее адресное пространство и дескрипторы :)

> Тем, что база - это лишь часть системы? И сама по себе модель асинхронного доступа к базе мягко говоря влияет на весь дизайн? Причем ни разу нелинейно и не факт, что тривиально. А там в очереди влиятелей ещё десятка два кандидатов стоят и все нервно дышат в затылок..

Всё равно больше нескольких десятков-сотен-тысяч (в зависимости от железа) подключений поставят СУБД (оптимизатор) в позу. connection pool, и никак иначе.

>> в сишном драйвере есть для mysql есть асинхронный режим. И там очень просто взять fd коннекта и сунуть его в epoll fd твоего приложения, например.

А именно?

Этот момент я не понял.

В чем проблема, чувак?

Тем, что база - это лишь часть системы? И сама по себе модель асинхронного доступа к базе мягко говоря влияет на весь дизайн? Причем ни разу нелинейно и не факт, что тривиально. А там в очереди влиятелей ещё десятка два кандидатов стоят и все нервно дышат в затылок..

Да, влияет. Вы делаете сфирический дизай с 10 тысячами потоков? Вам бы учесть архитектурные ограничения, немного, попа была бы целей, в целом

Всё равно больше нескольких десятков-сотен-тысяч (в зависимости от железа) подключений поставят СУБД (оптимизатор) в позу. connection pool, и никак иначе.

Нет ну зачем, на одну базу не больше пары десятков сессий. Ну сотня ну две. Но не тысячи конечно же. Но ведь сервер баз данных не обязательно должен быть один, правда? :)

Не, ну нихуя себе одинаково.

Это нифига не флаги. Флаги это капы там, или прочие селинукс роли. Но никак не адресной пространство.

Мужик, это мускуль, в нем нет оптимизатора.

Вопрос: чем отличаются task-proccess и task-thread?

Фактически ничем.

в сишном драйвере есть для mysql есть асинхронный режим.

Ссылку сестра на API? Просто любопытно. Только что в тысячный раз пробежался по C API 5.0.x - нету такого.

И там очень просто взять fd коннекта и сунуть его в epoll fd твоего приложения, например.

А именно?

Этот момент я не понял.