Bug 14660 - надо ускорить выполнение service network stop (в основном, касается перезагрузки)
Summary: надо ускорить выполнение service network stop (в основном, касается перезагру...
Status: CLOSED NOTABUG
Alias: None
Product: Sisyphus
Classification: Development
Component: etcnet (show other bugs)
Version: unstable
Hardware: all Linux
: P2 enhancement
Assignee: Mikhail Efremov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-26 16:45 MSK by Sergey Y. Afonin
Modified: 2015-08-30 17:56 MSK (History)
7 users (show)

See Also:


Attachments
набор 802.1q интерфейсов (10.60 KB, application/octet-stream)
2008-03-12 22:10 MSK, Sergey Y. Afonin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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
Проблему объехали, вопрос закрываю.