форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"тормоза при работе с динамической памятью в linux thread"

Сообщение от rmf on 26-Фев-07, 10:08

Ситуация: - linux 2.4.34 - glibc 2.3.2 + linuxthreads-0.10 - gcc 3.4.6 - swap отсутствует как класс - запись на диск - отключена - физической памяти предостаточно некий рабочий поток очень динамично выделяет posix_memalign()/memalign память (и большие 200K и маленькие куски < 2K) и через очередь переносит в основной процесс, где выделенные блоки обрабатываются и освобождаются судя по top: memleak-а вроде нет происходит следующее: 3 мин загрузка CPU 1% - это и ожидается, так как вся ресурсоемкая обработка отключена 10 сек загрузка CPU 25% - тормоза на чтении выделенных в потоке блоков 3 мин загрузка CPU 1% и так далее что это: - куча? - куча в трэдовых приложениях? - linux vm? Подскажите куда рыть, plz.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Сообщения по теме

[Сортировка по времени, UBB]

1. "тормоза при работе с динамической памятью в linux thread"

Сообщение от DeadMustdie (??) on 26-Фев-07, 13:51

1. Если все делается как описано, то - странный эффект.    Возможно, фокус действительно в старом ядрышке и древней glibc.    Сперва имеет смысл попробовать прогнать на свежем дистрибутиве:       ядро 2.6.x + glibc версии не ниже 2.3.2. 2. Есть резон завести временно файлик трассировки, в который выводить    факты порождения и обработки "блоков", а также текущие статистики    употребления процессора. Возможно, бурная активность перемежается    с периодами простоя. 3. Затем я попробовал бы прогнать эту штуку через valgrind.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "тормоза при работе с динамической памятью в linux thread"
	Сообщение от DeadMustdie (??) on 26-Фев-07, 13:52
	Чуть не забыл - первое, что следует сделать - перейти с linuxthreads на NPTL.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "тормоза при работе с динамической памятью в linux thread"
	Сообщение от rmf on 26-Фев-07, 14:41
	>Чуть не забыл - первое, что следует сделать - перейти с linuxthreads >на NPTL. Спасибо за ответы. На другой связке kernel/glibc/nptl - проверю. Все процессы идут равомерно по кварцу железяки. valgrind - пробовал - но скорость настолько резко падает, что не дождался в общем :) Возможно ответ лежит http://www.opennet.me/docs/RUS/nptl_design/ в разделе 5.6 Распределение памяти но суть до меня пока не дошла :) Самое странное, что тормоза включаются именно на доступе, а не на malloc/free, которые могут вызывать всякие процессы в куче.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "тормоза при работе с динамической памятью в linux thread"
	Сообщение от MKuznetsov (??) on 26-Фев-07, 23:26
	>>Чуть не забыл - первое, что следует сделать - перейти с linuxthreads >>на NPTL. > > >Спасибо за ответы. > >На другой связке kernel/glibc/nptl - проверю. > >Все процессы идут равомерно по кварцу железяки. > >valgrind - пробовал - но скорость настолько резко падает, >что не дождался в общем :) > >Возможно ответ лежит http://www.opennet.me/docs/RUS/nptl_design/ >в разделе 5.6 Распределение памяти >но суть до меня пока не дошла :) > >Самое странное, что тормоза включаются именно на доступе, >а не на malloc/free, которые могут вызывать всякие процессы в куче. а вы уверенны что тормозу именно при чтении уже выделенной и заполненной памяти ? в глубокой теории тормоза могут возникать при записи в большой, свежевыделенный кусок памяти..в серой практике - тормозить могут 1) реализация очереди 2) разбор и анализ принятых данных..кстати, большая занятость CPU может быть вызвана просто счётной задачей, то если есть чего считать - то он и считает, и это нормально :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "тормоза при работе с динамической памятью в linux thread"
	Сообщение от rmf on 27-Фев-07, 10:15
	>а вы уверенны что тормозу именно при чтении уже выделенной и заполненной >памяти ? Тормозит доступ к памяти: запись точно, чтение - не известно. >в глубокой теории тормоза могут возникать при записи в большой, свежевыделенный кусок >памяти.. Вот вот, уже теплее, киньте какую-нибудь фразу из теории для затравки. > в серой практике - тормозить могут 1) реализация очереди > 2) разбор и анализ принятых данных.. Все может быть, поэтому для теста - отключил очередь и поставил memcpy блока в том же потоке (в доп блок) - результат повторился. > кстати, большая занятость CPU может быть вызвана просто >счётной задачей, то если есть чего считать - то он и >считает, и это нормально :) В целом согласен, но периодические горбы в 10-20 сек в CPU 20% (потом 3 минуты  1-2%) на простых операциях с оперативкой это явный перебор. Пока грешу на какие-то кучёвые процессы из-за особенностей поточной схемы. Больше я с потоками не игок, даже с учетом nptl,futex и сравнительно лёгкого SMP. epool, rtsig, pool - наше всио. Потоки оставим выньдузятникам. Собственно поэтому в своё время и была выбрана такая кривая схема :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "тормоза при работе с динамической памятью в linux thread"
	Сообщение от MKuznetsov (??) on 27-Фев-07, 11:14
	>Вот вот, уже теплее, киньте какую-нибудь фразу из теории для затравки. сам попробуй сравнить время двух операций : - выделение большого блока через mmap - запись в этот блок 0x1 через 4096 байта фокус в том, что реально странички подставляются в момент записи
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "тормоза при работе с динамической памятью в linux thread"
	Сообщение от rmf on 27-Фев-07, 11:41
	> >>Вот вот, уже теплее, киньте какую-нибудь фразу из теории для затравки. > >сам попробуй сравнить время двух операций : >- выделение большого блока через mmap >- запись в этот блок 0x1 через 4096 байта >фокус в том, что реально странички подставляются в момент записи согласен однако в однопоточном тестовом приложении загрузка ровная без горбов c теми же размерами блоков если за операционный атом принять mmap() memcpy() munmap() (то есть за выделением памяти всегда идет обращение) тормоза могут быть на 1) mmap(>страницы) или 2) на доступе при подставлении страницы Однако если убрать memcpy() [ mmap() , munmap() ] то "горбам" кaпец, и сл-но тормоза на подставлении страницы. Но почему такими длит. периодами-то по 10-20 сек? Как будто память неоднородная по скорости.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "тормоза при работе с динамической памятью в linux thread"
	Сообщение от MKuznetsov (??) on 27-Фев-07, 14:29
	>Но почему такими длит. периодами-то по 10-20 сек? >Как будто память неоднородная по скорости. умозрительно картинка получается такая : 0- выделяется память через mmap 1- что-то туда пишется, но страницы нет, возникает исключение процессора 1.1 система ломится в режим ядра, ищет и подставляет страницу 1.2 ядро смотрит какой задаче вернуть управление, хорошо если вашей 1.3 управление возращается задаче 1.4 страница полностью заполняется 1.5 надо писать дальше - то есть возврат в 1) 2-всё записано :) если страниц много, и учитывая дискретность и погрешность измерений 15% загрузка на 10-20 секунд - это нормально если уж очень надо улучшить ситуацию, можно a) использовать свой аллокатор (то есть сразу взять сколько надо памяти и гонять её промеж собой) b) поиграть параметрами планировщика с) сделать swap :) странно, но на 2.4 это слегка ускоряет работу, даже если он реально не используется
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "тормоза при работе с динамической памятью в linux thread"
	Сообщение от rmf on 27-Фев-07, 14:45
	>если уж очень надо улучшить ситуацию, можно >a) использовать свой аллокатор (то есть сразу взять сколько надо памяти и >гонять её промеж собой) спасибо, похоже так и нужно возможно качать большие блоки через динамику это плохое решение по крайней мере в последней ванильке ветки 2.4 в 2.6 не пробовал (жду Etch-а). >b) поиграть параметрами планировщика это мне окончательно крышу свинтит :) >с) сделать swap :) странно, но на 2.4 это слегка ускоряет работу, > даже если он реально не используется интересно, на досуге проверю
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]