тормоза emerge

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

тормоза emerge

Alex Efros-4
Hi!

В последнее время emerge -uDNpv world работает как-то уж слишком долго.
Даже если обновлять нечего, команда запускается уже не в первый раз
(так что обращений к винту нет вообще, всё закешировано) и ей никто не
мешает жрать 100% CPU (точнее, одного ядра).

У меня достаточно быстрый проц (Core i7-2600K, разогнанный на 4.6GHz).
Обычная amd64 рабочая станция (1450 пакетов, из них 450 в world-файле).

При этом в portage-2.1.12.2 эта команда отрабатывает за 50 секунд,
а в portage-2.2.1 за 3 минуты 2 секунды!

Так у всех, или это у меня какие-то проблемы?
И если так у всех, то что за фигня творится, и можно ли её как-то пофиксить?


P.S. Сейчас ещё замерил на portage-2.2.1 system - 1 минута 7 секунд - и
максимально стандартный system (закомментировал все USE-флаги в make.conf
и удалил /etc/portage/) - 2 минуты 22 секунды.

P.P.S. Переключился с python 2.7 на 3.2 - стало отрабатывать на 15%
быстрее, но решением проблемы это не назовёшь.

--
                        WBR, Alex.

Reply | Threaded
Open this post in threaded view
|

Re: тормоза emerge

Pavel Labushev-4
On Mon, 9 Sep 2013 20:24:05 +0300
Alex Efros <[hidden email]> wrote:

> При этом в portage-2.1.12.2 эта команда отрабатывает за 50 секунд,
> а в portage-2.2.1 за 3 минуты 2 секунды!

Наблюдаю то же самое на 32-битном ядре. Если правильно помню, на
2.2.х тормоза начались давно, больше года назад. Как лечить, не знаю.

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] тормоза emerge

Taz-8
In reply to this post by Alex Efros-4

А если стрейсом/дебаггером побегать?

10 сент. 2013 г. 11:20 пользователь "Pavel Labushev" <[hidden email]> написал:
On Mon, 9 Sep 2013 20:24:05 +0300
Alex Efros <[hidden email]> wrote:

> При этом в portage-2.1.12.2 эта команда отрабатывает за 50 секунд,
> а в portage-2.2.1 за 3 минуты 2 секунды!

Наблюдаю то же самое на 32-битном ядре. Если правильно помню, на
2.2.х тормоза начались давно, больше года назад. Как лечить, не знаю.
Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] тормоза emerge

Pavel Labushev-4
On Tue, 10 Sep 2013 11:21:50 +0400
Taz <[hidden email]> wrote:

> А если стрейсом/дебаггером побегать?

Нет желания. Я редко пользуюсь emerge и только на одной машине с
небольшим набором пакетов.

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: тормоза emerge

Sergey Popov
In reply to this post by Alex Efros-4
09.09.2013 21:24, Alex Efros пишет:

> Hi!
>
> В последнее время emerge -uDNpv world работает как-то уж слишком долго.
> Даже если обновлять нечего, команда запускается уже не в первый раз
> (так что обращений к винту нет вообще, всё закешировано) и ей никто не
> мешает жрать 100% CPU (точнее, одного ядра).
>
> У меня достаточно быстрый проц (Core i7-2600K, разогнанный на 4.6GHz).
> Обычная amd64 рабочая станция (1450 пакетов, из них 450 в world-файле).
>
> При этом в portage-2.1.12.2 эта команда отрабатывает за 50 секунд,
> а в portage-2.2.1 за 3 минуты 2 секунды!
>
> Так у всех, или это у меня какие-то проблемы?
> И если так у всех, то что за фигня творится, и можно ли её как-то пофиксить?
>
>
> P.S. Сейчас ещё замерил на portage-2.2.1 system - 1 минута 7 секунд - и
> максимально стандартный system (закомментировал все USE-флаги в make.conf
> и удалил /etc/portage/) - 2 минуты 22 секунды.
>
> P.P.S. Переключился с python 2.7 на 3.2 - стало отрабатывать на 15%
> быстрее, но решением проблемы это не назовёшь.
>
Давно сижу на 2.2, поэтому к тормозам уже как-то привык, но всё же они
раздражают. Проблема обсасывалась много раз, без комплексного
переписывания потрохов portage ее не решить. Можно сколько угодно решать
ее экстенсивными методами(portage в sqlite, tmpfs, squashfs, на SSD и
т.д.) но это лишь маскирование проблемы.

