|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
Опции темы | Поиск в этой теме |
09.07.2008, 23:04 | #1 | |
Регистрация: 09.07.2008
Сообщений: 8
|
Разбирался с аналогичной проблемой.
Также с использованием Indy10 в RAD Studio 2007 сделал стресс тестер TCP соединений.
И клиент и сервер были на одном и том же компьюьтере. Система: Win XP SP2 4-х ядерный пень и RAM 4 GB До количества в 300 подключений все шло на ура. На все 300 потоков памяти ушло несколько мегабайт (потоки сами могут регулировать свой стек, это опровергает байки про 1 M на поток ) После трехсот соединений проги стали рушиться. Анализ показал, что крышу сносит у функции GetMemory которую я использовал для выделения памяти для сообщений, поскольку сообщения передавал в поток основного окна через события. Эта функция умудрялась выдать второй раз уже выделенную память. Несмотря на то, что флаг многопоточности был выставлен и функция заявляется как поддерживающая многопоточность. Анализ кода Indy показал, что он интенсивно использует сервисы Delpfi для выделения памяти. И с учетом кривизны библиотек Delphi в многопоточной среде, надо думать многие проблемы Indy именно из-за памяти. Цитата:
|
|
09.07.2008, 23:58 | #2 |
Новичок
Джуниор
Регистрация: 18.01.2008
Сообщений: 1,720
|
|
10.07.2008, 17:01 | #3 |
Регистрация: 09.07.2008
Сообщений: 8
|
Объясняю на пальцах
В дельфях Min Stack Size в линковщике указан $4000 по умолчанию
А криэйтор класса TThread вызывает BeginThread c размером стека равным 0. Т.е. при создании потока в дельфях из класса TThread (а это и использует Indy) выделяется физически стек в $4000 байт как говорит линковщик по умолчанию. Стек, конечно, может расти до мега, но это только в случае если юзер не совладает с рекурсией Вообщем проблем с памятью для потоков нет. Проблема в функциях Дельфи. Они нестабильны в многопоточной среде. А траблы с GetMemory - научно установленный факт. А свою прогу я гонял на разных компах. И получал разное количество тредов. К тому же надо умножать на 2 поскольку и стресс тестер и прога были на одном компе. И просто создать треды с сокетами целью не было, все сокеты реально подключались и одновременно передавали данные в общую базу. |
10.07.2008, 17:50 | #4 |
Новичок
Джуниор
Регистрация: 18.01.2008
Сообщений: 1,720
|
AlexandrY, если хотите, можем подискутировать об этом в другой теме. Создайте новую или попросим модератора раздела перенести крайние посты, поскольку явно отклоняемся от темы топика. Для начала могу сказать - не путайте выделенную память и зарезервированную.
|
11.07.2008, 19:00 | #5 |
Регистрация: 09.07.2008
Сообщений: 8
|
Да я уже с проблемой разобрался.
Прога создает 2000 сокетов менее чем за 1 сек через компоненты Indy. Соответственно на тестовом компе появилось 4000 новых потоков. Для моей задачи более чем достаточно. На этот раз комп был скромнее, всего 1 Gb RAM-а и одноядерный проц. C 4500 тредов операционка захватила всего 400 MB RAM-а. Но если вы говорите что это не в тему, то наверно не буду рассказывать в чем была настоящая проблема в моем случае. |
12.07.2008, 00:52 | #6 | ||
Новичок
Джуниор
Регистрация: 18.01.2008
Сообщений: 1,720
|
Во-первых, спасибо за перенос темы, во избежание недоразумений уточню, что часть постов перенесена отсюда.
Цитата:
Дело здесь вот в чём. Если Вы запустите вот такую программу: Код:
Код:
Цитата:
Код:
|
||
12.07.2008, 20:53 | #7 | |
Регистрация: 09.07.2008
Сообщений: 8
|
Жаль, этим вы насолили только навичку Vynt с которым я и хотел общаться.
Теперь ему придется рыться в темах чтобы найти ответ на свой вопрос, если он вообще знает ухватки местных модераторов. И совершенно не собирался с вами дискутировать по поводу многопоточности. Повторяю, никаких проблем большое количество потоков в WinXP не представляет, а то что 1 Meg чистая байка подтверждает ваша же ссылка. Просто как факт вам покажу без комментариев несколько скриншотов: Цитата:
|
|
13.07.2008, 01:00 | #8 | |||
Новичок
Джуниор
Регистрация: 18.01.2008
Сообщений: 1,720
|
Цитата:
Цитата:
Цитата:
Внимательно читайте то, что Вам пишут. И ту тему, кстати, тоже прочитайте. Там было сказано, что причина того, что не получается создать более 2000 потоков - мегабайт стэка на поток по умолчанию. Скриншоты Ваши, к сожалению, никакого интереса не представляют, можно запустить и 20 тысяч потоков. Как я уже писал выше - это очень плохой путь. |
|||
13.07.2008, 02:15 | #9 | |
Регистрация: 09.07.2008
Сообщений: 8
|
Вот тока не надо... "По умолчанию" сказал я с принципиальным уточнением, что по умолчанию конкретного линкера. А MSDN таким линкером по умолчанию считает Visual Studio. Но в общем случае другому линкеру никто не запрещает иметь другую цифру по умолчанию. Так что байка она и есть байка
Но я вижу с вами можно иметь дело. Вы уже категорично не настаиваете на скупых цифрах типа на более 2 тыс. или не более 4 тыс. Уже и 20 тыс. оказывается можно. А нам больше и не надо. А если что, то переходим на следующую Ethernet карту и организуем новый процесс и опять назначаем в десяток тысяч тредов. Какие проблемы? Скриншот я показал для того чтобы не молоть по пусту воду о том как треды занимают ресурсы проца. Фиберы в этом плане ничуть не лучше. И тредам и фиберам одинаково приходится сохранять контекст процессора. Т.е. накладные на переключение процессов будут одинаковые. Причин для какой-то фрагментации чего-либо не вижу. Проблемы синхронизации тоже выглядят надуманными. Но если делать все сокеты в одном треде то вынуждены будете мучительно делать все тот же самопальный кольцевой планировщик, и ради чего? Просто потому что боимся тредов? Так в чем там плохой путь с тредами? Писать консольные процедурки не обязательно. Просто на пальцах, на уровне идей. Хорошую идею нетрудно и самому проверить. Цитата:
|
|
13.07.2008, 02:43 | #10 | |||||||
Новичок
Джуниор
Регистрация: 18.01.2008
Сообщений: 1,720
|
Цитата:
Я польщён. Цитата:
Цитата:
Цитата:
Цитата:
Не "чего-либо", а Non Paged Pool. Причины? А обычные причины для фиксированного на одном месте объема памяти, в котором постоянно хаотически будут выделяться и удаляться тысячи блоков. Думаете, продержится такой "сервер" хотя бы неделю? Всё выглядит надуманным, пока мы с этим не столкнулись. Цитата:
Нет, не боимся. Когда они нужны и полезны - используем, и другим советуем. Когда их применение по принципу "лишь бы были" грозит построением неуправляемого чудовища - берём карандаш, если нужно, документацию и аккуратно проектируем. Цитата:
----------------------------- Да, ещё, насчёт "по умолчанию". Не надо играть в слова. Не стоит брать куски других постов, адресованных другим участникам, и строить на них свои доводы. Последний раз редактировалось B_N; 13.07.2008 в 02:47. |
|||||||
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
многопоточность в Delphi | xakkkkker | Свободное общение | 12 | 13.08.2010 18:52 |
Многопоточность Indy | AVer | Работа с сетью в Delphi | 14 | 14.02.2009 22:10 |
Кодировка в приложениях | Horror | Общие вопросы .NET | 3 | 16.04.2008 14:23 |
По поводу зациты от DoS в сетевых приложениях Delphi... | dukie | Работа с сетью в Delphi | 2 | 30.12.2007 22:37 |