The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Раздел полезных советов: Сокращение времени загрузки Fedora ..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Сокращение времени загрузки Fedora ..."  +/
Сообщение от auto_tips on 31-Май-12, 19:56 
Изложенные в данной статье инструкции позволяют сократить до трёх секунд загрузку дистрибутива Fedora 17 с NetworkManager до экрана приглашения входа в систему от GDM. Указанная конфигурация опробована на ноутбуке Lenovo T420s (2x2x Intel Core i5-2540M CPU @ 2.60GHz) и SSD-накопителем Intel SSDSA2BW160G3L.

1. Используем простейшую конфигурацию разбиения диска с загрузочным и рабочим разделами с файловой системой Ext4:

   sda1 ext4 /boot
   sda2 swap
   sda3 ext4 /

После установки дистрибутива потребуется как минимум две перезагрузки для достижения оптимального времени загрузки из-за необходимости адаптации к загрузочной последовательности механизма readahead (вначале readahead собирает информацию о загружаемых программах и библиотеках, после чего начнёт разом загружать компоненты в кэш страниц памяти).

Обновляем все пакеты, активируем prelink и устанавливаем пакет systemd-analyze:

   sudo yum update
   sudo /etc/cron.daily/prelink
   sudo yum install systemd-analyze


После перезагрузки выполняем:

   sudo systemd-analyze

   Startup finished in 1413ms (kernel) + 2911ms (initramfs) + 10593ms (userspace) = 14918ms

Как видим в штатном режиме дистрибутив загрузился за 15 секунд.

Начинаем оптимизацию.
Отключаем initramfs - так как в ядро встроена поддержка файловой системы ext4, поэтому для монтирования корневого раздела не требуется загрузка дополнительных модулей ядра. В параметрах загрузки явно указываем имя корневого раздела (без UUID) и тип ФС. Содержимое /etc/grub2.cfg должно выглядеть примерно так:

   linux /vmlinuz-3.3.7-1.fc17.x86_64 root=/dev/sda3 rootfstype=ext4 quiet libahci.ignore_sss=1 raid=noautodetect
   # initrd /initramfs-3.3.7-1.fc17.x86_64.img

Опции "raid=noautodetect" и "libahci.ignore_sss=1" позволяют ускорить время инициализации ядра из-за пропуска дополнительных проверок.

После перезагрузки systemd-analyze показывает сокращение времени до 14684ms. Продолжаем оптимизацию.

Так как на компьютере не используются  LVM, RAID и шифрование можно смело отключить все сервисы fedora-*storage*. Дополнительно можно отключить систему вывода заставки  plymouth, так как нам важнее скорость а не эстетическое наслаждение от ожидания завершения загрузки. Для отключения указанных сервисов следует использовать команду "systemctl mask", достоинство которой ещё и в том, что %post скрипт RPM в дальнейшем не включит сервис автоматически.

   cd /lib/systemd/system
   for i in fedora*storage* plymouth-*.* lvm2-monitor.* mdmonitor*.*; do sudo systemctl mask $i;done

Одновременно отключим лишние SysV-скрипты  livesys, livesys-late и spice-vdagentd:

   for i in livesys livesys-late spice-vdagentd ; do sudo chkconfig $i off;done

Перезагружаем систему и наблюдаем через systemd-analyze сокращение времени загрузки до 8197ms

Далее переходим к экстремальным действиям и отключаем все сервисы, кроме NetworkManager, поэтому важно запомнить что именно было отключено, так как в результате будет получена система без почты, межсетевого экрана, системы печати, утилит abrt,  avahi, некоторых точек монтирования, rsyslog, irqbalance и защиты selinux.

   cd /lib/systemd/system
   for i in abrt*.service auditd.service avahi-daemon.* bluetooth.* dev-hugepages.mount dev-mqueue.mount \
      fedora-configure.service fedora-loadmodules.service fedora-readonly.service ip6tables.service \
      iptables.service irqbalance.service mcelog.service rsyslog.service sendmail.service sm-client.service \
      sys-kernel-config.mount sys-kernel-debug.mount; do \
    sudo systemctl mask $i; \
   done

Для отключения selinux правим  файл /etc/selinux/config и добавляем настройку "selinux=0" в строку с параметрами ядра. Настройки /etc/grub2.cfg принимают примерно такой вид:

   linux /vmlinuz-3.3.7-1.fc17.x86_64 root=/dev/sda3 rootfstype=ext4 libahci.ignore_sss=1 raid=noautodetect selinux=0
   #  initrd /initramfs-3.3.7-1.fc17.x86_64.img


Перезагружаемся и наблюдаем по systemd-analyze сокращение загрузки до 2926ms.