--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


signature.asc (567 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: тормоза emerge

Sergey Kobzar-2
On 09/10/13 13:05, Sergey Popov wrote:

> 09.09.2013 21:24, Alex Efros пишет:
>> Hi!
>>
>> В последнее время emerge -uDNpv world работает как-то уж слишком долго.
>> Даже если обновлять нечего, команда запускается уже не в первый раз
>> (так что обращений к винту нет вообще, всё закешировано) и ей никто не
>> мешает жрать 100% CPU (точнее, одного ядра).
>>
>> У меня достаточно быстрый проц (Core i7-2600K, разогнанный на 4.6GHz).
>> Обычная amd64 рабочая станция (1450 пакетов, из них 450 в world-файле).
>>
>> При этом в portage-2.1.12.2 эта команда отрабатывает за 50 секунд,
>> а в portage-2.2.1 за 3 минуты 2 секунды!
>>
>> Так у всех, или это у меня какие-то проблемы?
>> И если так у всех, то что за фигня творится, и можно ли её как-то пофиксить?
>>
>>
>> P.S. Сейчас ещё замерил на portage-2.2.1 system - 1 минута 7 секунд - и
>> максимально стандартный system (закомментировал все USE-флаги в make.conf
>> и удалил /etc/portage/) - 2 минуты 22 секунды.
>>
>> P.P.S. Переключился с python 2.7 на 3.2 - стало отрабатывать на 15%
>> быстрее, но решением проблемы это не назовёшь.
>>
>
> Давно сижу на 2.2, поэтому к тормозам уже как-то привык, но всё же они
> раздражают. Проблема обсасывалась много раз, без комплексного
> переписывания потрохов portage ее не решить. Можно сколько угодно решать
> ее экстенсивными методами(portage в sqlite, tmpfs, squashfs, на SSD и
> т.д.) но это лишь маскирование проблемы.

Помнится у меня локальное обновление базы(!) портов FreeBSD занимало
30-60 минут в зависимости от харда.

Поэтому на 1-3 минуты я уже не обращаю внимания.

А вообще работать стало медленней - факт.


Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] тормоза emerge

a.a.okhrimenko
Постепенно теряется смысл в компиляциях. Все тормозит. Не знаю как у вас. У меня Debian на виртуалке быстрее работает, чем Gentoo+Gnome на том же реальном железе. Может руки не те, Может флаг fast=true не включил где то...

Охрименко А.А.


10 сентября 2013 г., 13:32 пользователь Sergey Kobzar <[hidden email]> написал:
On 09/10/13 13:05, Sergey Popov wrote:
09.09.2013 21:24, Alex Efros пишет:
Hi!

В последнее время emerge -uDNpv world работает как-то уж слишком долго.
Даже если обновлять нечего, команда запускается уже не в первый раз
(так что обращений к винту нет вообще, всё закешировано) и ей никто не
мешает жрать 100% CPU (точнее, одного ядра).

У меня достаточно быстрый проц (Core i7-2600K, разогнанный на 4.6GHz).
Обычная amd64 рабочая станция (1450 пакетов, из них 450 в world-файле).

При этом в portage-2.1.12.2 эта команда отрабатывает за 50 секунд,
а в portage-2.2.1 за 3 минуты 2 секунды!

Так у всех, или это у меня какие-то проблемы?
И если так у всех, то что за фигня творится, и можно ли её как-то пофиксить?


