диалог с любителями потоков
От: sluge  
Дата: 01.07.09 06:09
Оценка: :)
постоянно сталкиваюсь с персонажами, которых я про себя называю "любители потоков". Этих людей отличает то что они для любой функциональности считают нужным заводить отдельный поток. И ладно еще если этих потоков будет гораниченное число-например поток на работу с сетью, поток на работу с БД. Бывает так что скажем хочет человек написать web-сервер и говорит-а дай ка я на каждое соединение заведу себе поток. Потом следуя своей стратегии, на каждое соединение заводится 2,3 и так далее потоков. Таким образом получается что при скажем 1000 соединений в системе будет 1000*n потоков. Кто что думает по этому поводу, и есть ли тут такие любители потоков?
Re: диалог с любителями потоков
От: Mr.Cat  
Дата: 01.07.09 06:17
Оценка:
А why, собственно, и not? Эрланг же.
Re[2]: диалог с любителями потоков
От: sluge  
Дата: 01.07.09 06:29
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>А why, собственно, и not? Эрланг же.


а если с++ или жаба?
Re[3]: диалог с любителями потоков
От: Mr.Cat  
Дата: 01.07.09 06:39
Оценка: +2
Здравствуйте, sluge, Вы писали:
S>а если с++ или жаба?

Мой поинт в том, что с философской точки зрения большое количество "потоков" — вполне нормальный подход.
Понятное дело, что для такого подхода нужно выбирать соответствующие средства реализации. Будь то green threads или грамотно используемый пул потоков.
Re: диалог с любителями потоков
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 01.07.09 06:54
Оценка:
Здравствуйте, sluge, Вы писали:

S>постоянно сталкиваюсь с персонажами, которых я про себя называю "любители потоков". Этих людей отличает то что они для любой функциональности считают нужным заводить отдельный поток. И ладно еще если этих потоков будет гораниченное число-например поток на работу с сетью, поток на работу с БД. Бывает так что скажем хочет человек написать web-сервер и говорит-а дай ка я на каждое соединение заведу себе поток. Потом следуя своей стратегии, на каждое соединение заводится 2,3 и так далее потоков. Таким образом получается что при скажем 1000 соединений в системе будет 1000*n потоков. Кто что думает по этому поводу, и есть ли тут такие любители потоков?

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

Вообще, интересно, где это вы "постоянно сталкиваетесь" с такими персонажами.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[3]: диалог с любителями потоков
От: SkyDance Земля  
Дата: 01.07.09 07:55
Оценка:
S>а если с++ или жаба?

В С++, особливо на виндах, — проблема. Стек на 1000 процессов выест 1000 * 10 Мб (по дефолту) = 10 Гб виртуальной памяти, в 32 бита (2 Гб предел) уже не лезет. Проблема реально существует, мы с ней боролись. Сначала уменьшением аппетитов (до 1 Мб стека), потом стало понятно, что делу это не поможет и консолидировали потоки. Стало намного лучше работать.
Re[4]: диалог с любителями потоков
От: jedi Мухосранск  
Дата: 01.07.09 08:09
Оценка: +2
Здравствуйте, SkyDance, Вы писали:

S>>а если с++ или жаба?


SD>В С++, особливо на виндах, — проблема. Стек на 1000 процессов выест 1000 * 10 Мб (по дефолту) = 10 Гб виртуальной памяти, в 32 бита (2 Гб предел) уже не лезет. Проблема реально существует, мы с ней боролись. Сначала уменьшением аппетитов (до 1 Мб стека), потом стало понятно, что делу это не поможет и консолидировали потоки. Стало намного лучше работать.


МСДН говорит 1 мегабайт по умолчанию на поток:

The default size for the reserved and initially committed stack memory is specified in the executable file header. Thread or fiber creation fails if there is not enough memory to reserve or commit the number of bytes requested. The default stack reservation size used by the linker is 1 MB. To specify a different default stack reservation size for all threads and fibers, use the STACKSIZE statement in the module definition (.def) file. The operating system rounds up the specified size to the nearest multiple of the system's allocation granularity (typically 64 KB). To retrieve the allocation granularity of the current system, use the GetSystemInfo function.


Хотя это конечно не повод плодить по потоку на коннекшн А если сильно хочется — то легкие потоки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[4]: диалог с любителями потоков
От: CreatorCray  
Дата: 01.07.09 08:14
Оценка: +1
Здравствуйте, SkyDance, Вы писали:

SD>В С++, особливо на виндах, — проблема.

SD> Стек на 1000 процессов выест 1000 * 10 Мб (по дефолту) = 10 Гб виртуальной памяти, в 32 бита (2 Гб предел) уже не лезет.
А при чем тут вообще С++?
CreateThread — WinAPI функция, которой можно задавать отличный от дефолтного размер стека.

SD> Проблема реально существует, мы с ней боролись. Сначала уменьшением аппетитов (до 1 Мб стека), потом стало понятно, что делу это не поможет и консолидировали потоки. Стало намного лучше работать.

Можно было попробовать еще на Fiber-ы перенести, некоторым помогало.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: диалог с любителями потоков
От: frogkiller Россия  
Дата: 01.07.09 08:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А что, тут какие-то варианты мнений что ли есть? Если у людей нет желания написать масштабируемый сервер массового обслуживания — то пусть делают как хотят. Некоторые и вообще удовлетворяются одноклиентными серверами.

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

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

А вообще мой пойнт такой, что в даже рамках одного проекта могут быть разные сервера с разными потоковыми моделями.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[2]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 01.07.09 10:47
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

S>Вообще, интересно, где это вы "постоянно сталкиваетесь" с такими персонажами.
Ща рассмешу: здесь
Автор: Gomes
Дата: 13.02.09

Там по ветке есть ссылка на скачку видео.
Re[5]: диалог с любителями потоков
От: SkyDance Земля  
Дата: 01.07.09 10:50
Оценка: :))
CC>А при чем тут вообще С++?

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

CC>Можно было попробовать еще на Fiber-ы перенести, некоторым помогало.


Старые legacy, когда там уже мегатонны древючего кода намучены, рефакторить в таком объеме было просто "ссыкотно" (С).
Re[6]: диалог с любителями потоков
От: jedi Мухосранск  
Дата: 01.07.09 11:36
Оценка:
Здравствуйте, SkyDance, Вы писали:

SD>Старые legacy, когда там уже мегатонны древючего кода намучены, рефакторить в таком объеме было просто "ссыкотно" (С).


В чем тогда заключалось "консолидировали потоки" ? и почему это было менее "ссыкотно" (С)
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[6]: диалог с любителями потоков
От: CreatorCray  
Дата: 01.07.09 11:37
Оценка:
Здравствуйте, SkyDance, Вы писали:

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

Видимо потому, что они не совсем потоки. Вернее не OS потоки.

SD>Старые legacy, когда там уже мегатонны древючего кода намучены, рефакторить в таком объеме было просто "ссыкотно" (С).

+1
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: диалог с любителями потоков
От: Курилка Россия http://kirya.narod.ru/
Дата: 01.07.09 11:52
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, SkyDance, Вы писали:


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

CC>Видимо потому, что они не совсем потоки. Вернее не OS потоки.
В яве зелёные потоки были насколько мне помнится только в 1.1.
Re[7]: диалог с любителями потоков
От: SkyDance Земля  
Дата: 01.07.09 11:54
Оценка:
J>В чем тогда заключалось "консолидировали потоки" ? и почему это было менее "ссыкотно" (С)

Проект старый, начат был малоквалифицированными людьми. Каждый громоздил свой слой абстрации от чего-нибудь, и дописывал наслоения кода. Так вот, при таком количестве кода нетрудно было найти точки диспетчеризации для наиболее типичных задач, которые порождали наибольшее количество потоков. Соответственно, часть потоков стала консолидироваться через один диспетчер. Это позволило нам расширить поддержку многосерверных инсталляций до нескольких сотен серверов. До этого, когда был thread per server, мы были ограничены примерно 130 серверами в постоянном мониторинге. И в целом, когда мы проводили исследования, даже при сниженном объеме стека до 256 кб у нас не создавалось больше 190 потоков. То ли из-за фрагментации памяти, то ли еще почему, но — факт.

Решение, конечно, местечковое. Но именно такие и принимаются во время maintenance продукта — никто не будет проводить глобальный рефакторинг, если это не принесет реальных бенефитов.
Re[4]: диалог с любителями потоков
От: sluge  
Дата: 02.07.09 07:21
Оценка:
Здравствуйте, SkyDance, Вы писали:

S>>а если с++ или жаба?


SD>В С++, особливо на виндах, — проблема. Стек на 1000 процессов выест 1000 * 10 Мб (по дефолту) = 10 Гб виртуальной памяти, в 32 бита (2 Гб предел) уже не лезет. Проблема реально существует, мы с ней боролись. Сначала уменьшением аппетитов (до 1 Мб стека), потом стало понятно, что делу это не поможет и консолидировали потоки. Стало намного лучше работать.


а что значит консолидировали потоки?
Re[2]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.09 13:35
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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


IIS вроде бы выделяет, но все им пользуются тем не менее.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 02.07.09 13:37
Оценка: +1 :))
Здравствуйте, VladD2, Вы писали:

VD>IIS вроде бы выделяет, но все им пользуются тем не менее.

[отпрыгивает]
Да ладно!
Re[3]: диалог с любителями потоков
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 03.07.09 02:33
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>IIS вроде бы выделяет, но все им пользуются тем не менее.
Ну конечно же ничего он не выделяет. Он использует IO Completion Ports и пул потоков.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.07.09 07:59
Оценка:
Здравствуйте, sluge, Вы писали:

S>постоянно сталкиваюсь с персонажами, которых я про себя называю "любители потоков". Этих людей отличает то что они для любой функциональности считают нужным заводить отдельный поток. И ладно еще если этих потоков будет гораниченное число-например поток на работу с сетью, поток на работу с БД. Бывает так что скажем хочет человек написать web-сервер и говорит-а дай ка я на каждое соединение заведу себе поток. Потом следуя своей стратегии, на каждое соединение заводится 2,3 и так далее потоков. Таким образом получается что при скажем 1000 соединений в системе будет 1000*n потоков. Кто что думает по этому поводу, и есть ли тут такие любители потоков?


Ежу понятно:)), что всё зависит от задачи. И от среды.

Есть примеры, когда подход "одна нить на клиента" приводила к переполнению ресурсов — например, oops (конкурент squid'а) выдерживал более 2000 клиентов только на солярке, а на более "народных" ОС дох значительно раньше. Соответственно, он далеко не ушёл.

Но чем сложнее обработка и чем меньше клиентов, тем проще и осмысленнее делать по нити на клиента и даже по несколько нитей на клиента.

P.S. В качестве бесстыдной рекламы, FAQ по этим вопросам для Unix. Основные идеи, однако, годятся для любой ОС.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.