Gentoo с каждым обновленимем работает все медленнее и медленее

Ручками удалить, ручками:

1) rm -r /var/tmp/portage/*

2) rm -r /usr/portage/distfiles/*

3) Довести систему до просветления, чтобы emerge --depclean не ломал ее, делать его регулярно

4) may be у тебя и набор старых gentoo-sources валяется еще?) Старая ж версия не сносится сама

Да, ну и df сколько кажет?

Почистил:

1) /var/tmp/portage/* примерно 58 Мб.

2) /usr/portage/distfiles/ - жалко удалять. Имхо на скорость не влияет.

3) df
Ф. система    Тип     Разм  Исп  Дост  Исп% смонтирована на
rootfs      rootfs    9,2G  7,8G  968M  90% /
/dev/root     ext3    9,2G  7,8G  968M  90% /
udev         tmpfs     10M  160K  9,9M   2% /dev
shm          tmpfs    442M     0  442M   0% /dev/shm
rc-svcdir    tmpfs    1,0M   96K  928K  10% /lib/rc/init.d
/dev/hda2     ext3     28G   24G  2,8G  90% /home
/home/distfiles
              ext3     28G   24G  2,8G  90% /usr/portage/distfiles

emerge --depclean написал вот такую петицию:
tux puh # emerge -av --depclean

*** WARNING ***  Depclean may break link level dependencies.  Thus, it is
*** WARNING ***  recommended to use a tool such as `revdep-rebuild` (from
*** WARNING ***  app-portage/gentoolkit) in order to detect such breakage.
*** WARNING ***
*** WARNING ***  Also study the list of packages to be cleaned for any obvious
*** WARNING ***  mistakes. Packages that are part of the world set will always
*** WARNING ***  be kept.  They can be manually added to this set with
*** WARNING ***  `emerge --noreplace <atom>`.  Packages that are listed in
*** WARNING ***  package.provided (see portage(5)) will be removed by
*** WARNING ***  depclean, even if they are part of the world set.
*** WARNING ***
*** WARNING ***  As a safety measure, depclean will not remove any packages
*** WARNING ***  unless *all* required dependencies have been resolved.  As a
*** WARNING ***  consequence, it is often necessary to run
*** WARNING ***  `emerge --update --newuse --deep world` prior to depclean.

emerge --depclean удалил 28 пакетов. Сейчас расскажу что отвалилось :):):)

Дефрагментацию пора делать.

А на будущее - разносить на разные разделы /home, /usr, /var, /var/tmp и /tmp :)

>А на будущее - разносить на разные разделы /home, /usr, /var, /var/tmp и /tmp :)

А можно пояснить смысл этого хотя бы поверхностно ? А то у меня с покупкой нового диска мысли - как лучше его разделить на партиции.

Лично мне *кажется*, что по сабжу лучше было просто не занимать никакие r/w разделы общего назначения более, чем на 70-80%. И, возможно, сменить ext3 на рейзера. Это помогло бы избежать проблемы?

Тупо: выдели раздел под дерево портежей - и, о чудо, фрагментирование файлов дерева портежей будет происходить только там, и фрагменты не будут размазываться по всему диску. Ферштейн? Дальше объяснять?

Теперь по поводу разбивки Вот мой вариант:
rootfs 957M 543M 415M 57% /
/dev/mapper/vg-opt 800M 676M 125M 85% /opt
/dev/mapper/vg-tmp 2.0G 33M 2.0G 2% /tmp
/dev/mapper/vg-usr 4.0G 4.0G 30M 100% /usr
/dev/mapper/vg-var 5.5G 5.3G 198M 97% /var
/dev/hda1 61M 13M 45M 22% /boot

opt,usr,var,tmp, как видно, сидят на LVM'e

/var/tmp был заменён симлинком на /tmp
portage-tree перенёс в /var/cache:
DISTDIR="/var/cache/portage/distfiles"
PKGDIR="/var/cache/portage/packages"
PORTAGE_NICENESS=10
PORTDIR="/var/cache/portage"
PORTAGE_TMPDIR="/tmp

>Ферштейн?

Ы-ы-ы, тока ща глянул в профиль котика :P . Тока не обижаться плиз, никаких тонких намёков тут не было :D

P.S. с.аная политкорректность.

>А можно пояснить смысл этого хотя бы поверхностно ?

В любой файловой системе есть такая мерзкая штука, как фрагментация свободного пространства. И когда через некоторое время удалений/обновлений файлов у тебя /var/tmp «размажется» по всей поверхности HDD, то винчестеру при работе придётся постоянно скакать от одного файла у другому для всего NNN-гигабайтного диска. И это катастрофически снижает производительность.

Вообще, типичный сценарий обновления пакета в Gentoo, когда /usr и /var/tmp в одном каталоге. Ты собираешь пакет. В процессе его сборки файлы раскидываются как бог на душу положит. Потом этот пакет, собранный, ставится в /usr. Но там уже каша. Файлы, опять, раскидываются куда попало и как попало... Потом, при запуске ещё незакешировавшейся программы, она свои компоненты со всего HDD будет собирать. Сколько дорожек в твоём HDD? Подели на два и получишь среднее предельное снижение скорости по сравнению с последовательным чтением файлов, расположенных плотно. Обычно счёт идёт на сотни, если не на тысячи.

...

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

>Это помогло бы избежать проблемы?

Немного. Это уменьшило бы фрегментацию файлов (у меня /var бывает до 30% фрагментирован :D). Но не уменьшило бы фрагментацию свободного пространства :-/

KRoN73, и не лениво тебе расписывать это ~каждые 2 месяца, если не чаще? :)

Не-а :) Я, вообще, монологи люблю ;) Мне лениво сделать соответствующую страничку и ссылку кидать :D

Думал что только в винде такая проблема :( А как можно определить процент фрагмениторвания?

>А как можно определить процент фрагмениторвания?

Вот, например, скриптик: http://forums.gentoo.org/viewtopic-p-3081971.html

О, это супер! Спасибо!

Любопытно, кстати, что этот скрипт покажет у топикстартера.

>А можно пояснить смысл этого хотя бы поверхностно ?

>В любой файловой системе есть такая мерзкая штука, как фрагментация свободного пространства.

Мне казалось что в журналируемых ФС есть встроенные механизмы защиты от сильной фрагментации... а небольшая фрагментация при кэшируемых операциях чтения/записи с/на диск пофигу... Или я ошибаюсь ?

а имеет смысл /var/tmp/portage кинуть в tmpfs (если памяти гига два-четыре?) а /var/cache/ccache, /var/cache/portage? Хотя, боюсь не влезет, а что-то вроде рамдиска с сохранением на винт раз в 15 минут для линукса не придумали?

> Мне казалось что в журналируемых ФС есть встроенные механизмы защиты от сильной фрагментации... а небольшая фрагментация при кэшируемых операциях чтения/записи с/на диск пофигу... Или я ошибаюсь ?

этот механизм более-менее работает если свободного места больше половины объема раздела. т.е. при записи один файл пишется последовательно а не по кусочкам забивается везде где только можно.

>а имеет смысл /var/tmp/portage

Для большинства пакетов подойдёт, но если попадётся что-нить крупное - звиняйте, emerge вывалится с ошибкой.

Но я бы использовал только в случае 4-х и более гигов RAM

>/var/cache/ccache, /var/cache/portage

Хи-хи-хи, а машинка то совсем не выключается и сверхнадёжна?

>Хотя, боюсь не влезет, а что-то вроде рамдиска с сохранением на винт раз в 15 минут для линукса не придумали?

На моей машинке 768мб, так что я даже не смотрел в эту сторону, sorry.

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

Это как-то регулируется в аллокаторе для конкретной ФС или свои наблюдения ? Мне кажется главное чтобы хватало места для непрерывной записи а сколько его там - пол диска или меньше осталось это неважно. Вообще вопрос с фрагментацией скользкий - я нигде не нашел четкого ответа - понятно что фрагментация есть в любой ФС - но так ли она страшна в linux ? Например при интенсивном использовании диска с множественными операциями чтения/записи (при доступе разных процессов к различным файлам) некоторые утвержадют что фрагментированная фс работает быстрей :)

>>Хотя, боюсь не влезет, а что-то вроде рамдиска с сохранением на винт раз в 15 минут для линукса не придумали?

>На моей машинке 768мб, так что я даже не смотрел в эту сторону, sorry.

а я разжился недавно вторым гигом, подумываю о 4х :)

под оффтопик есть драйвер рамдиска, который в фоне сохраняет своё состояние на винт каждые N минут. Получается и рамдиск, и состояние не теряется при выключении.

по идее, если просто тупо повесить в фоне демона, который будет rsync-ать tmpfs в локальный и надёжный раздел на винте :) раз в 5-10 минут, например. например, просыпаться, если есть открытые файлы на tmpfs , делать sync, и синхронизировать со снапшотом на винте. LVM поверх рамдиска со снапшотами -- это наверно черезчур :)) но в gentoo-wiki было про /usr/portage в cramfs+unionfs поверх для записи.

правда, наступит облом, если пока начало раздела будет rsync'аться, в хвост какой-то процесс будет писать. По идее заморозить бы все процессы с открытыми файлами на tmpfs, rsync-нуть бекап в snapshot, разморозить и поехать дальше.

или, как в висте, сделать RAID из флешек для кеширования записи на винт (если USB 2.0 не станет узким местом :))

>>В любой файловой системе есть такая мерзкая штука, как фрагментация свободного пространства.

>Мне казалось что в журналируемых ФС есть встроенные механизмы защиты от сильной фрагментации

Фрагментация файлов и фрагментация файлового пространства - это две огромных разницы.

Но даже защита от фрагментации файлов не всегда помогает. У меня сейчас /var/tmp фрагментирован на 32%. Свободно в нём 5,3Гб из 6,4.

>а имеет смысл /var/tmp/portage кинуть в tmpfs

Имеет. Так и делаю иногда. Но, к сожалению, та же сборка openoffice2 занимает более 5Гб места. Так что оперативки в этом случае нужно хотя бы 6Гб ;)

>/var/cache/ccache

Подразумевается /var/tmp/ccache? Проще тогда ccache вообще отключить. Ибо единственная его ценность - в повторном использовании через какое-то время, которое невозможно в tmpfs.

>/var/cache/portage

А это кто такой?

> Это как-то регулируется в аллокаторе для конкретной ФС или свои наблюдения ? Мне кажется главное чтобы хватало места для непрерывной записи а сколько его там - пол диска или меньше осталось это неважно. Вообще вопрос с фрагментацией скользкий - я нигде не нашел четкого ответа - понятно что фрагментация есть в любой ФС - но так ли она страшна в linux ? Например при интенсивном использовании диска с множественными операциями чтения/записи (при доступе разных процессов к различным файлам) некоторые утвержадют что фрагментированная фс работает быстрей :)

а вот хз. я кстати тоже не нашел нигде четкого описания. по моим наблюдениям, система начинала тормозить если раздел заполнен на 80-90 процентов (debian, ext3). после этого я форматнул раздел в reiserfs и часть восстановил а часть похерил. щас свободно 60% и стало намного быстрее шуршать.

а вообще, я щас все что только можно в tmpfs перенес.

>под оффтопик есть драйвер рамдиска, который в фоне сохраняет своё состояние на винт каждые N минут. Получается и рамдиск, и состояние не теряется при выключении.

Ну ты молодец - забивай ОЗУ калом всяким из тмп :) Только посматривай иногда вывод команды free - есть такие поля buffers/cache - формально это свободное место но если ты для них не оставишь ничего то тормозить будет не только чтение/запись на диске но и вся система.

>А это кто такой?

Посмотри по мой первый или второй пост.

>Фрагментация файлов и фрагментация файлового пространства - это две огромных разницы

Мне кажется разница не так огромна - первая замедляет чтение а вторая запись да и то только при отсутствии нефрагментированного свободоного места.

>Проще тогда ccache вообще отключить. Ибо единственная его ценность - в повторном использовании через какое-то время, которое невозможно в tmpfs.

а кстати, от него вообще польза есть? genlop -c пакет говорит, что новые версии ( kde, gcc, ядра, firefox ) со сменой минорной версии стало собираться раза в 2 дольше.

Что ccache может эффективно скешировать, а что -- ниасилит? если например USE=feature emerge bla-bla-bla && USE=-feature emerge bla-bla-bla -- что будет с кешем в ccache при второй сборке, кеш "вымоется"? А что тогда эффективно скешируется?

А то вот ./configure.sh например, чекает по-тупому каждый раз одно и то же заново в очередном пакете, выполняет заново те же самые проверки по второму разу. Вот как можно это скешировать, чтобы он не компилировал свои мини-сниппеты в очередной раз, а сразу выдал скешированное? Или, определил, что USE изменился, кеш сбросил, и перекомпилировал тест заново?

Ручки чешутся обёртку к ./configure.sh написать :)

> >Фрагментация файлов и фрагментация файлового пространства - это две огромных разницы

> Мне кажется разница не так огромна - первая замедляет чтение а вторая запись да и то только при отсутствии нефрагментированного свободоного места.

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

Gentoo RIP ☠☠☠☠☠?

Нет, просто неверно настроена.

>Мне кажется разница не так огромна

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

>а кстати, от него вообще польза есть?

Определённая есть. Компиляция уже компилировавшихся ранее файлов быстрее выполняется. Практического выигрыша не знаю, не измерял :)

Я же говорю - вопрос скользкий :) Интересовался этим вопросом и на многих форумах сходятся во мнении что фрагментация не так страшна в linux, пожалуй только тут я увидел мнения что она так катострофически влияет на скорость работы. Я пользуюсь CRUX - тоже sorce based дистрибутив как и gentoo - посмотрел фрагментацию скриптом http://forums.gentoo.org/viewtopic-p-3081971.html на своем старом диске на рзделе 10 Гб занят на 70% - показало около 8% (диск использовался чуть меньше года). Никогда не замечал никаких тормозов. Стоит ли так извращаться с разделами да еще с привлечением LVM на однодисковой машине ? :)

>Стоит ли так извращаться с разделами да еще с привлечением LVM на однодисковой машине ? :)

Это не извращения, а логически оправданные действия.

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

> Практического выигрыша не знаю, не измерял :)

afaik, в целом процентов на 20 ;)

Это по отношению cache hit / cache miss (CCACHE_DIR=/var/tmp/ccache/ ccache -s), а также отношение времени сборки с ним и без него. Хотя из кэша оно собирает во много раз быстрее, но cache hit всё равно мал по сравнению с miss. Это с кэшем 1 Gb.

Но, что более важно, оно во много раз ускоряет пересборку того, что ты только что собирал - а это обычно те случаи, когда что-то незаладилось, и ты hands-on крутишь use-флаги или зависимости. То есть экономия *твоего* времени гораздо выше 20%, хотя оценить её трудно.

Есть такая чепуха. Недавно кардинально лечил - копированием, удалением всего и копированием обратно. Дополнительно организовал еще такую шутку:
=================================================================
avatar@Nemesis ~ % mount
rootfs on / type rootfs (rw)
/dev/root on / type ext3 (rw,errors=continue,data=ordered)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
udev on /dev type tmpfs (rw,nosuid,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,size=151552k)
rc-svcdir on /lib/rc/init.d type tmpfs (rw,nosuid,nodev,noexec,size=1024k,mode=755)
/dev/mapper/System-usr on /usr type ext3 (rw,noatime)
/dev/mapper/System-avatar on /home/avatar type ext3 (rw,user_xattr)
/dev/mapper/System-music on /pub/music type ext3 (rw,user_xattr)
/dev/mapper/System-opt on /opt type ext3 (rw,noatime)
/dev/mapper/System-shared on /pub/shared type ext3 (rw,noatime,user_xattr)
/dev/mapper/System-var on /var type ext3 (rw,noatime)
/dev/mapper/System-log on /var/log type ext3 (rw)
/dev/mapper/System-build on /var/tmp/portage type reiserfs (rw,noatime)
/dev/mapper/System-netboot on /opt/netboot type ext3 (rw,noatime)
/dev/mapper/System-doc on /pub/library type ext3 (rw,noatime,user_xattr)
/dev/mapper/System-portage on /usr/portage type reiserfs (rw,noatime)
/dev/mapper/System-emul on /emul type ext3 (rw,noatime)
/dev/mapper/System-os--devel on /os-devel type ext3 (rw,noatime)
tmpfs on /tmp type tmpfs (rw,size=20M)
/pub/library/System/doc on /usr/share/doc type none (rw,bind)
/pub/library/System/man on /usr/share/man type none (rw,bind)
/pub/library/System/info on /usr/share/info type none (rw,bind)
usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=251)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
securityfs on /sys/kernel/security type securityfs (rw,noexec,nosuid,nodev)
10.0.1.11:/storage/fap on /mnt/storage/fap type nfs (rw,rsize=8192,wsize=8192,timeo=10,retrans=2,fg,hard,intr,addr=10.0.1.11)
10.0.1.11:/var/www on /var/www type nfs (rw,rsize=8192,wsize=8192,timeo=10,retrans=2,fg,hard,intr,addr=10.0.1.11)
10.0.1.11:/home on /home/remote type nfs (rw,rsize=8192,wsize=8192,timeo=10,retrans=2,fg,hard,intr,addr=10.0.1.11)
/dev/mapper/_dev_mapper_System-IIT--Works on /home/avatar/Devel/IIT-Works type reiserfs (rw)
avatar@Nemesis ~ %     
Выглядит страшнюче, зато вроде чуть лучше стало. Да и дефрагментацию с удалением теперь только для /usr надо переводить периодически.       
                                                               

2.32177275461705% non contiguous files, 1.09595036068937 average fragments.

нормально? archlinux

> 2.32177275461705% non contiguous files, 1.09595036068937 average fragments.

> нормально?

Вполне, почему нет? :) 98% файлов ВООБЩЕ не фрагментированы.