P.S. Сейчас ещё замерил на portage-2.2.1 system - 1 минута 7 секунд - и
максимально стандартный system (закомментировал все USE-флаги в make.conf
и удалил /etc/portage/) - 2 минуты 22 секунды.

P.P.S. Переключился с python 2.7 на 3.2 - стало отрабатывать на 15%
быстрее, но решением проблемы это не назовёшь.


Давно сижу на 2.2, поэтому к тормозам уже как-то привык, но всё же они
раздражают. Проблема обсасывалась много раз, без комплексного
переписывания потрохов portage ее не решить. Можно сколько угодно решать
ее экстенсивными методами(portage в sqlite, tmpfs, squashfs, на SSD и
т.д.) но это лишь маскирование проблемы.

Помнится у меня локальное обновление базы(!) портов FreeBSD занимало 30-60 минут в зависимости от харда.

Поэтому на 1-3 минуты я уже не обращаю внимания.

А вообще работать стало медленней - факт.



Reply | Threaded
Open this post in threaded view
|

Re: тормоза emerge

Alex Efros-4
In reply to this post by Sergey Popov
Hi!

On Tue, Sep 10, 2013 at 02:05:44PM +0400, Sergey Popov wrote:
> Давно сижу на 2.2, поэтому к тормозам уже как-то привык, но всё же они
> раздражают. Проблема обсасывалась много раз, без комплексного
> переписывания потрохов portage ее не решить. Можно сколько угодно решать
> ее экстенсивными методами(portage в sqlite, tmpfs, squashfs, на SSD и
> т.д.) но это лишь маскирование проблемы.

Не думаю, что эти методы помогут. У меня 8 гиг памяти, я запускал emerge
много раз подряд (так что всё нужное из /usr/portage было закешировано) и
в процессе следил за conky - обращений к винту за эти 3 минуты не было!
Всё это время ядро было нагружено на 100%, так что вряд ли дело в сисколах
(т.е. смотреть strace-ом смысла нет) и дело точно не в скорости винта
(команда time выдавала практически всё потраченное emerge время как user).

А кроме того, на мой вкус и на моём железе (не так давно это был почти
топовый игровой комп, да ещё и сильно разогнанный и по памяти и по процу)
даже 50 секунд у портаж 2.1 на то, чтобы не найти никаких обновлений - это
слишком долго! Серьёзно, у меня ядро быстрее компилируется! 3 минуты на то
же самое в портаж 2.2 - это уже просто свинство.

--
                        WBR, Alex.

attachment0 (197 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] тормоза emerge

Кокарев Сергей
In reply to this post by a.a.okhrimenko
10.09.2013 21:35, Охрименко Александр пишет:
Постепенно теряется смысл в компиляциях. Все тормозит. Не знаю как у вас. У меня Debian на виртуалке быстрее работает, чем Gentoo+Gnome на том же реальном железе. Может руки не те, Может флаг fast=true не включил где то...

Охрименко А.А.


10 сентября 2013 г., 13:32 пользователь Sergey Kobzar <[hidden email]> написал:
On 09/10/13 13:05, Sergey Popov wrote:
09.09.2013 21:24, Alex Efros пишет:
Hi!

В последнее время emerge -uDNpv world работает как-то уж слишком долго.
Даже если обновлять нечего, команда запускается уже не в первый раз
(так что обращений к винту нет вообще, всё закешировано) и ей никто не
мешает жрать 100% CPU (точнее, одного ядра).

У меня достаточно быстрый проц (Core i7-2600K, разогнанный на 4.6GHz).
Обычная amd64 рабочая станция (1450 пакетов, из них 450 в world-файле).

При этом в portage-2.1.12.2 эта команда отрабатывает за 50 секунд,
а в portage-2.2.1 за 3 минуты 2 секунды!

Так у всех, или это у меня какие-то проблемы?
И если так у всех, то что за фигня творится, и можно ли её как-то пофиксить?


P.S. Сейчас ещё замерил на portage-2.2.1 system - 1 минута 7 секунд - и
максимально стандартный system (закомментировал все USE-флаги в make.conf
и удалил /etc/portage/) - 2 минуты 22 секунды.

P.P.S. Переключился с python 2.7 на 3.2 - стало отрабатывать на 15%
быстрее, но решением проблемы это не назовёшь.


Давно сижу на 2.2, поэтому к тормозам уже как-то привык, но всё же они
раздражают. Проблема обсасывалась много раз, без комплексного
переписывания потрохов portage ее не решить. Можно сколько угодно решать
ее экстенсивными методами(portage в sqlite, tmpfs, squashfs, на SSD и
т.д.) но это лишь маскирование проблемы.

Помнится у меня локальное обновление базы(!) портов FreeBSD занимало 30-60 минут в зависимости от харда.

Поэтому на 1-3 минуты я уже не обращаю внимания.

А вообще работать стало медленней - факт.



Ну что Вы! emerge конечно сам по себе не быстро работает, но сама система у меня летает. Может просто это какой-то специфический глюк?
Reply | Threaded
Open this post in threaded view
|

Re: тормоза emerge

Sergey Popov
In reply to this post by Alex Efros-4
10.09.2013 21:03, Alex Efros пишет:
> А кроме того, на мой вкус и на моём железе (не так давно это был почти
> топовый игровой комп, да ещё и сильно разогнанный и по памяти и по процу)
> даже 50 секунд у портаж 2.1 на то, чтобы не найти никаких обновлений - это
> слишком долго! Серьёзно, у меня ядро быстрее компилируется! 3 минуты на то
> же самое в портаж 2.2 - это уже просто свинство.

Как я уже сказал, основная проблема скорости работы portage - в расчете
зависимостей. ЕМНИП до сих пор данный алгоритм выполняется однопоточно,
а с введением саб-слотов и использованием их в ебилдах процесс
выполнения этого алгоритм из небыстрого еще более замедлился.

Авторы portage утверждают что без полного переписывания внутренних
алгоритмов существенно ускорить его невозможно и ситуация будет лишь
усугубляться. А на переписывания не хватает ресурсов, в первую очередь
людских.

--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


signature.asc (567 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] тормоза emerge

Taz-8
Так возьми и перепиши :)

2013/9/11 Sergey Popov <[hidden email]>:

> 10.09.2013 21:03, Alex Efros пишет:
>> А кроме того, на мой вкус и на моём железе (не так давно это был почти
>> топовый игровой комп, да ещё и сильно разогнанный и по памяти и по процу)
>> даже 50 секунд у портаж 2.1 на то, чтобы не найти никаких обновлений - это
>> слишком долго! Серьёзно, у меня ядро быстрее компилируется! 3 минуты на то
>> же самое в портаж 2.2 - это уже просто свинство.
>
> Как я уже сказал, основная проблема скорости работы portage - в расчете
> зависимостей. ЕМНИП до сих пор данный алгоритм выполняется однопоточно,
> а с введением саб-слотов и использованием их в ебилдах процесс
> выполнения этого алгоритм из небыстрого еще более замедлился.
>
> Авторы portage утверждают что без полного переписывания внутренних
> алгоритмов существенно ускорить его невозможно и ситуация будет лишь
> усугубляться. А на переписывания не хватает ресурсов, в первую очередь
> людских.
>
> --
> Best regards, Sergey Popov
> Gentoo developer
> Gentoo Desktop Effects project lead
> Gentoo Qt project lead
> Gentoo Proxy maintainers project lead
>
Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] тормоза emerge

Sergey Popov
11.09.2013 12:12, Taz пишет:

