LINUX.ORG.RU

Низкий прирост скорости компиляции с distcc

 ,


0

3

Привет, ЛОР.

Я решил привлечь к сборке gentoo свой домашний сервер-файлопомойку через distcc. Для этого поставил на сервере gentoo в контейнер lxc, чтобы не было проблем из-за разных версий gcc, и настроил всё по статье из wiki.

Суть проблемы:
Всё работает, в htop и distccmon-text видно, что сервер всеми четырьмя ядрами помогает компилировать. Но планировалось получить ускорение на уровне 15%-25%, а получилось не больше 7%. Так и должно быть, или я упускаю что-то важное?

На локалхосте, на котором живет компилируемая gentoo, стоит AMD Phenom(tm) II X6 1055T Processor.
На сервере стоит AMD Athlon(tm) X4 740 Quad Core Processor.

Конфиги на сервере:

# grep -v '^#\|^$' /etc/conf.d/distccd
DISTCCD_EXEC="/usr/bin/distccd"
DISTCCD_PIDFILE="/var/run/distccd/distccd.pid"
DISTCCD_OPTS="--port 3632 --log-level notice --log-file /var/log/distccd.log -N 15 --allow 192.168.15.0/24"

Конфиги на локальной машине:

$ cat /etc/portage/make.conf
#CFLAGS="-march=native -O2 -pipe"
CFLAGS="-march=amdfam10 -O2 -pipe -mcx16 -msahf -mpopcnt -mabm -mlzcnt -mprfchw -mfxsr --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10 -fstack-protector" 
CXXFLAGS="${CFLAGS}"
CHOST="x86_64-pc-linux-gnu"
PORTDIR="/usr/portage"
DISTDIR="${PORTDIR}/distfiles"
PKGDIR="${PORTDIR}/packages"

ABI_X86="64"

#MAKEOPTS="-j7"
MAKEOPTS="-j21 -l6"
FEATURES="distcc distcc-pump"

GENTOO_MIRRORS="http://mirror.yandex.ru/gentoo-distfiles/"
VIDEO_CARDS="radeon r600"
LINGUAS="ru"

SANE_BACKENDS="epkowa"

USE="mmx mmxext sse sse2 sse3 sse4a 3dnow 3dnowext \ 
     bindist pulseaudio -gnome -kde \
     bash-completion vdpau -avahi \
     -bluetooth -qt5 infinality -ldap smp \
     glamor udev -libav ffmpeg -vaapi ipv6"

CFLAGS и MAKEOPTS я сделал, следуя рекомендациям всё той же статьи из gentoo wiki.

$ grep -v '^#\|^$' /etc/conf.d/distccd
DISTCCD_EXEC="/usr/bin/distccd"
DISTCCD_PIDFILE="/var/run/distccd/distccd.pid"
DISTCCD_OPTS="--port 3632 --log-level notice --log-file /var/log/distccd.log -N 15  --allow 192.168.15.0/24"

Результаты тестирования:
Проверял скорость сборки firefox командой { time emerge firefox ; } 2> /tmp/distcc.

В /etc/portage/make.conf закоментировано всё, что относится к distcc, собираем силами одного Phenom II 1055T на локалхосте:

real    22m7.832s
user    83m18.755s
sys     5m37.575s

------------------

Включаем distcc в make.conf, в /etc/distcc/hosts написано localhost 192.168.15.61:

real    22m20.462s
user    11m3.583s
sys     3m43.100s
Тут видно, что процессор на локальной машине почти ничего не делает, а время сборки даже немного увеличилось.

------------------

Увеличиваю в /etc/distcc/hosts лимиты на количество процессов distcc — localhost/6 192.168.15.61/4:

real    21m51.957s
user    11m7.690s
sys     3m32.900s
Уже лучше, но все равно ни о чем. Кстати, правильно ли я делаю, выставляя лимиты по количеству процессорных ядер на машине?

------------------

Читаю мануал дальше, делаю --randomize localhost/6 192.168.15.61,cpp,lzo:

real	20m53.875s
user	53m16.153s
sys	5m7.439s

------------------

И убираю из /etc/distcc/hosts --randomize, в итоге в файле написано localhost/6 192.168.15.61,cpp,lzo:

real	20m43.418s
user	54m1.178s
sys	5m7.274s
Лучший результат, но он меня всё равно не радует.