Но идеи по оптимизации пока не исчерпаны. Попробует выжать ещё времени через манипуляции с монтированием разделов. Переводим раздел /boot в режим "монтирование по требованию" и создаём раздел /tmp с использованием  tmpfs для сокращения нагрузки на диск в процессе загрузки. В результате /etc/fstab будет выглядеть следующим образом:

   /dev/sda3  /                       ext4    defaults        1 1
   /dev/sda1  /boot                   ext4    noauto,comment=systemd.automount     1 2
   /dev/sda2  swap                    swap    defaults        0 0
   tmpfs      /tmp                    tmpfs   defaults        0 0

После перезагрузки systemd-analyze выдаёт 2769ms.

Так как NetworkManager запускается также при старте программы входа в систему, можно отключить приводящую к загрузке  NetworkManagers зависимость на уровне multi-user, так как он всё равно будет параллельно запущен при запуске gdm, зависимость для которого остаётся.

   sudo rm /etc/systemd/system/multi-user.target.wants/NetworkManager.service

Проверяем время загрузки - 2603ms.

Для проверки насколько readahead влияет на время загрузки  для эксперимента временно выключим readahead:

   cd /lib/systemd/system  
   for i in *readahead*; do sudo systemctl mask $i;done

После перезагрузки systemd-analyze показывает 2547ms. Но несмотря на сокращение времени загрузки до запуска экрана входа в систему, сам э
кран визуально появляется с некоторой задержкой. Для того чтобы более точно оценить время загрузки воспользуемся секундомером.

   sudo dracut -f

Время загрузки с readahead и возвращённым initramfs:

   systemd-analyze
   Startup finished in 803ms (kernel) + 2217ms (initramfs) + 1018ms (userspace) = 4039ms

При сборке initramfs без plymouth и в режиме только хоста:

   sudo dracut -f -H -o plymouth

получаем:

   systemd-analyze
   Startup finished in 612ms (kernel) + 499ms (initramfs) + 1330ms (userspace) = 2443ms

Следует иметь в виде,  что сервисы  отключенные через "systemctl mask" при необходимости  можно в любой момент вернуть командой "systemctl unmask".

URL: http://www.harald-hoyer.de/personal/blog/fedora-17-boot-opti...
Обсуждается: http://www.opennet.ru/tips/info/2695.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Сокращение времени загрузки Fedora 17 c 15 до 3 секунд"  +/
Сообщение от Anonymousw on 31-Май-12, 19:56 
тут не сказано про настрйки prelink и как быть с wine, так-как prelink "убивает" вайн если проходиться по его компонентам, ещё есть e4rat который дефрагментит и предзагружает файлы для загрузки, но это не более чем изврат.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Сокращение времени загрузки Fedora 17 c 15 до 3 секунд"  +/
Сообщение от pavlinux (ok) on 31-Май-12, 20:00 
>  Опции "raid=noautodetect" и "libahci.ignore_sss=1" позволяют ускорить время
> инициализации ядра из-за пропуска дополнительных проверок.

После сделать dmesg | grep 'lpj='
и дописать в ядро этот loop per jitter, например lpj=11111111
(по 50 мс на ядро, cэкономит.)

А так же,
- похрерачить все символы через strip -S
- дисковый раздел должен быть один! Никаких /boot, /run, /var...
- в ядре дефлотным IO шыдулером сделать deadline, потом менять на нужный...
...

B И ваще, оптимизация начинается с кастрации ядра, чтоб не писать raid=noautodetect :)


> irqbalance

Уже сто тыщь раз писали, что с меньше чем 8 ПРОЦЕССОРАМИ (не ядрами),
оно без полезно в режиме демона, можно раз в полчаса вызывать с флагом --oneshot


Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Сокращение времени загрузки Fedora 17 c 15 до 3 секунд"  +/
Сообщение от Аноним (??) on 31-Май-12, 22:00 
> А так же,
> - похрерачить все символы через strip -S

символы в отдельных пакетах -debuginfo, которые по умолчанию не установлены

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "Сокращение времени загрузки Fedora 17 c 15 до 3 секунд"  +/
Сообщение от an. on 31-Май-12, 23:06 
> символы в отдельных пакетах -debuginfo, которые по умолчанию не установлены

символы (отладочная информация) - да, отдельно, но после компиляции в библиотеках все равно хранятся имена функций, которые можно удалить с помощью strip (подробности man strip).

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Сокращение времени загрузки Fedora 17 c 15 до 3 секунд"  +/
Сообщение от Аноним (??) on 31-Май-12, 23:26 
/usr/lib/rpm/redhat/brp-strip-static-archive выполняет 'strip -g' , а это то же, что и 'strip -S'
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Сокращение времени загрузки Fedora 17 c 15 до 3 секунд"  +/
Сообщение от pavlinux (ok) on 01-Июн-12, 00:40 
Ах да, теперь маленькая -s (ака --strip-all), раньше -S ваще не было.  

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