> Так возьми и перепиши :)
>
> 2013/9/11 Sergey Popov <[hidden email]>:
>> 10.09.2013 21:03, Alex Efros пишет:
>>> А кроме того, на мой вкус и на моём железе (не так давно это был почти
>>> топовый игровой комп, да ещё и сильно разогнанный и по памяти и по процу)
>>> даже 50 секунд у портаж 2.1 на то, чтобы не найти никаких обновлений - это
>>> слишком долго! Серьёзно, у меня ядро быстрее компилируется! 3 минуты на то
>>> же самое в портаж 2.2 - это уже просто свинство.
>>
>> Как я уже сказал, основная проблема скорости работы portage - в расчете
>> зависимостей. ЕМНИП до сих пор данный алгоритм выполняется однопоточно,
>> а с введением саб-слотов и использованием их в ебилдах процесс
>> выполнения этого алгоритм из небыстрого еще более замедлился.
>>
>> Авторы portage утверждают что без полного переписывания внутренних
>> алгоритмов существенно ускорить его невозможно и ситуация будет лишь
>> усугубляться. А на переписывания не хватает ресурсов, в первую очередь
>> людских.
Из меня такой знаток Питона, что просто ах :-). А переписывать на C++ -
уже есть paludis.


--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


signature.asc (567 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: тормоза emerge

Alex Efros-4
In reply to this post by Sergey Popov
Hi!

On Wed, Sep 11, 2013 at 12:07:56PM +0400, Sergey Popov wrote:
> > даже 50 секунд у портаж 2.1 на то, чтобы не найти никаких обновлений - это
> > слишком долго! Серьёзно, у меня ядро быстрее компилируется! 3 минуты на то
> > же самое в портаж 2.2 - это уже просто свинство.
>
> Как я уже сказал, основная проблема скорости работы portage - в расчете
> зависимостей. ЕМНИП до сих пор данный алгоритм выполняется однопоточно,
> а с введением саб-слотов и использованием их в ебилдах процесс
> выполнения этого алгоритм из небыстрого еще более замедлился.

Интересно, какие именно полезные фичи добавили в портаж-2.2, что расчёт
зависимостей замедлился в 3.5 раза? Может просто откатиться на 2.1 и
забить на 2.2? Судя по файлу NEWS
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob_plain;f=NEWS;hb=master
в 2.2 нет ничего полезного.

--
                        WBR, Alex.

Reply | Threaded
Open this post in threaded view
|

Re: тормоза emerge

Sergey Popov
11.09.2013 15:36, Alex Efros пишет:
> Интересно, какие именно полезные фичи добавили в портаж-2.2, что расчёт
> зависимостей замедлился в 3.5 раза? Может просто откатиться на 2.1 и
> забить на 2.2? Судя по файлу NEWS
> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob_plain;f=NEWS;hb=master
> в 2.2 нет ничего полезного.
>

2.2 уже в stable, следовательно 2.1 примерно через год будет
замаскирован или дропнут до unstable(останется только для возможности
апгрейда старых необновленных систем). Поэтому, настоятельно рекомендую
всё же отправить багрепорт, приложив тесты, наглядно доказывающие регрессию.

Потому что переходить на 2.2 придется всё равно, так или иначе.

--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


signature.asc (567 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: тормоза emerge

Alex Efros-4
In reply to this post by Alex Efros-4
Hi!

Есть подозрение, что эти тормоза проявляются на 64-битных системах.
На моих 32-битных портаж во-первых работает в несколько (5-6) раз быстрее,
а во-вторых разницы в скорости между 2.1 и 2.2 нет.
Можете это подтвердить/опровергнуть, для статистики?

--
                        WBR, Alex.

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] тормоза emerge

YuriyRusinov
Здравствуйте !

Наверно Alex Efros прав, у меня дома стоит 64-битная, на работе -- 32-битная, так тормоза проявляются только дома.


2013/9/14 Alex Efros <[hidden email]>
Hi!

Есть подозрение, что эти тормоза проявляются на 64-битных системах.
На моих 32-битных портаж во-первых работает в несколько (5-6) раз быстрее,
а во-вторых разницы в скорости между 2.1 и 2.2 нет.
Можете это подтвердить/опровергнуть, для статистики?

--
                        WBR, Alex.




--
Best regards,
Sincerely yours,
Yuriy Rusinov.
Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] тормоза emerge

