Ситуация:
- 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.
1. Если все делается как описано, то - странный эффект.
Возможно, фокус действительно в старом ядрышке и древней glibc.
Сперва имеет смысл попробовать прогнать на свежем дистрибутиве:
ядро 2.6.x + glibc версии не ниже 2.3.2.
2. Есть резон завести временно файлик трассировки, в который выводить
факты порождения и обработки "блоков", а также текущие статистики
употребления процессора. Возможно, бурная активность перемежается
с периодами простоя.
3. Затем я попробовал бы прогнать эту штуку через valgrind.
Чуть не забыл - первое, что следует сделать - перейти с linuxthreads на NPTL.
>Чуть не забыл - первое, что следует сделать - перейти с linuxthreads
>на NPTL.
Спасибо за ответы.На другой связке kernel/glibc/nptl - проверю.
Все процессы идут равомерно по кварцу железяки.
valgrind - пробовал - но скорость настолько резко падает,
что не дождался в общем :)Возможно ответ лежит http://www.opennet.me/docs/RUS/nptl_design/
в разделе 5.6 Распределение памяти
но суть до меня пока не дошла :)Самое странное, что тормоза включаются именно на доступе,
а не на malloc/free, которые могут вызывать всякие процессы в куче.
>>Чуть не забыл - первое, что следует сделать - перейти с linuxthreads
>>на NPTL.
>
>
>Спасибо за ответы.
>
>На другой связке kernel/glibc/nptl - проверю.
>
>Все процессы идут равомерно по кварцу железяки.
>
>valgrind - пробовал - но скорость настолько резко падает,
>что не дождался в общем :)
>
>Возможно ответ лежит http://www.opennet.me/docs/RUS/nptl_design/
>в разделе 5.6 Распределение памяти
>но суть до меня пока не дошла :)
>
>Самое странное, что тормоза включаются именно на доступе,
>а не на malloc/free, которые могут вызывать всякие процессы в куче.а вы уверенны что тормозу именно при чтении уже выделенной и заполненной памяти ?
в глубокой теории тормоза могут возникать при записи в большой, свежевыделенный кусок памяти..в серой практике - тормозить могут 1) реализация очереди 2) разбор и анализ принятых данных..кстати, большая занятость CPU может быть вызвана просто счётной задачей, то если есть чего считать - то он и считает, и это нормально :)
>а вы уверенны что тормозу именно при чтении уже выделенной и заполненной
>памяти ?Тормозит доступ к памяти: запись точно, чтение - не известно.
>в глубокой теории тормоза могут возникать при записи в большой, свежевыделенный кусок
>памяти..
Вот вот, уже теплее, киньте какую-нибудь фразу из теории для затравки.
> в серой практике - тормозить могут 1) реализация очереди
> 2) разбор и анализ принятых данных..Все может быть, поэтому для теста - отключил очередь
и поставил memcpy блока в том же потоке (в доп блок) -
результат повторился.> кстати, большая занятость CPU может быть вызвана просто
>счётной задачей, то если есть чего считать - то он и
>считает, и это нормально :)В целом согласен, но периодические горбы в 10-20 сек в CPU 20% (потом 3 минуты 1-2%) на простых операциях с оперативкой это явный перебор.
Пока грешу на какие-то кучёвые процессы из-за особенностей поточной схемы.
Больше я с потоками не игок, даже с учетом nptl,futex и сравнительно лёгкого SMP.epool, rtsig, pool - наше всио.
Потоки оставим выньдузятникам.
Собственно поэтому в своё время и была выбрана такая кривая схема :)
>Вот вот, уже теплее, киньте какую-нибудь фразу из теории для затравки.сам попробуй сравнить время двух операций :
- выделение большого блока через mmap
- запись в этот блок 0x1 через 4096 байта
фокус в том, что реально странички подставляются в момент записи
>
>>Вот вот, уже теплее, киньте какую-нибудь фразу из теории для затравки.
>
>сам попробуй сравнить время двух операций :
>- выделение большого блока через mmap
>- запись в этот блок 0x1 через 4096 байта
>фокус в том, что реально странички подставляются в момент записи
согласен
однако в однопоточном тестовом приложении загрузка ровная без горбов
c теми же размерами блоковесли за операционный атом принять
mmap()
memcpy()
munmap()(то есть за выделением памяти всегда идет обращение)
тормоза могут быть на1) mmap(>страницы)
или
2) на доступе при подставлении страницыОднако если убрать memcpy() [ mmap() , munmap() ] то "горбам" кaпец,
и сл-но тормоза на подставлении страницы.Но почему такими длит. периодами-то по 10-20 сек?
Как будто память неоднородная по скорости.
>Но почему такими длит. периодами-то по 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 это слегка ускоряет работу,
даже если он реально не используется
>если уж очень надо улучшить ситуацию, можно
>a) использовать свой аллокатор (то есть сразу взять сколько надо памяти и
>гонять её промеж собой)спасибо, похоже так и нужно
возможно качать большие блоки через динамику это плохое решение
по крайней мере в последней ванильке ветки 2.4
в 2.6 не пробовал (жду Etch-а).
>b) поиграть параметрами планировщикаэто мне окончательно крышу свинтит :)
>с) сделать swap :) странно, но на 2.4 это слегка ускоряет работу,
> даже если он реально не используетсяинтересно, на досуге проверю