3. "Сокращение времени загрузки Fedora 17 c 15 до 3 секунд"  +/
Сообщение от pavlinux (ok) on 31-Май-12, 20:12 
> sudo rm /etc/systemd/system/multi-user.target.wants/NetworkManager.service

Уважаю! :)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Сокращение времени загрузки Fedora 17 c 15 до 3 секунд"  +/
Сообщение от xandry (ok) on 01-Июн-12, 21:27 
> Опции "raid=noautodetect" и "libahci.ignore_sss=1" позволяют ускорить время

инициализации ядра из-за пропуска дополнительных проверок.

Каких проверок? Если с "raid=noautodetect" всё более менее понятно из названия, то что делает "libahci.ignore_sss=1"?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Сокращение времени загрузки Fedora 17 c 15 до 3 секунд"  +/
Сообщение от pavlinux (ok) on 02-Июн-12, 03:39 
> ... что делает "libahci.ignore_sss=1"?

Дикий баян, за 2009 год. Тогда уже юзали в Оpenembbedded, OSADL, RTLinux, ART Linux,
в OpenSuSE оно с версии ядра 2.6.33,...  
Короче все, кроме фидорасов, а тут ёптя, проснулись. :)
---

ignore_sss - "Ignore staggered spinup flag", 0=don't ignore, 1=ignore.


10.9 Staggered Spin-up Operation

  Staggered spin-up is an optional feature in the Serial ATA II: Extensions to Serial ATA 1.0a revision 1.2
specification. This feature enables an HBA to individually spin-up attached devices. The feature is useful
to avoid having a power supply that must handle maximum current draw from all devices at the same time
when applying power to the devices. In order for a system to support staggered spin-up, the devices, the
HBA, and BIOS/driver must all support staggered spin-up.
  In systems that support staggered spin-up, an HBA can individually spin-up devices connected to
implemented SATA ports. In systems that do not support staggered spin-up, the HBA spins up all
connected SATA devices upon receiving power to the HBA.
  Staggered spin-up is only performed when power is applied to the drive. If the drive has been spun-down
due to an ATA command (e.g. STANDBY) and the device continues to be powered, the drive will not
spin-up again until access to the media is required – the staggered spin-up mechanism is not invoked in
this case. Note that when a system transitions to system power management state S3 or greater, the
drive will cease having power applied. Since the drive loses power, when the drive is powered back on in
the transition back to S0, the drive will undergo another staggered spin-up process.
  
HBAs that support staggered spin-up shall have the following additional features:

• CAP.SSS shall be set.
• For each port, PxCMD.SUD shall be read/write.

http://www.intel.com/content/www/us/en/io/serial-ata/serial-...


ahci: add a module parameter to ignore the SSS flags for async scanning
    
    The SSS flag, which directs the OS to spin up one disk at a time
    to not have the PSU blow out, sometimes gets set even when not needed.
    The effect of this is a longer-than-needed boot time.
    
    This patch adds a module parameter that makes the driver ignore SSS
    at least as far as the parallel scan during boot is concerned...

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "Сокращение времени загрузки Fedora 17 c 15 до 3 секунд"  +/
Сообщение от Аноним (??) on 20-Июн-12, 18:12 
> 17 c 15 до 3 секунд?

Так со скольких до скольки?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Сокращение времени загрузки Fedora 17 c 15 до 3 секунд"  +/
Сообщение от СуперАноним on 24-Июн-12, 12:48 
Лучше потерять время на монтирование при загрузке, но сделать отдельный раздел для /home, чем париться с копированием туда-сюда при необходимости полной переустановки системы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Сокращение времени загрузки Fedora 17 c 15 до 3 секунд"  +/
Сообщение от Feodor Slonikov on 13-Янв-13, 00:25 
> Лучше потерять время на монтирование при загрузке, но сделать отдельный раздел для
> /home, чем париться с копированием туда-сюда при необходимости полной переустановки системы.

после этой оптимизации чего улучшение всего 8 сек вместо обещанных много :)
но  проблемка появилась не переключается раскладка  комбинации клавиш менял но переключить получается только выбором в панели keyboard layouts
спасайте меня все! и со старым новым годом :)

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Сокращение времени загрузки "  +/
Сообщение от partizan email(??) on 23-Дек-14, 12:03 
У меня вообще что-то странное случилось. Время загрузки более 3-х минут.

[root@comp-celeron-cpu-c52aa6 ~]# sudo systemd-analyze
Startup finished in 3.985s (kernel) + 3min 884ms (userspace) = 3min 4.870s
[root@comp-celeron-cpu-c52aa6 ~]#

что делать с этим (userspace)?
Система перестала вообще грузится, т.к. диск забился под завязку всяким хламом (как я потом выяснил). Диск почистил от мусора. Стала загружаться система. Но вот так надолго подвисает.

В Линукс я не эксперт. Подскажите хоть направление, где искать решение.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру