Bug 14660

Summary: надо ускорить выполнение service network stop (в основном, касается перезагрузки)
Product: Sisyphus Reporter: Sergey Y. Afonin <asy>
Component: etcnetAssignee: Mikhail Efremov <sem>
Status: CLOSED NOTABUG QA Contact: qa-sisyphus
Severity: enhancement    
Priority: P2 CC: asy, ldv, mike, rider, sem, shaba, vseleznv
Version: unstable   
Hardware: all   
OS: Linux   
Attachments:
Description Flags
набор 802.1q интерфейсов none

Description Sergey Y. Afonin 2008-02-26 16:45:08 MSK 
Есть проблема долгой остановки сервиса. Например, в случае

# ip a|egrep "^[1-9]"|wc -l
133

команда reboot исполняется минут чуть ли не пять. Хотелось бы подумать, что с
этим можно сделать. В данном случае, основная масса - это 802.1q интерфейсы. В
принципе, я, пока, не представляю вариантов, когда интерфейсосов может быть
много, кроме этого случая и случая со всякими ppp. Соответственно, видятся такие
варианты:

1. Самый банальный. Для этого надо ответить на вопрос, а надо ли делать network
stop при перезагрузке. Если это ничем особенным не грозит, может быть поступить
по принципу init.d/halt c его разным наименованием, и, соответственно,
поведением для уровней 0 и 6 ?

2. Если проблемы предполагаются, думаю, можно не гасить некоторые типы
интерфейсов: они будут положены при отключении основного физического интерфейса,
как в случае с vlan.

3. Ускорить сам процесс для каждого интерфейса, хотя я не смотрел пока, возможно
ли это, и откуда задержка такая сама по себе. Хотя 1 и 2 останутся актуальны.
Comment 1 Sergey Y. Afonin 2008-02-26 16:55:23 MSK 
Кстати, в случае 1, можно просто убрать K90network из rc6.d и rc0.d
Comment 2 Denis Ovsienko 2008-02-26 17:00:24 MSK 
Если вручную выполнить service network stop и посмотреть на прогресс, то какая
именно стадия процесса занимает наибольшее время? И выполняется так же медленно
service network start?
Comment 3 Sergey Y. Afonin 2008-02-26 23:09:38 MSK 
Весь набор опытов не провёл, но на stop тратится примерно по 5 секунд на каждый
802.1q интерфейс. При загрузке network стартует всего (относительно) секунд за
30.  Завтра постораюсь подробнее посмотреть.
Comment 4 Sergey Y. Afonin 2008-02-27 12:23:24 MSK 
В общем, получается, что скорость остановки отдельно взятого интерфейса линейно 
зависит от их общего количества.
Comment 5 Denis Ovsienko 2008-02-27 13:10:42 MSK 
Ага, вот это интересно. Интерфейсы собраны через vlantab или каждый индивидуально?
Comment 6 Sergey Y. Afonin 2008-02-27 13:45:39 MSK 
Каждый индивидуально. vlantab оказался неудобен из-за необходимости 
индивидуально работы с интерфейсами. Кстати, пока экспериментировал, всплыл 
такой момент, что restart не трогает существующие интерфейсы, если информация о 
них удалена. Наверное, rmmod стоит делать при restart, несмотря на 
NEVER_RMMOD=yes. Это отдельным фичереквестом повесить ?
Comment 7 Denis Ovsienko 2008-03-12 13:47:53 MSK 
Архивом /etc/net не пришлёте мне для воспроизводства?
Comment 8 Sergey Y. Afonin 2008-03-12 22:10:27 MSK 
Created attachment 2494 [details]
набор 802.1q интерфейсов

Да там ничего особенного, главное количество. Я себе, для опытов, вот такой
набор насоздавал. С таким количеством у меня 3 секунды на интерфейс получается
примерно. Только я далеко не продвинулся: понятно только, что долго исполняются
вызовы вида 
/etc/net/scripts/ifdown eth0.23 skiphot
Comment 9 Denis Ovsienko 2008-03-15 14:20:13 MSK 
Воспроизвёл у себя.
Comment 10 Denis Ovsienko 2008-03-15 15:04:31 MSK 
Могу пояснить следующее: для каждого интерфейса в конфигурации по умолчанию
включена опция IFDOWN_CHILDREN. Это значит, что если какой-то другой интерфейс
имеет в REQUIRES или HOST имя текущего останавливаемого интерфейса, то этот
другой будет предварительно остановлен. Цепочки зависимостей могут иметь
произвольную длину, главное, чтобы они не были циклами (такие случаи
контролируются). Для того, чтобы эта схема работала, для каждого интерфейса
ищутся зависящие от него, а в условиях наследования опций и множественности
профилей для этого приходится выполнить pickup_options для каждого
потенциального интерфейса.
Таким образом, задача остановки всех имеет квадратичную сложность, а время
остановки каждого интерфейса действительно линейно зависит от их количества.
Алгоритму можно дать подсказку, которая его ускорит --- поместить в
/etc/net/ifaces/default/options-vlan строку "IFDOWN_CHILDREN=0". Это
подразумевает, что от VLAN-интерфейсов действительно не зависят другие
интерфейсы, например, туннели. Если же зависят, то для тех VLAN-интерфейсов,
которые упомянуты в REQUIRES или HOST, необходимо будет выборочно включить
IFDOWN_CHILDREN.
Попробуйте.
Comment 11 Sergey Y. Afonin 2008-03-15 20:34:17 MSK 
Стало значительно лучше, спасибо. Но вариант не делать network stop при reboot,
мне кажется, стоит обдумать. И rmmod при stop/restart.
Comment 12 Vladimir V. Kamarzin 2008-03-17 09:42:38 MSK 
Ну дак может сделать IFDOWN_CHILDREN=0 по дефолту для vlan-интерфейсов?
Comment 13 Sergey Y. Afonin 2008-03-17 10:03:22 MSK 
(In reply to comment #12)

Тут надо подумать/посмотреть, какие последствия это будет иметь, если к vlan 
привязать тонель. Теоретически должно нормально быть, а как на практике - 
вопрос. А с точки зрения вероятности ситуаций "много vlan" и "тонель через 
vlan", последняя, возможно, не менее вероятная...
Comment 14 Denis Ovsienko 2009-06-16 13:16:31 MSD 
Проблему объехали, вопрос закрываю.