Планета Calculate

Облако тэгов

звуковые карты wi-fi udev news полезное работа mail swap abi_x86_32 KDE5 xsel серые листы winbind tracker ДНК cld cp1251 live-flash valve syslog QupZilla kvm cairo-dock автологин настройка цветов принтера freerdp mpg123 форматирование текста профиль пользователя bonding book dwm NetworkManager apvlv CLDG qemu rtorrent uptime rutorrent ati autologin ccze asus n10j press радио mailman BINHOST builder persistence icons bash CSS клавиатура kde5 cldg strategy benchmark zstd matrix форум lm_sensors screenshot alpha пресса feh tun slim maillist lighttpd шаблоны домашний сервер Gnome3 hdmi CSC remoteapp zswap networking flashplayer atom n270 Книги foto тема pam power KDE dhcpcd android textile bond Tor elogv многопоточная закачка asus x86 revision tint browser ati-drivers asterisk lirc vaio games desktop ups ускорение Xorg windows MultiTail instagram BugTracker cpu family mplayer реестр PowerTOP su ПО RT mencoder package unmasking установка net cl-builder vulnerability blog tint2 программист LXC qrencode сайт утилитки на Icon EFI plymouth ControlMaster calculate-access помощь день рождение LXD vps рассылка man LTE фидонет pre qupzilla db Calculate E17 wiki umd persistence-mode IRC mirrorselect aufs xfce оптимизация AMD bootchart cryptsetup pxe birthday obmenu доступ rdp LXQt emerge radeon pf-kernel udisks ntfs-3g xen grub openbox midori кодировка CP1251 настройка цветов сканера beta keyboard systemd-udevd Calculate package sound gcc handbook ini.env grc MATE kernel pwkl cds xpak командная строка firefox mate make.conf XZ kernek win7 acl jabber recordmydesktop windows 7 firmware tweaks autounmask ext4 minicom двойная загрузка nextcloud Matrix #calculatelinux linux tbn bug xmpp виртуализация benchmarking raid Firefox hibernate calculate2 w2k3 маршрутизатор gnome vpn support calculate-install-gui calculate utilities glx-dock CLC 4G calculate utils otter features profile Windows 7 Huawei new tools CDS dns dhcp настройка цветов фотоаппарата Calculate Linux Enlightenment сглаживание udisks-glue reader цветовой профиль icc фидо перенесено костыли распространение pdf cmc dropbox kde xfce pastebin twitter ssh шрифт authentication cls канал wget uksm LVM world мышка день программиста Midnight Commander lxc-desktop sudo kde nano calculate-sources templates temperature pitivi calculate 2.2 portage CMC xchat ПДУ howto muqss theme звук dvcs meta djvu cl-update-profile X linuxdcpp 1C postgresql apache fontconfig lcdfilter fonts шрифты DPI atheros9285 ratigan монитор экран разрешение CLDXE sony smplayer описание tuxonice flags optimization fonts bluetooth uefi openvpn VirtualBox nm-applet weechat 11.6 backdor qr-code alsa torrent tail forum интервью Audio utilities donation сеты monitoring распространение программ systemd Office security загрузчик dhcp binhost Скоростной алгоритм сжатия LZ4 TV GSC canto браузер CL14 xxkb участие USE samba screensaver MyRuLib lto distro xbmc keyexec python3 Снобизм stage luks pae UTF-8 оптимизация linux lautre дизайн energy saving plan репозиторий Summer Camp 3G курсор мыши dnscrypt install Calculate Utilities Библиотека shorewall gnome3 GPT steam производительность gentoo vlc p2p mp3 Plasma plugn ldap screencast icon w2k8 mc lvm Compose установка Icon в Calculate nexus repo git team CLDC Atheros XFCE cldm сборка из исходников openssh pulseaudio pgo помощь проекту CLDM liveusb ppp0 tap mouse vim перемещаемые профили cl-kernel iptables mirror android kde mtp livecd Gnome cpp livedvd установка linux e4rat calculate3 начало XMPP update caffeine binary code dns calculate linux antivirus free documentation calculate-install dmidecode kde и многопоточный звук codelite euse CLSK rip grub2 интернет unclutter freshplayerplugin hdd most openrc container release Либрусек acoola новости SSD bsa font iphone dconf btrfs E17 nut настройка цветов монитора план RSS безопасность ebuild ядро gnome 2 github ncurses markdown почта удаленная сеть qutim разработка xorg packages openldap udisks template calculate postfix ffmpeg ubuntu clementine глобальное меню загрузка CL17 CLSL EAPI 2 CLS обмен опытом E17 Calculate bridge telegram chromium OpenRC Timeless overlay libvirt создание подсветки синтаксиса bittorrent АТС nouveau network calculate-utils server developers вакансия ParaType facebook locale Desktop eudev DNA CCDX irc оптимизация ядра CDS настройка linux atheros calculate linux obconf automagic reestr pptp MidnightCommander cl-console-bg cl CLDX linux CLDL internet history objecticon видео blueman firewall layout Zen softraid CLD подсветка синтаксиса video python dmix debian localepurge google talk-plugin smart блог bash-completion кеширование proxy Icon Calculate USB Creator Calculate Linux Spamassassin брелок programming сервер Cinnamon unicode

Ускоряем компиляцию пакетов. Советы и используемые мною трюки.

Добавил(а) Данила Жукоцкий больше 4 лет назад

За что я люблю Gentoo? За потрясающую гибкость и возможность улучшить практически всё!

Подозреваю, что многие пользователи Calculate перешли на него с Gentoo именно за возможность избежать долгих часов компиляции. Я и сам, признаться, руководствовался в том числе и этим мотивом. Бывают ситуации, когда компилировать просто некогда, бывает железо, превращающее процесс в мучение... Однако далеко не всё богатство софта в portage наличествует у нас в бинарном виде. В результате совсем от компиляции уйти не удаётся. Кроме того, иногда из перфекционистских соображений пользователь может отказаться от бинарных пакетов. Например чтобы избавиться от ненужного лично ему, но присутствующего на диске софта, языков, на которых он не говорит, не читает и не пишет, добавить отсутствующий по умолчанию функционал или наоборот, от части функционала избавиться. Всё это влечёт за собой изменение USE флагов и, как следствие, пересборку из исходников.

Предлагаемые ниже советы и трюки помогут ускорить этот процесс.

Про железо.

  • Самый важный элемент Вашего компьютера, ускоряющий компиляцию - ОЗУ. Нужно больше памяти! Swapping Ваш враг, swapping крадёт минуты и часы из Вашей жизни, swapping портит Ваш характер. Ряд советов из приведённых здесь предполагают наличие у Вашего компьютера "лишнего" ОЗУ. Память нынче дешёвая, увеличить ОЗУ до комфортных размеров, хотя бы до 16 гигабайт, и навсегда забыть про swapping стоит совсем недорого, зато сразу же улучшится цвет лица и качество Вашей жизни.
  • SSD. Вы ещё не переехали всей системой на SSD диск? Дорого? Купите что нибудь быстрое и дешёвое на 60gb и осильте bcache. Получите "два в одном", ёмкость Вашего "классического" HDD плюс сверхбыстрый случайный доступ свойственный SSD. Рекомендую.
  • А вот процессор, как ни странно, лишь на третьем месте... Тут всё понятно, мне кажется. Чем больше всего, ядер, частот, кэша - тем лучше.

