LINUX.ORG.RU

Потоки vs Процессы


0

0

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

Где-то читал что ничего плодить ненадо, а всё через poll делать ... ???

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

И ещё как быть если планируется огромное кол-во входящих соединений. Насколько знаю надо увеличить кол-во возможных дескрипторов? Может ещё что-то?

Спасибо.

anonymous

> Где-то читал что ничего плодить ненадо, а всё через poll делать ... ???

Да, потоков должно быть столько же сколько и ядер да и то только тогда когда увидишь, что проседает у тебя процессор, а не сеть.

> В нете искал, но еслиесть человек который с такого рода задачами сталкивался, буду благодарен за авторитетный ответ.

смотри примеры к libevent и/или boost/asio

> Насколько знаю надо увеличить кол-во возможных дескрипторов?

да, путем правки /etc/security/limits.conf

Reset ★★★★★
()

если слишком много входящих соедиений, то открывать тысячи даже потоков любой ОС будет сложно

namezys ★★★★
()
Ответ на: комментарий от namezys

> если слишком много входящих соедиений, то открывать тысячи даже потоков любой ОС будет сложно

ну линукса в принципе держит несколько тысяч потоков и вполне стабильно это делает. другой вопрос - надо ли это..

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

// ну линукса в принципе держит несколько тысяч потоков

Все держим. Но там, где щас 1000, завта будет 10 000, а через месяц и вся сотня

Ну другие причины писать не буду

namezys ★★★★
()
Ответ на: комментарий от klalafuda

>ну линукса в принципе держит несколько тысяч потоков и вполне стабильно это делает. другой вопрос - надо ли это..

Если нужны десятки/тысячи потоков - то это прямая дорога в Erlang :) В остальных случаев - пулы. При несложных задачах десятки потоков могут обрабатывать сотни и тысячи клиентов.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Ну можно попытаться реализовать что-то похожее на базе пулов потоков

В любом случае, тута не ситуация один поток - одна задача, Множенье потов надо для равномерной загрузки камней

namezys ★★★★
()
Ответ на: комментарий от KRoN73

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

да могут конечно. правда, с одним но: если им в процессе обработки не приходится общаться с задумчивыми синхронными вызовами. к примеру, лезть в MySQL базу через libmysqlclient [+ через сеть].

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

>> если им в процессе обработки не приходится общаться с задумчивыми синхронными вызовами.

А зачем это делать синхронно?

namezys ★★★★
()
Ответ на: комментарий от klalafuda

Интересно! допустим: - для обработки коннекта надо лезть на сервак с MySQL. - одновременных соединений может быть тысячи.

тогда как быть? использовать потоки для соединений или в через poll делать?

Спасибо за ваши ответы!

anonymous
()
Ответ на: комментарий от namezys

>В любом случае, тута не ситуация один поток - одна задача

В L2Fortress у нас использовался такой механизм. Стоит небольшой пул соединений с клиентами. Клиент присылает пакет. Сервер (в смысле - pool-часть) формирует runnable-объект для этого пакета и отправляет исполняться отдельным потоком. В результате и число одновременно работающих потоков невелико, так как клиенты шлют пакеты не непрерывно, и клиентов может быть много, и время отклика хорошее, и оба (у меня только два было) процессора грузятся.

KRoN73 ★★★★★
()
Ответ на: комментарий от klalafuda

>с одним но: если им в процессе обработки не приходится общаться с задумчивыми синхронными вызовами

Да, есть такое. У нас задачи простые были в этом смысле. Все объекты, отображаемые на MySQL глобальные и грузятся/выгружаются нечасто.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Я тута для С++ написал топик

И тама преложил ... точнее что-то написал из того что у меня для такого есть

есть много идей как это развить

namezys ★★★★
()
Ответ на: комментарий от klalafuda

> а как мне исполнить SQL запрос на сервере MySQL асинхронно?

А оно что, не умеет?

тама разве не сеть лежит?

namezys ★★★★
()
Ответ на: комментарий от namezys

> А оно что, не умеет? тама разве не сеть лежит?

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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от namezys

> Хм. Я правда не знал что не умеет

не умеет. и постгрес AFAIR не умеет, и сибейз. да собственно я и не припомню примеров тех, кто умеет. a'la разядил SQL запрос, задал ему калбек и ждёшь, когда он его там дёрнет. или в этом духе. видимо, такое де-факто не очень то и нужно народу, а в реализации при этом дюже муторно.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

> такое де-факто не очень то и нужно народу, а в реализации при этом дюже муторно.

Не знаю

Хотя тута вопрос сложный, нужно или нет

