[Comm] планировщик , ещё к вопросу о " стабилизации "

[Comm] планировщик , ещё к вопросу о " стабилизации "

[Gleb Kulikov]

Джентельмены,

а виден ли свет в конце туннеля? Вряд ли нормальная ситуация, что на 
*незагруженной* системе

2.6.12-std26-up-alt10 #1 Tue Feb 28 17:29:17 MSK 2006 i686 unknown unknown 
GNU/Linux

top - 22:35:12 up  1:11,  1 users,  load average: 2.46, 2.52, 2.36

На ядре wks, ситуация чуть получше --- 1 с копейками (хоть музыку/кино можно 
послушать, на std --- абсолютно исключено!)

при прочих равных, но на Мастере (Linux tsk-523-56 2.4.26-std-up-alt13 #1 Mon 
Nov 14 00:25:14 MSK 2005 i686 unknown unknown GNU/Linux),
на том же железе

22:38:24  up 15:39,  4 users,  load average: 0,26, 0,33, 0,31
97 processes: 92 sleeping, 5 running, 0 zombie, 0 stopped
CPU states:  1,8% user,  1,2% system, 22,3% nice,  0,0% iowait, 74,5% idle

Это при том, что запущено два x-сервера, работают 4 человека, тв тюнер
вещает на второй x-сервер.

Извиняюсь за "спам", но это же ни в какие ворота не лезет. Какой новый 
дистрибутив, какая "стабилизация", ребята, о чём вы? С *этим*, просто 
невозможно работать, неужели никто не обращал внимания на это дерьмо? 
Какой дистрибутив, как только *это* пойдёт на сервера, поднимется *такой* вой, 
и правильно.

Ещё раз извиняюсь, но просидев пол года под Компактом с этими *жутчайшими* 
тормозами системы, ну, я не знаю... разные мысли в голову приходят.

Кстати, никто не натыкался, как ЭТО выглядит на сервере? Довольно мощная, 3 
ГГц (! тут должен стоять неопределённый артикль б...), 512 Мб ОЗУ, машина, 
обслуживала 5 клиентов с /home на NFS. При незагруженной сети, но сколь 
мало-мальской загрузке процессора на сервере происходит что? Правильно. Все 
клиенты стоят раком (от нескольких до десятков минут), ибо nfs недоступна. На 
самом сервере видим не менее чудную картину: не срабатывают семафоры и т.п., 
сигналы не доставляются. В частности, наблюдаем "зависание" некоторых 
программ, а-ля konsole. 

Ежу понятно, что на Мастере (или 2.4.xxx, уж не знаю, какая фраза в данном 
случае корректна), ничего подобного *никогда* не наблюдалось, даже на 
несравнимо мснее мощном железе.

Ещё раз извинияюсь, но наболело. Откровенно задрало. Работать с *этим*, 
невозможно. Мысль о новом дистрибутиве с такими милыми свойствами, приводит в 
ужас.

Итак, кто виноват? Мэйнстрим? Локальная сборка? Возможно ли с этим что-то 
сделать?

В Сизифе ядра лучше? Будут ли сборки для Компакта? (ставить Сизиф на рабочие 
машины, ясно дело, невозможно, а на не находящихся под реальной работой --- 
от тестов, мало проку).

PS: Интересно, что wks ядро, ведёт себя заметно лучше. Дык, в чём проблема, 
товарищи "ядерщики"?
-- 
      Салют, /GLeb

UIN: 15341920
jabber://gleb@asd.iao.ru
sip://2387245@sipnet.ru			(telephony)
skype://gleb_kulikov.tomsk		(telephony)
sip://20000204@sip.pctel.ru		(telephony)
netmail: 2:5005/78

Re: [Comm] планировщик , ещё к вопросу о " стабилизации "

[Damir Shayhutdinov]

> а виден ли свет в конце туннеля? Вряд ли нормальная ситуация, что на
> *незагруженной* системе
>
> 2.6.12-std26-up-alt10 #1 Tue Feb 28 17:29:17 MSK 2006 i686 unknown unknown
> GNU/Linux
>
> top - 22:35:12 up  1:11,  1 users,  load average: 2.46, 2.52, 2.36
А что у вас в top по процессам творится? Кто кушает проц?

Re: [Comm] планировщик , ещё к вопросу о " стабилизации "

[Gleb Kulikov]

В сообщении от Вторник 26 Сентябрь 2006 23:15 Damir Shayhutdinov написал:

> А что у вас в top по процессам творится? Кто кушает проц?

а особо, никто:

top - 23:23:27 up  1:59,  4 users,  load average: 5.21, 6.17, 5.27
Tasks: 105 total,   1 running, 104 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.9% us,  2.0% sy,  0.0% ni,  0.0% id, 93.8% wa,  0.3% hi,  0.0% si
Mem:    240632k total,   229108k used,    11524k free,     5616k buffers
Swap:   586616k total,     2560k used,   584056k free,   111248k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7336 root      17   0  2036 1060  812 R  1.6  0.4   0:00.64 top
 6020 gleb      16   0 28800  15m  12m S  0.7  6.4   0:30.65 konsole
 6671 root      16   0  1872  816  664 S  0.7  0.3   0:04.59 watch
 4737 root      15   0 78116 8936 2088 S  0.3  3.7   0:27.55 X
 4887 root      15   0 21436  11m 9868 S  0.3  5.0   0:30.22 kdm_greet
 6669 root      16   0  8396 2912 2132 S  0.3  1.2   0:01.69 xterm
 6836 gleb      15   0 55324  37m  23m S  0.3 15.9   0:30.40 kmail
    1 root      16   0  1452  480  424 S  0.0  0.2   0:00.97 init
    2 root      34  19     0    0    0 S  0.0  0.0   0:00.37 ksoftirqd/0
    3 root      10  -5     0    0    0 S  0.0  0.0   0:00.27 events/0
    4 root      10  -5     0    0    0 S  0.0  0.0   0:00.05 khelper
    5 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kthread  

и т.д.

-- 
      Салют, /GLeb

UIN: 15341920
jabber://gleb@asd.iao.ru
sip://2387245@sipnet.ru			(telephony)
skype://gleb_kulikov.tomsk		(telephony)
sip://20000204@sip.pctel.ru		(telephony)
netmail: 2:5005/78

Re: [Comm] планировщик , ещё к вопросу о " стабилизации "

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

On Tue, Sep 26, 2006 at 11:24:17PM +0700, Gleb Kulikov wrote:
> В сообщении от Вторник 26 Сентябрь 2006 23:15 Damir Shayhutdinov написал:
> 
> > А что у вас в top по процессам творится? Кто кушает проц?
> 
> а особо, никто:
> 
> top - 23:23:27 up  1:59,  4 users,  load average: 5.21, 6.17, 5.27
> Tasks: 105 total,   1 running, 104 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.9% us,  2.0% sy,  0.0% ni,  0.0% id, 93.8% wa,  0.3% hi,  0.0% si
                                                  ^^^^^^^^
Нужно ещё посмотреть процессы в состоянии D (uninterruptible sleep).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] [d-kernel] собственно , USB и картина маслом (compact 3)

[Michael Shigorin]

On Tue, Sep 26, 2006 at 10:27:33PM +0700, Gleb Kulikov wrote:
> PS: Это всё к словам о "стабилизации" и прочая. Куда уж найти
> более фундаментальные глюки...

On Tue, Sep 26, 2006 at 10:57:29PM +0700, Gleb Kulikov wrote:
> а виден ли свет в конце туннеля? Вряд ли нормальная ситуация,
> что на *незагруженной* системе 2.6.12-std26-up-alt10

Ну если есть возможность, я бы на отдельный небольшой раздел
(возможно, своп) всандалил Sisyphus-current и посмотрел на то,
что творится сейчас.  Как обычно, разбирать уже почти прошлый
выпуск под уже почти новый благородно, но непродуктивно :-(

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] [d-kernel] собственно , USB и картина маслом (compact 3)

[Gleb Kulikov]

В сообщении от Среда 27 Сентябрь 2006 02:15 Michael Shigorin написал:

> Ну если есть возможность, я бы на отдельный небольшой раздел
> (возможно, своп) всандалил Sisyphus-current и посмотрел на то,
> что творится сейчас.  Как обычно, разбирать уже почти прошлый
> выпуск под уже почти новый благородно, но непродуктивно :-(

Сложно. Много качать (проверять-то надо по возможности, полную систему, ага?), 
почти нереально.

Михаил, я не хотел никого обидеть, поймите правильно. Но как иначе, ведь это 
фундаментальные, даже не "глюки", просчёты. И в них надо разбираться, имхо. 
Если виноват мэйнстрим, так значит, надо об этом орать на каждом углу. И 
тюкать разработчиков, пока не проникнутся :)

Система по факту, превращается в неработоспособную, глюк с несрабатыванием 
семафоров и пропуском сигналов, меня убил.  Надо же разбираться... когда 3 
гигагерцовая машина не может обслужить 5 хилых клиентов --- я не знаю, как 
это назвать. Что это, дефекты локальной сборки, побочный эффект отсутствия до 
сих пор ?!!! NPTL, глобальные просчёты в проектировании ядра --- надо же 
понять, в чём проблема.  Когда Вы говорите, что подобное поведение наблюдали 
один раз за прошедший год --- верю, но у меня на всех, а это несколько 
десятков машин --- наблюдаются эффекты аномально высокой "загрузки" 
процессора, а точнее, плохого планирования. Возможно, у вас машины побыстрее, 
и это не так заметно, или дефект исправлен на новых ядрах -- но мне-то это 
проверить, невозможно, поэтому и дёргаюсь!

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

А на сизифе, имхо, реальное тестирование таких фундаментальных штучек, 
невозможно: глюки проявляются при длительной *реальной* работе. По-моему, 
хорошо бы выпускать для компакта новые ядра, пусть даже и ценой существенного 
изменения логики работы базовых подсистем, но это возможность реального 
тестирования на гораздо бОльшем, чем у Сизифа, подмножестве пользователей. 
Раз уж заявили окончательный переход на новое ядро, а оно вон как 
оказывается... скреплённым жвачкой и изолентой, и разваливающимся при самом 
слабом ветре.

-- 
      Салют, /GLeb

UIN: 15341920
jabber://gleb@asd.iao.ru
sip://2387245@sipnet.ru			(telephony)
skype://gleb_kulikov.tomsk		(telephony)
sip://20000204@sip.pctel.ru		(telephony)
netmail: 2:5005/78

Re: [Comm] [d-kernel] собственно , USB и картина маслом (compact 3)

[Michael Shigorin]

On Wed, Sep 27, 2006 at 09:40:05AM +0700, Gleb Kulikov wrote:
> Сложно. Много качать (проверять-то надо по возможности, полную
> систему, ага?), почти нереально.

Зачем полную?  Минимальную с необходимым для монтирования.

> Михаил, я не хотел никого обидеть, поймите правильно.

Да понимаю.

> Но как иначе, ведь это фундаментальные, даже не "глюки",
> просчёты. И в них надо разбираться, имхо.  Если виноват
> мэйнстрим, так значит, надо об этом орать на каждом углу.
> И тюкать разработчиков, пока не проникнутся :)

А они годами могут проникаться.  Мы тут с год тому делали
подставку под одну штуковину (мультитредовый специализированный
сервер), так там только после снижения HZ с 1000 до 100, как
в 2.4, удалось на 2.6.10 терять всего (!) 20% производительности
относительно RH7.3.  При рядом стоящих 2.6 и 2.4 загрузка в
старое ядро тоже не радовала -- оно просто взлетало относительно
2.6...

> Система по факту, превращается в неработоспособную, глюк с
> несрабатыванием семафоров и пропуском сигналов, меня убил.

Я бы сперва железо думал.  memtest, cpuburn, ...

> Надо же разбираться... когда 3 гигагерцовая машина не может
> обслужить 5 хилых клиентов --- я не знаю, как это назвать. Что
> это, дефекты локальной сборки, побочный эффект отсутствия до
> сих пор ?!!!

Ну мне вот не попадалось.

> NPTL, глобальные просчёты в проектировании ядра --- надо же
> понять, в чём проблема.  Когда Вы говорите, что подобное
> поведение наблюдали один раз за прошедший год --- верю, но у
> меня на всех, а это несколько десятков машин --- наблюдаются
> эффекты аномально высокой "загрузки" процессора, а точнее,
> плохого планирования. Возможно, у вас машины побыстрее,

Ага, начиная с Cel433.

> и это не так заметно, или дефект исправлен на новых ядрах -- но
> мне-то это проверить, невозможно, поэтому и дёргаюсь!

Стоп.  На каких это вылазит/началось?

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

Надо.  Только мне, например, переубеждать кого-нить в LKML слабо,
поскольку сам вовсе не ядрописец.  А капать на мозги vsu@ или
lakostis@ бессмысленно по той банальной причине, что они и так
делают всё, что могут.