Про помогающий софт, глобальные флаги и tmpfs.

  • Кроме компиляции часть времени отнимают процессы распаковки\запаковки - распаковка исходников, сжатие чего нибудь в процессе установки... В portage есть версии популярных архиваторов использующие многопоточные алгоритмы: app-arch/pbzip2 и app-arch/pigz - многопоточный gzip. Если установить их с флагом symlink они подменят собою штатные bzip2 и gzip. Есть разные мнения об их эффективности, но почему бы не попробовать? Вы ничего не сломаете, если что то пойдёт не так - просто удалите эти пакеты и продолжите пользоваться штатными.
  • Смонтируйте PORTAGE_TMPDIR в tmpfs.
    У меня в fstab:
    none            /var/portagetmp tmpfs   mode=1777,size=10G,mpol=interleave      0 0
    

    /var/portagetmp - это у меня так. Замените Вашим значением переменной PORTAGE_TMPDIR.
    size=10G - вполне достаточно для сборки libreoffice например. Реально в памяти tmpfs занимает столько места, сколько на ней данных. При размере ОЗУ в 16gb и tmpfs 10gb openoffice собирается без залезания в swap. Если памяти будет не хватать, ОС начнёт вытеснять неиспользуемые страницы tmpfs в swap. Это чревато тормозами, но ничего не сломается.
    mpol=interleave - не обращайте внимания, Вам можно это не писать, это мои NUMAпроблемы.
    Не используйте -pipe в CFLAGS если Вы собираете в tmpfs, зачем вам двойной расход памяти. И наоборот, не используете tmpfs - пропишите -pipe в CFLAGS.
  • Флаг pch - использование прекомпилированных заголовков, существенно ускоряет сборку qt программ и библиотек. Имеет смысл включить его глобально. Внимание! Этот флаг ломает сборку при использовании distcc и снижает эффективность ccache!
  • ccache. Есть ошибочное мнение что использование ccache ускоряет компиляцию. В долгосрочном плане это не так. Эффективность "холодного" кеша ccache весьма низка, наличие в "холодном" кеше объектов от сборки предыдущей версии пакета вряд ли поможет при сборке новой версии. Возможный выигрыш растрачивается на работу алгоритма поиска по массиву кеша (поэтому нет смысла делать размер кеша больше умолчального) и доступ к диску для каждого вызова gcc, даже если это SSD. Он всё равно медленнее чем доступ к ОЗУ (о сборке в tmpfs мы поговорим позднее). Поэтому если у Вас глобально выставлено FEATURES="ccache" в make.conf вы замедляете сборку, а не ускоряете. ccache необходим, если Вы отлаживаете сборку какого либо пакета и она постоянно прерывается ошибками. Вот в этом случае использование FEATURES="ccache" ebuild /путь/к-тому/что-вы/чините.ebuild merge или FEATURES="ccache" emerge уже-компились-давай оправданно и экономит время. Несмотря на всё вышесказанное, я использую один трюк с ccache слегка убыстряющий обновление мира. Дело в том, что ccache может эффективно ускорять прохождение этапа configure. На этом этапе система гоняет тесты, большинство из которых однотипные и их результаты прекрасно живут, не вытесняясь, в горячем кеше. Как это работает: Я монтирую CCACHE_DIR в tmpfs, руками, перед обновлением мира, и задаю кешу маленький размер, 100mb. В результате я жертвую 100mb ОЗУ, но получаю ускорение тестов configure. Для этого у меня в fstab есть запись:
    none            /var/cache/ccache       tmpfs   size=1G,noauto       0 0
    

    /var/cache/ccache - я предпочитаю хранить кеш тут, из эстетических соображений, переменная CCACHE_DIR в make.conf указывает у меня туда. Там живёт холодный кеш умолчального размера, которым я пользуюсь при отладке сборки своих ebuildов.
    size=1G - перестраховка, в памяти будет <=100mb.
    noauto - я монтирую это вручную.
    В результате я обновляю мир так:
    # mount /var/cache/ccache
    # CCACHE_SIZE=100m FEATURES=ccache emerge -auD --newuse world
    umount /var/cache/ccache #когда всё закончил.
    

    Можно конечно всё это автоматизировать, но мне лень :)
  • distcc явно выходит за рамки этой статьи. Читать здесь. Главное, что стоит помнить: не используйте use флаг pch при сборке с помощью distcc, выключите его глобально для надёжности (-pch) и нельзя использовать -march=native в СFLAGS совместно с distcc! У машин в кластере наверняка отличаются процессоры, CFLAGS в данном случае следует указывать явно и полностью. Для определения "правильных" CFLAGS для Вашей машины сделайте на ней:
    # gcc -march=native -E -v - </dev/null 2>&1 | grep cc1
    # gcc -Q --help=target -march=native
    

Про оптимальное количество потоков и загрузку системы.

  • Наверняка вы читали про MAKEOPTS в make.conf. Наиболее часто приводимое значение --jobs={КОЛИЧЕСТВО_ЯДЕР_ПРОЦЕССОРА}+1, одно ядро с гипертредингом считать за два ядра. Однако это не самая оптимальная настройка. Утилита make, которой и передаётся этот параметр, умеет сама регулировать количество задач в зависимости от загрузки системы. В результате получаем более эффективное распределение нагрузки. Ограничивающий нагрузку параметр называется --load-average, усреднённая загрузка системы, и для грамотной настройки необходимо понимать, сколько это в цифрах в Вашем случае и как вообще это считать. Прочитать про LA можно здесь. Эмпирически наиболее эффективное с точки зрения максимальной производительности значение --load-average = КОЛИЧЕСТВО_ЯДЕР+1. То есть для двухядерной машины оптимальное значение 3, для восьмиядерной - 9. Но необходимо ещё учитывать расход ОЗУ - в случае его нехватки даже при теоретически правильно рассчитанном значении --load-average машина будет уходить в swap, показатель LA - расти, эффективность - падать. И наоборот, если ОЗУ с избытком, значение --load-average можно увеличить, очередь заданий станет длиннее, средняя загрузка ядер равномернее. Итак, в конечном виде переменная может выглядеть так:
    MAKEOPTS="--jobs=10 --load-average=5" 
    

    Для четырёхядерной машины это означает следующее: количество заданий make будет колебаться от 1 до 10, make будет стараться поддерживать среднюю загрузку системы в районе 5 единиц - лёгкий перегруз для четырёхядерной машины, но, при наличии вменяемого количества ОЗУ (8-16gb), не доставляющий дискомфорта при параллельном серфинге по Сети. Не увлекайтесь высокими значениями --jobs, make начинает балансировку не моментально, в результате машина может помереть в страшном свопе до того как make притормозит "лишние" потоки. Экспериментируйте.
  • У portage тоже есть аналогичная настройка, только она балансирует количество процессов emerge. Получается параллельный emerge. Предположим наш ebuild собирается в один поток, поскольку параллелится с помощью make далеко не всё, некоторые программы валятся при параллельной сборке и их майнтейнеры принудительно выставили --jobs=1 в ebuild, некоторые ebuild вообще не используют make и т.п. В этом случае portage будет обеспечивать равномерную загрузку системы запуская выполнение ebuildов параллельно! В make.conf это может выглядеть так (для четырёхядерной машины):
    EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --jobs=10 --load-average=5 --verbose --keep-going " 
    

    --jobs и --load-average работают аналогично примеру с MAKEOPTS, применённые совместно эти настройки дополняют друг друга. Если ebuild параллелится - make будет стараться поддерживать баланс нагрузки наравне с portage, если нет - portage запустит больше параллельных ebuildов. К сожалению механизм работает не со 100% эффективностью: встречаются цепочки ebuild которые должны собираться строго друг за другом и при этом внутри не распараллеливаются. Часть ядер в этом случае будет простаивать.
    --keep-going удобен при параллельной сборке. Если один ebuild в процессе отвалится с ошибкой сборка остальных будет продолжена, кроме тех пакетов которые прямо зависят от помершего ebuild. Такое случается иногда (редко) при параллельной сборке из за глюков с очерёдностью. Паниковать в этом случае не надо, достаточно заново запустить сборку мира после того как она остановится и то что отвалилось в итоге соберётся.
    Учитывайте расход памяти. Экспериментируйте и ищите оптимальные для Вас значения.

Наверняка о чём то я забыл рассказать, если вспомню - дополню статью.


Комментарии

Comment

Добавил(а) Сергей Сиделев больше 4 лет назад

уточнение по поводу пункта

..Если памяти будет не хватать, ОС начнёт вытеснять неиспользуемые страницы tmpfs в swap. Это чревато тормозами, но ничего не сломается.

а если у нас swap-раздел физически просто отсутствует? все рухнет?

Comment

Добавил(а) Данила Жукоцкий больше 4 лет назад

Сергей Сиделев писал(а):

уточнение по поводу пункта

..Если памяти будет не хватать, ОС начнёт вытеснять неиспользуемые страницы tmpfs в swap. Это чревато тормозами, но ничего не сломается.

а если у нас swap-раздел физически просто отсутствует? все рухнет?

Придёт OOM killer и что нибудь убьёт. Скорее всего компиляция и рухнет.

Comment

Добавил(а) Алексей Бешенков больше 4 лет назад

Скоратить время компиляции, по идее должен переход на clang

Comment

Добавил(а) Юрий Ануфриев почти 2 года назад

Все, вы уверены? Как на счет portage? :)

Спасибо!