Deleted

MAKEOPTS="-j21 -l6"

А это не перебор?
У тебя на сервере 4 ядра + на клиенте 6 ядер (если не ошибся при просмотре характеристик процессоров)
Итого 10.

MAKEOPTS="-j10" 

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

P.S. и логи distcc и каталог /var/tmp/portage лучше смонтируй в оперативку (tmpfs).
Кроме того(давно не смотрел) раньше для режима distcc-pump требовалось запускать команду
«pump emerge пакет»

Atlant ★★★★★
()

Куда смонтирован /var/tmp на обоих машинах? Сеть - гигабит или 100мбит?

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

Может, он перепутал процессоры и думает, что на AMD есть гипертрединг?

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

ЯННП? Инфа из вики:

A common strategy is to

set the value of N to twice the number of total (local + remote) CPU cores + 1, and
set the value of M to the number of local CPU cores

# 2 удалённых хоста с 4 ядрами каждый = 8 удалённых ядер
# 1 локальный хост с двумя ядрами = 2 локальных ядра
# общее количество ядер — 10, N = 2*10+1 и M=2
MAKEOPTS="-j21 -l2"

Waldo-de-Kard ★★
()
Последнее исправление: Waldo-de-Kard (всего исправлений: 1)

Atlant, DeadEye, MAKEOPTS рассчитано по статье из gentoo wiki, и да, я понимаю, что у меня 6 и 4 ядра без гипертрединга.

Pinkbyte, на локальной машине /var/tmp/ на iscsi с ext4, потому что там всего 4 гигабайта оперативки, firefox не хочет собираться с таким маленьким /var/tmp/portage. Тот iscsi даёт писать на себя со скорость до 200 мегабайт в секунду. На сервере /var/tmp/ на tmpfs. Сеть между машинами сделана из двухгигабитного бондинга в режиме balance-rr.

Я перенес логи distcc в tmpfs. Стал запускать { time pump emerge firefox ; } 2> /tmp/distcc.

Результаты тестирования с разным содержимым /etc/distcc/hosts:

--------------

localhost/6 192.168.15.61,cpp,lzo
real	20m48.040s
user	55m21.912s
sys	5m8.141s
--------------
localhost,cpp,lzo 192.168.15.61,cpp,lzo
real	30m41.575s
user	12m25.125s
sys	3m52.798s
--------------
--randomize localhost,cpp,lzo 192.168.15.61,cpp,lzo
real	30m14.379s
user	12m55.680s
sys	3m55.402s
--------------

Какая-то ерунда получается.

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

Тот iscsi даёт писать на себя со скорость до 200 мегабайт в секунду.

Одним большим файлом или кучей мелких?

А то сдаётся мне что где-то в I/O просадка явно. nload на сетевой интерфейс насколько его нагружает?

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte
Incoming:  
Avg: 74.59 MBit/s
Max: 1.47 GBit/s
Ttl: 27.68 GByte

Outgoing:
Avg: 138.26 MBit/s
Max: 1.10 GBit/s
Ttl: 27.96 GByte

Мне сейчас лень измерять иопсы, латентность и т.п. На этом iscsi ff собирается за 22m7.832s и при этом вовсю используется локальный процессор. C distcc локальный процессор используется только на ~75%. Такое поведение может быть связано с I/O?

Я могу попробовать увеличить tmpfs с помощью zram.

Deleted
()
Ответ на: комментарий от Waldo-de-Kard

common strategy

common misconceprtion more like

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

Собираю boost.

Без distcc:

real	4m45.978s
user	13m10.881s
sys	1m33.398s
------------------
localhost/6 192.168.15.61,cpp,lzo
MAKEOPTS="-j21 -l6"
real	4m9.748s
user	11m14.334s
sys	1m29.211s
------------------
localhost/6 192.168.15.61,cpp,lzo
MAKEOPTS="-j10 -l6"
real	4m32.992s
user	11m56.164s
sys	1m27.955s

Т.е. неоднократно озвученная выше идея про MAKEOPTS не нашла подтверждения.

Проблема в том, что я не могу ни с одной комбинацией параметров в /etc/distcc/hosts заставить компилятор максимально утилизировать оба процессора одновременно. Один из них постоянно используется только на 50%-80%. В результате прирост производительности получается в пределах погрешности из-за смен настроения СУБД, которая параллельно использует жесткие диски.