В частности, и поэтому сравнивать последние 2.4 (e.g. 2.4.26)
и первые 2.6 (~2.6.8) было совсем грустно.

> А на сизифе, имхо, реальное тестирование таких фундаментальных
> штучек, невозможно: глюки проявляются при длительной *реальной*
> работе.

С openvz и vserver получается иметь под сизифом и свежим ядром
стабильное окружение (или даже несколько).  У нас сейчас вон 
LTSP с ALC3.0 работает под Sisyphus/x86_64.

> По-моему, хорошо бы выпускать для компакта новые ядра, пусть
> даже и ценой существенного изменения логики работы базовых
> подсистем, но это возможность реального тестирования на гораздо
> бОльшем, чем у Сизифа, подмножестве пользователей.

Понимаете, сейчас проблема не в недостатке тестирования как
такового, бишь input.  Скорее с тем, чтобы хотя бы уже имеющийся
отработать.  Пока это не изменится, напрягаться на то, чтобы
увеличить количество того, с чем не получается справиться,
неразумно.

> Раз уж заявили окончательный переход на новое ядро, а оно вон
> как оказывается... скреплённым жвачкой и изолентой, и
> разваливающимся при самом слабом ветре.

Не, ну его уже довольно давно собирает стабильный майнтейнер. :)

Глеб, вообще если есть какое-то время/здоровье и странный
энтузиазм -- пойдёмте в команду.  Иногда действительно
получается, что небольшое приложение напильника позволяет
разгрузить тех, кого в результате можно попросить обратить
более пристальное внимание на более важные проблемы, чем
мелочёвка всякая.

Например, посмотрите в bugzilla на баги, которые сейчас висят на
nobody altlinux org -- есть ли среди них интересные и которые
вроде как посильно починить?

Ну и разумеется -- перед тем, как тратить на что-то заметное 
время, стоит посмотреть и взвесить свои варианты.  Я с год
назад этим озадачивался; результат, думаю, понятен.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] [d-kernel] собственно , USB и картина маслом (compact 3)

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]

On Срд, 2006-09-27 at 09:40 +0700, Gleb Kulikov wrote:
> Но как иначе, ведь это фундаментальные, даже не "глюки", просчёты. И в
> них надо разбираться, имхо.  Если виноват мэйнстрим, так значит, надо
> об этом орать на каждом углу. И тюкать разработчиков, пока не
> проникнутся :)

Честно говоря, пока вы не сообщили ничего о чём можно было бы орать
мэйнстриму. Пока вы только показали uptime и кусочек top'а но ничего
больше! По сути вы сказали у меня всё не работает. Но для разработчика
это ровным словом ни о чём не говорит [1]. Признаюсь, я мало работал с
altlinux'ом, но ставил compact 3.0 на roverbook и на какую-то ещё тачку.
И не наблюдал вашей проблемы! Брат до сих пор играется с roverbook'м и
пока не жаловался... При сам собирал и ставил ядра начиная с 2.6.6 (а
как известно самосборка, по идее, должна добавить глюков а не убрать. Не
так ли?). И конечно были oops'ы связанные с hyperthread'ом проблемы,
были связанные с netfilter, но не с производительностью! Начиная с
2.6.8.1 я использовал ядра на 7 разных машинах в разных конфигурациях
и ... ничего подобного...

2.6.13 i686 Pentium III (Coppermine) GNU/Linux
2.6.13 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz
2.6.17 x86_64 Intel(R) Pentium(R) 4 CPU 3.20GHz
2.6.17-mppe-mppc i686 Intel(R) Pentium(R) 4 CPU 3.20GHz
2.6.17 x86_64 AMD Sempron(tm) Processor 2600+

На 2.6.12 тоже ничего подобного не было.

Несомненно нужно понять в чём у вас проблема, но я практически уверен,
что пока вы не начнёте сами копать и разбираться в чём у вас проблема
мало кто из разработчиков поможет вам чем-нибудь, кроме советом
поменять/поиграть версиями... Скорее всего у разработчиков всё
работает... Эй, разработчики и пользователи у вас работает???

Что так влияет на загрузку сервера? Попробуйте включать/выключить разные
сервисы. Будет ли тоже самое если вы init подмените /bin/bash? В другом
треде вам предлагалось посмотреть а процессы в uninterpretable sleep.
Так что там? Но вместо ответа вы снова жалуетесь...

Ссылочка:
[1] http://ln.com.ua/~openxs/articles/smart-questions-ru.html

Peter.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]