смотря сколько времени отводится на выполнение запроса/его обработку

namezys ★★★★
()

В зависимости от операционной системы.. Смотреть в сторону thread pooling для универсальности..

MiracleMan ★★★★★
()
Ответ на: комментарий от namezys

>> такое де-факто не очень то и нужно народу, а в реализации при этом дюже муторно.

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

anonymous
()
Ответ на: комментарий от anonymous

> Не нужно либе делать то, что клиент либы может сделать сам: запускаешь тред для общения с базой, даешь ему задание и коллбек. Сам делаешь что-то еще - когда тред получит ответ от базы - дернет коллбек. Вот вам и асинхронный вызов либы.

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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

>ну линукса в принципе держит несколько тысяч потоков и вполне стабильно это делает. другой вопрос - надо ли это..

В контексте linux "Потоки vs Процессы" никакого смысла не имеет потому что они тут ничем не отличаются.

anonymous
()
Ответ на: комментарий от anonymous

> В контексте linux "Потоки vs Процессы" никакого смысла не имеет потому что они тут ничем не отличаются.

ой ли? так уж и ни чем? :)

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от MiracleMan

> он имел в виду затраты.

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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

>ну мне сложно судить о том, что же именно имел ввиду анонимус. будем надеяться, что со временем он пояснит своё высказывание.

Лично я понял его именно так.. А, вообщем, да, согласен..

MiracleMan ★★★★★
()
Ответ на: комментарий от klalafuda

Поток - это тот же процесс который использует совместно ресурсы с другим процессом, имеет свою task_struct. Для ядра нет никакой разницы между потоками и процессами.

anonymous
()
Ответ на: комментарий от anonymous

> Поток - это тот же процесс который использует совместно ресурсы с другим процессом, имеет свою task_struct. Для ядра нет никакой разницы между потоками и процессами.

и лимиты на ресурсы надо полагать у них отрабатывают одинаково...

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от MiracleMan

Вернее, в нормальной ситуации это не так - man IPC..

MiracleMan ★★★★★
()
Ответ на: комментарий от klalafuda

При чем ту вообще лимиты на ресурсы ? Лимиты как правило обусловлены физической составляющей а не виртуальными ресурсами. В этом одно из коренных отличий linux от других ос - там потоки это некая абстракция, более легкий вариант процесса. В linux - все процессы.

anonymous
()
Ответ на: комментарий от anonymous

> При чем ту вообще лимиты на ресурсы ? Лимиты как правило обусловлены физической составляющей а не виртуальными ресурсами. В этом одно из коренных отличий linux от других ос - там потоки это некая абстракция, более легкий вариант процесса. В linux - все процессы.

man ulimit

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

>man ulimit

Ну и - дальше что ? Я что-то мысли не понял. Как у эллочки - мрак, блеск, парниша ?

anonymous
()
Ответ на: комментарий от klalafuda

> что такой подход не вяжется с "централизованной раздачей" событий через диспачер.

Т.е. хочется, чтобы при обработке события от диспатчера, в случае обращения к базе
1) вызвать либу (которая должна послать запрос к базе и сразу вернуть управление не дожидаясь ответа)
2) зарегистрировать (у того же диспатчера) новое задание проверки ответа базы + коллбек продолжения обработки события
3) вернуть управление диспатчеру.

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

anonymous
()
Ответ на: комментарий от klalafuda

> что такой подход не вяжется с "централизованной раздачей" событий через диспатчер. точнее вяжется, но как то через ж. искусственно.

В twisted вяжется и вполне естесственно.

anonymous
()
Ответ на: комментарий от anonymous

>Разве с приходом NPTL от этого отказались, нет?

На ЛОРе видимо отказались - а в остальном мире нет :) С приходом nptl реализацию потоков из юзерспейса перенесли на ядро. А там каждый поток - это отдельный процесс, они группируются и все потоки-процессы имеют одинаковый идентификатор группы - пид первого процесса этой группы.

anonymous
()
Ответ на: комментарий от anonymous

epoll руками дергать не кошерно. Держи курс на libev

redbaron ★★
()
Ответ на: комментарий от klalafuda

> не умеет. и постгрес AFAIR не умеет, и сибейз. да собственно я и не припомню примеров тех, кто умеет. a'la разядил SQL запрос, задал ему калбек и ждёшь, когда он его там дёрнет. или в этом духе. видимо, такое де-факто не очень то и нужно народу, а в реализации при этом дюже муторно.

постгрес умеет, только не калбек, а типа poll. см. http://www.postgresql.org/docs/current/static/libpq-async.html

Eshkin_kot ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.