Deleted
()

Промонитровал /var/tmp/ через tmpfs на локальной машине. Всё равно процессоры утилизируются не полностью. Проблема не в I/O.

Без distcc:

real	3m53.639s
user	13m6.260s
sys	1m30.735
------------------

localhost/6 192.168.15.61,cpp,lzo
real	3m42.965s
user	11m29.182s
sys	1m26.581s

------------------

localhost/6 192.168.15.61/4
real	3m9.934s
user	9m45.529s
sys	1m21.906s

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

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

У меня два гигабита между машинами. И они даже не используются на 100%. Максимум 1.47 GBit/s в процессе сборки.

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

Не жрет, я бы заметил. При компиляции процессоры простаивают на 15%-50%, хотя без distcc всё утилизируется по полной.

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

сорри, лишняя запятая в первой строчку.

Atlant ★★★★★
()

вангану, что собрать целиком на сервере будет быстрее

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

Продолжаю собирать boost. Начало описано в этом посте.

localhost/6 192.168.15.61,cpp,lzo/4
MAKEOPTS="-j21 -l6"
real	4m2.717s
user	11m29.787s
sys	1m25.469s
-----------------------------
localhost/6 192.168.15.61,cpp,lzo/4
MAKEOPTS="-j10"
real	3m43.684s
user	9m12.650s
sys	1m22.471s

Я написал скрипт, который гоняет компиляцию с разными параметрами distcc и MAKEOPTS. Осталось дождаться ночи, когда будет прохлажнее и счетчик электроэнергии переключится на дешевый тариф =)

Но я почти уверен, что после отработки этого скрипта придется признать поражение и остановиться, т.к. distcc бесполезен в моем случае, и местами даже немного вредит.

MyTrooName, нет, твое предположение не верно, я проверял. Быстрее на локалхосте.

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

Убери -l. Я сомневаюсь, что он учитывает load average distcc-сервера. И поставь -j равным сумме количеств ядер на обеих системах, не больше и не меньше.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Уже убирал, оно мало на что влияет.

Deleted
()

Погонял сборку ядра без pump.

DISTCC_HOSTS="localhost/X 192.168.15.61/Y"
make CC="distcc" -jZ -lW 
Где параметры X,Y,Z,W принимали следующие значения:
X: 6,7,9,12
Y: 4,5,8
Z: 10,11,21
W: 6 и просто без ключа -lW

Перебрал все возможные комбинации.

Лучший результат:

localhost/12 192.168.15.61/8
make CC="distcc" -j21
real    3m57.863s
user    18m13.681s
sys     2m5.225s
----------------

Худший результат:

localhost/9 192.168.15.61/5
make CC="distcc" -j10 -l6
real    6m54.911s
user    18m17.720s
sys     2m18.706s
----------------

Результат комбинации, на которую возлагалось больше всего надежд:

localhost/6 192.168.15.61/4
make CC="distcc" -j10
real    4m24.799s
user    18m24.616s
sys     2m8.328s
----------------

Только localhost:

make CC="gcc" -j7
real	4m40.517s
user	24m10.204s
sys	2m11.486s

----------------

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

Сейчас дам железу немного отдохнуть и запущу тестирование с pump mode.

Deleted
()
Последнее исправление: somestuff (всего исправлений: 1)

На всякий случай немного поэкспериментировал с приоритетом в планировшике. Это не дало ощутимого результата.

Лучший результат с pump mode:

MAKEOPTS="-j21"
localhost/6 192.168.15.61/4,cpp,lzo
real	3m51.511s
user	17m40.738s
sys	2m2.775s

Я оставляю эти параметры. Эксперимент завершен.

Самым эффективным оказалось -j21, которое советовало gentoo wiki, а не -j10, которое казалось самым логичным. Прирост скорости около 17%. Сэкономленные 10 минут с часа компиляции наверное не стоили того. Но с другой стороны, distcc немного разгружает локальную машину, и можно без лагов посмотреть видео в браузере во время сборки libreoffice. Хотя я больше бы радовался, если бы с distcc хотя бы локалхост загружался так же эффективно, как без distcc.

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

Это сборка ядра без портежа.

Deleted
()

Спасибо всем за поддержку. Без вас я бы забил на всё намного раньше и не получил бы этих 17%.

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