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

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

[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%
быстрее, но решением проблемы это не назовёшь.

-- 
			WBR, Alex.

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

[Pavel Labushev]

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

On Mon, 9 Sep 2013 20:24:05 +0300
Alex Efros <powerman@powerman.name> wrote:

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

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

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

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

[Taz]

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

А если стрейсом/дебаггером побегать?
10 сент. 2013 г. 11:20 пользователь "Pavel Labushev" <
pavel.labushev@runbox.no> написал:

> On Mon, 9 Sep 2013 20:24:05 +0300
> Alex Efros <powerman@powerman.name> wrote:
>
> > При этом в portage-2.1.12.2 эта команда отрабатывает за 50 секунд,
> > а в portage-2.2.1 за 3 минуты 2 секунды!
>
> Наблюдаю то же самое на 32-битном ядре. Если правильно помню, на
> 2.2.х тормоза начались давно, больше года назад. Как лечить, не знаю.
>

[-- Attachment #2: Type: text/html, Size: 1010 bytes --]

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

[Pavel Labushev]

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

On Tue, 10 Sep 2013 11:21:50 +0400
Taz <taz.inside@gmail.com> wrote:

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

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

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

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

[Sergey Popov]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Sergey Kobzar]

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 минуты я уже не обращаю внимания.

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

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

[Охрименко Александр]

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

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

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


10 сентября 2013 г., 13:32 пользователь Sergey Kobzar <sergey.kobzar@mail.ru
> написал:

> 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 минуты я уже не обращаю внимания.
>
> А вообще работать стало медленней - факт.
>
>
>

[-- Attachment #2: Type: text/html, Size: 3820 bytes --]

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

[Alex Efros]

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

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.

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

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

[Sergey Kokarev]

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

10.09.2013 21:35, Охрименко Александр пишет:
> Постепенно теряется смысл в компиляциях. Все тормозит. Не знаю как у
> вас. У меня Debian на виртуалке быстрее работает, чем Gentoo+Gnome на
> том же реальном железе. Может руки не те, Может флаг fast=true не
> включил где то...
>
> Охрименко А.А.
>
>
> 10 сентября 2013 г., 13:32 пользователь Sergey Kobzar
> <sergey.kobzar@mail.ru <mailto:sergey.kobzar@mail.ru>> написал:
>
>     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 конечно сам по себе не быстро работает, но сама
система у меня летает. Может просто это какой-то специфический глюк?

[-- Attachment #2: Type: text/html, Size: 5775 bytes --]

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

[Sergey Popov]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Taz]

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

2013/9/11 Sergey Popov <pinkbyte@gentoo.org>:
> 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
>

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

[Sergey Popov]

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

11.09.2013 12:12, Taz пишет:
> Так возьми и перепиши :)
> 
> 2013/9/11 Sergey Popov <pinkbyte@gentoo.org>:
>> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Alex Efros]

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.

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

[Sergey Popov]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Alex Efros]

Hi!

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

-- 
			WBR, Alex.

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

[Yuriy Rusinov]

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

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

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


2013/9/14 Alex Efros <powerman@powerman.name>

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


-- 
Best regards,
Sincerely yours,
Yuriy Rusinov.

[-- Attachment #2: Type: text/html, Size: 1009 bytes --]

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

[Sergey Kobzar]

On 09/14/13 10:50, Yuriy Rusinov wrote:
> Здравствуйте !
>
> Наверно Alex Efros прав, у меня дома стоит 64-битная, на работе --
> 32-битная, так тормоза проявляются только дома.
>
>
> 2013/9/14 Alex Efros <powerman@powerman.name
> <mailto:powerman@powerman.name>>
>
>     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 минутах реч не идет.

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

[a.a.okhrimenko]

А теперь переложите из памяти на диск и сравните производительность. Получим дельту которая идет на i/o дисковой подсистемы. 
-----Original Message-----
From: Sergey Kobzar <sergey.kobzar@mail.ru>
Date: Sat, 14 Sep 2013 18:36:28 
To: <gentoo-user-ru@lists.gentoo.org>
Reply-To: gentoo-user-ru@lists.gentoo.org
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 <powerman@powerman.name
> <mailto:powerman@powerman.name>>
>
>     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 минутах реч не идет.

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

[Alex Efros]

Hi!

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

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

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

-- 
			WBR, Alex.