Sergey Kobzar-2
On 09/14/13 10:50, Yuriy Rusinov wrote:

> Здравствуйте !
>
> Наверно Alex Efros прав, у меня дома стоит 64-битная, на работе --
> 32-битная, так тормоза проявляются только дома.
>
>
> 2013/9/14 Alex Efros <[hidden email]
> <mailto:[hidden email]>>
>
>     Hi!
>
>     Есть подозрение, что эти тормоза проявляются на 64-битных системах.
>     На моих 32-битных портаж во-первых работает в несколько (5-6) раз
>     быстрее,
>     а во-вторых разницы в скорости между 2.1 и 2.2 нет.
>     Можете это подтвердить/опровергнуть, для статистики?

Linux 3.7.10-gentoo i686

дерево портовзакэшировано в памяти (недавно делал emerge --sync) -
обращений к диску в овремя emerge -upvDN world практически не было.

# time emerge -upvDN world
...
real    0m51.971s
user    0m51.287s
sys     0m0.398s

# equery list '*' | wc -l
497

Т.е. явно ни о каких 2-3 минутах реч не идет.

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] Re: [gentoo-user-ru] тормоза emerge

a.a.okhrimenko
А теперь переложите из памяти на диск и сравните производительность. Получим дельту которая идет на i/o дисковой подсистемы.
-----Original Message-----
From: Sergey Kobzar <[hidden email]>
Date: Sat, 14 Sep 2013 18:36:28
To: <[hidden email]>
Reply-To: [hidden email]
Subject: Re: [gentoo-user-ru] Re: [gentoo-user-ru] тормоза emerge

On 09/14/13 10:50, Yuriy Rusinov wrote:

> Здравствуйте !
>
> Наверно Alex Efros прав, у меня дома стоит 64-битная, на работе --
> 32-битная, так тормоза проявляются только дома.
>
>
> 2013/9/14 Alex Efros <[hidden email]
> <mailto:[hidden email]>>
>
>     Hi!
>
>     Есть подозрение, что эти тормоза проявляются на 64-битных системах.
>     На моих 32-битных портаж во-первых работает в несколько (5-6) раз
>     быстрее,
>     а во-вторых разницы в скорости между 2.1 и 2.2 нет.
>     Можете это подтвердить/опровергнуть, для статистики?

Linux 3.7.10-gentoo i686

дерево портовзакэшировано в памяти (недавно делал emerge --sync) -
обращений к диску в овремя emerge -upvDN world практически не было.

# time emerge -upvDN world
...
real    0m51.971s
user    0m51.287s
sys     0m0.398s

# equery list '*' | wc -l
497

Т.е. явно ни о каких 2-3 минутах реч не идет.

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] Re: [gentoo-user-ru] тормоза emerge

Alex Efros-4
Hi!

On Sat, Sep 14, 2013 at 08:27:23PM +0000, [hidden email] wrote:
> А теперь переложите из памяти на диск и сравните производительность.
> Получим дельту которая идет на i/o дисковой подсистемы.

Я уже мерял. Насколько я помню, на i/o уходит в несколько раз меньше
времени, чем на cpu. Так что тормозят именно вычисления на 64-битных
системах, а не дисковый i/o.

Когда узким местом станет диск - есть разные варианты. Например, засунуть
/usr/portage на squashfs с какой-то оверлейной fs поверх для --sync.
Правда, когда я последний раз это пытался сделать оказалось, что для этого
нужно патчить ядро, и был конфликт между этими и hardened патчами.

--
                        WBR, Alex.