Comments 135
Какой конфигурации комп?
А правда, что от всего, кроме upstart, результат зависит слабо?
От ext4 ещё хороший прирост, с аптбуйлда правда не большой(
Практически да
Компиляция с оптимизацией под конкретный процессор может дать ощутимый прирост производительности только на специфических задачах.
В «домашних» условиях этот прирост не превышает 5% (проверено на себе).
Поэтому, по моему мнению, надо оптимизировать загрузочные скрипты (поставить upstart как вариант), использовать файловые системы, соответствующие решаемым задачам, ну и конечно не на последнем месте качество используемого софта.
Компиляция с оптимизацией под конкретный процессор может дать ощутимый прирост производительности только на специфических задачах.
В «домашних» условиях этот прирост не превышает 5% (проверено на себе).
Поэтому, по моему мнению, надо оптимизировать загрузочные скрипты (поставить upstart как вариант), использовать файловые системы, соответствующие решаемым задачам, ну и конечно не на последнем месте качество используемого софта.
Какой результат получился с кде4?
с оптимизациями ядра acer aspire one под debian lanny @2.6.28.2 грузится за ~30с с XFCE
в ходе оптимизации выходит клакварь уже )
можно сделать быстрее. а может и не получиться. всё зависит от того, что у вас за процессор и насколько вы владеете ключами в emerge.
для атлона ХР — наборы инструкций апт билда на глаз шустрее чем эмерджа. Но ключами я не пользовался ни там, ни там.
Для атомов — апт билд почти бесполезен.
Ну и в таком духе… в общем технология очень и очень интересная, но не востребованная и посему мало улучшаемая.
для атлона ХР — наборы инструкций апт билда на глаз шустрее чем эмерджа. Но ключами я не пользовался ни там, ни там.
Для атомов — апт билд почти бесполезен.
Ну и в таком духе… в общем технология очень и очень интересная, но не востребованная и посему мало улучшаемая.
1. Извините, но без тестов на скорость «до» и «после» ваши советы мало что стоят.
2. Коренными бывают зубы, а раздел — корневым.
2. Коренными бывают зубы, а раздел — корневым.
У меня на ~8-10 секунд ускорило добавление в /boot/grub/menu.lst в параметр к ядру concurrency=startpar, т.е. в результате строка должна выглядеть примерно так:
/boot/vmlinuz-2.6.27-custom root=/dev/sda2 ro quiet concurrency=startpar
это без upstart.
Ещё с некоторыми мелкими оптимизациями, отключением ненужных процессов через утилу rcconf, система на c2d e8400 грузится 18 секунд, замерялось через bootchart, кстати замечательная программка.
/boot/vmlinuz-2.6.27-custom root=/dev/sda2 ro quiet concurrency=startpar
это без upstart.
Ещё с некоторыми мелкими оптимизациями, отключением ненужных процессов через утилу rcconf, система на c2d e8400 грузится 18 секунд, замерялось через bootchart, кстати замечательная программка.
стартовые скрипты с одинаковым уровнем выполнения будут загружаются параллельно
а где вы видели стартовые скрипты с одинаковым уровнем выполнения?..
упс. извиняюсь. не о том подумал
Вы имели ввиду runlevel? но там есть опасность не корректного запуска зависимых скриптов. -тотже банальный LAMP не очень корректно запускать не по порядку
Вы имели ввиду runlevel? но там есть опасность не корректного запуска зависимых скриптов. -тотже банальный LAMP не очень корректно запускать не по порядку
А можно поинтересоваться — какая разница апачу, будет ли запущен мускуль до него, после или одновременно?
Ему разницы нет — но на боевом сервере например запуск апача до старта мускуля иногда приводит к сильному проседанию первого из за потока запросов от клиентов на которым он (точнее не он естественно а скрипты сайта) выдает ошибки соединения с БД — но пред эти мужительно пытаясь достучаться до мускуля. — Количество апачей может подскочить до максимального за буквально 1 секунду. И на разгребание запросов при большой нагрузке может уйти до 15-30 минут.
В общем ИМХО не корректно не по порядку запускать зависящие друг от друга вещи.
В общем ИМХО не корректно не по порядку запускать зависящие друг от друга вещи.
Имелось ввиду число после «S» в папках вида /etc/rc2.d. Например, у меня есть такие:
S20postgres
S20nginx
S25pulseaudio
Это значит, что 20-е будут загружаться одновременно, а 25-ый после них
S20postgres
S20nginx
S25pulseaudio
Это значит, что 20-е будут загружаться одновременно, а 25-ый после них
Такое чувство что вы занимаетесь только тем что перезагружаете систему. )
P.S. Ubuntu 8.04 из Hibernate на моем ноутбуке поднимается меньше чем за 10 секунд.
P.S. Ubuntu 8.04 из Hibernate на моем ноутбуке поднимается меньше чем за 10 секунд.
А можно узнать вашу комплектацию, у вас двухядерник? сколько памяти?
У меня ACER 5315, Сел. 1,7 Ггц 533 шина, 1 Гб ОЗУ, 80ка винт — на диске 2 раздела: корневой и подкачка — 8.10 выходит из Hibernate столько же времени, сколько бы ушло на загрузку, единственное преимущество — сохранение рабочего окружения. Засыпает также долго как и выключатеся.
Win не ставил, но думаю она просыпалась бы раза в 2 быстрее.
Но доволен и этим, так как еще пару лет назад Hibernate запускался только после бубна.
У меня ACER 5315, Сел. 1,7 Ггц 533 шина, 1 Гб ОЗУ, 80ка винт — на диске 2 раздела: корневой и подкачка — 8.10 выходит из Hibernate столько же времени, сколько бы ушло на загрузку, единственное преимущество — сохранение рабочего окружения. Засыпает также долго как и выключатеся.
Win не ставил, но думаю она просыпалась бы раза в 2 быстрее.
Но доволен и этим, так как еще пару лет назад Hibernate запускался только после бубна.
как слегка усталый гентушник спрошу — вы стали счастливее?
apt-build не нужен.
Хотите из сорцов? Ставьте Gentoo :) Там есть куда более мощные, логичные и простые инструменты оптимизации под железо, ака use-флаги, гибкое указание CFLAGS и т.д.
*Гентушник*
Хотите из сорцов? Ставьте Gentoo :) Там есть куда более мощные, логичные и простые инструменты оптимизации под железо, ака use-флаги, гибкое указание CFLAGS и т.д.
*Гентушник*
Еще стоит отметить, что upstart в Debian до сих пор есть только в experimental репозитории, а использование apt-build даёт практически нулевой прирост производительности, в силу того, что процесс сборки абсолютно идентичен сборке пакета на билд-серверах дебиана под соответствующую архитектуру. При этом вы: тратите кучу времени на сборку каждого пакета, захламляете свою систему абсолютно ненужными вам -dev-пакетами и пакетами исходников устанавливаемых программ.
Вот и получается, что смысл в руководстве имеют два пункта:
— обновление ядра для перехода на ext4 — что с точки зрения Debian неверно в силу возможной нестабильности;
— установка пакета upstart из experimental — что неверно в силу тех же причин.
Как уже верно сказали, для экспериментов с самым новым софтом есть gentoo и иже с ним. Или ставьте Ubuntu, там upstart уже установлен по умолчанию.
Вот и получается, что смысл в руководстве имеют два пункта:
— обновление ядра для перехода на ext4 — что с точки зрения Debian неверно в силу возможной нестабильности;
— установка пакета upstart из experimental — что неверно в силу тех же причин.
Как уже верно сказали, для экспериментов с самым новым софтом есть gentoo и иже с ним. Или ставьте Ubuntu, там upstart уже установлен по умолчанию.
>что с точки зрения Debian неверно в силу возможной нестабильности
Я пользуюсь sid, Для меня нестабильность не страшна =)
Я пользуюсь sid, Для меня нестабильность не страшна =)
Я тоже пользуюсь sid. sid — очень стабилен, в sid в Debian попадает то, что в других дистрибутивах считается stable. А вот в experimental попадает что попало. И обновляться до experimental крайне не рекомендуется вообще.
The— Справочник разработчика Debian.experimentaldistribution is a special distribution. It is not a full distribution in the same sense asstable,testingandunstableare. Instead, it is meant to be a temporary staging area for highly experimental software where there's a good chance that the software could break your system, or software that's just too unstable even for theunstabledistribution (but there is a reason to package it nevertheless). Users who download and install packages fromexperimentalare expected to have been duly warned. In short, all bets are off for theexperimentaldistribution.
Никто не требует dist-upgrade до experimental, просто его подключаешь и в /etc/apt/preferences:
И установленный из experimental пакеты будут обновлятся из него, адругие не будут.
Package: *
Pin: release a=experimental
Pin-Priority: 101
И установленный из experimental пакеты будут обновлятся из него, адругие не будут.
а как же КДЕ 4.2? :)
Кто-то говорит про стабильность КДЕ 4.2? В каком месте он стабилен, простите? То одно отвалится, то другое, то трей не реботает, то плазмоиды, то еще что.
где? все работает, как часы. трей работает, плазмоиды отвалились только те, что были ручной сборки. пару багов наблюдал с крэшем плазмы, но подобные падения и в 3.5.10 есть — а он в stable живет
Вот 3.5.10 у меня сколько лет стоял — падений не было. А с 4-ми кедами мне самому возиться уже совершенно не хочется. Зато сейчас ежедневно вижу толпу разработчиков, любителей кед, которые всё обсуждают, что в 4.2 отвалилось на этот раз, что они наконец исправили, и какие там тормоза и зверское падение FPS в зависимости от видеокарты.
Если всё правильно ставить, то всё работает, у меня собранный apt-build'ом с оптимизацией kde4.2 работает отлично =)
>В ходе оптимизации система будет переведена на ext4, будет новое ядро и пакеты будут
>собираться из исходных текстов, а так же init заменён на upstart
В ходе оптимизации мы из Debian Stable сделаем Debian Sid…
>собираться из исходных текстов, а так же init заменён на upstart
В ходе оптимизации мы из Debian Stable сделаем Debian Sid…
experimental, сидом там даже не пахнет :)
Из него только 3 пакета — habrahabr.ru/blogs/linux/52368/#comment_1390365
Мне больше хочется понять, зачем отдельный /boot на ext2 на десктопе? )
Чтобы grub смог запуститься и стартовать ядро. Модуля ext4 для него, я так понимаю, в стандартной поставке по крайней мере нету.
Чтобы как минимум ядро всегда имело возможность загрузиться, независимо от того, что вы сделаете с корнем. Поэтому /boot должен быть ext2 — т.к. это самая маленькая и простая ФС для такого раздела, и поэтому же он не должен монтироваться по умолчанию, либо должен монтироваться в RO.
Чтобы как минимум ядро всегда имело возможность загрузиться, независимо от того, что вы сделаете с корнем. Поэтому /boot должен быть ext2 — т.к. это самая маленькая и простая ФС для такого раздела, и поэтому же он не должен монтироваться по умолчанию, либо должен монтироваться в RO.
А что оптимизировали-то? Скорость загрузки операционки?
S3/S4 ваши друзья. А всякие оптимизации загрузочных скриптов идут лесом. Полученый за много лет экстракт истины ^_^
А вообще, время запуска операционки не сильно важно.
А вообще, время запуска операционки не сильно важно.
Напишите лучше кто-нибудь статью по тюнингу linux под высокие нагрузки и трафик при работе в качестве веб-сервера ;)
это как бе слишком абстрактно, да и в инете дофига всего по различным подсистемам
А по-моему это наоборот очень даже конкретно и предметно.
Хотелось бы увидеть аналог статьи Сысоева по оптимизации FreeBSD только для линуха ;)
Хотелось бы увидеть аналог статьи Сысоева по оптимизации FreeBSD только для линуха ;)
если вы про www.opennet.ru/base/net/tune_freebsd.txt.html то там только сетевая подсистема
У меня возникто два вопроса:
1. А что вы всё меряете, сколько времени проходит загрузка машины? Какая разница, подождёте ли Вы на 20 секунд дольше раз в день?
Я вот вообще свои машины не выключаю. Максимум — hibernate.
2. Вот разработчик пакетов компилит их сам за вас обычно. Правда пакеты федоры, например, скомпилены под i386, в то время, как у меня i686 (обещали к следующей версии перекомпилить их под i586). Но ведь у остальных с этим по лучше обстоит.
Так вот скажите, много ли прироста производительности даёт перекомпиляция исходников под конкретный процессор. А если это Celeron? А Code2Dou/Xeon?
Многие говорят, что сборка всего из исходников добавляет очень много геморроя. Так ли это? Верно ли это для src-пакетов?
Просто хочу для себя раз и на всегда определиться, использовать прекомпилированные пакеты или нет.
1. А что вы всё меряете, сколько времени проходит загрузка машины? Какая разница, подождёте ли Вы на 20 секунд дольше раз в день?
Я вот вообще свои машины не выключаю. Максимум — hibernate.
2. Вот разработчик пакетов компилит их сам за вас обычно. Правда пакеты федоры, например, скомпилены под i386, в то время, как у меня i686 (обещали к следующей версии перекомпилить их под i586). Но ведь у остальных с этим по лучше обстоит.
Так вот скажите, много ли прироста производительности даёт перекомпиляция исходников под конкретный процессор. А если это Celeron? А Code2Dou/Xeon?
Многие говорят, что сборка всего из исходников добавляет очень много геморроя. Так ли это? Верно ли это для src-пакетов?
Просто хочу для себя раз и на всегда определиться, использовать прекомпилированные пакеты или нет.
Я чуть выше обрисовал ситуацию по поводу геморроя — загромождение системы dev-пакетами, которые потребуются для сборки, а также куча времени, которое уйдёт на сборку всего на свете, особенно чего-нибудь тяжелого, типа QT, KDE, PHP, Apache…
Плюс к этому вы получаете: благодаря установке upstart вы обновляете свой дистрибутив со stable/testing/unstable до experimental. Автор статьи предлагает на этом месте зафиксировать все пакеты — то есть никакие обновления, в том числе и исправления багов накатываться не будут. Если пакеты не фиксировать — замечательно, при каждом обновлении вы начинаете заниматься сборкой всех обновляемых пакетов — ещё уйма времени.
Теперь по поводу производительности. В Debian нет такой архитектуры, как i486, i586 или i686. Соответственно, все программы собираются либо под базовую архитектуру i386, без учёта доступных расширений, либо под amd64/sparc/etc. Частично вы эту проблему решите при пересборке ядра — когда по совету автора выберете ваш тип процессора. Это добавит небольшую оптимизацию. Но вся хитрая фишка в том, что вся остальная-то система Debian нацелена именно на i386. И все собираемые пакеты будут собираться именно под i386. То есть — без какой-либо разницы с тем, что собирается на билд-машинах.
Плюс к этому вы получаете: благодаря установке upstart вы обновляете свой дистрибутив со stable/testing/unstable до experimental. Автор статьи предлагает на этом месте зафиксировать все пакеты — то есть никакие обновления, в том числе и исправления багов накатываться не будут. Если пакеты не фиксировать — замечательно, при каждом обновлении вы начинаете заниматься сборкой всех обновляемых пакетов — ещё уйма времени.
Теперь по поводу производительности. В Debian нет такой архитектуры, как i486, i586 или i686. Соответственно, все программы собираются либо под базовую архитектуру i386, без учёта доступных расширений, либо под amd64/sparc/etc. Частично вы эту проблему решите при пересборке ядра — когда по совету автора выберете ваш тип процессора. Это добавит небольшую оптимизацию. Но вся хитрая фишка в том, что вся остальная-то система Debian нацелена именно на i386. И все собираемые пакеты будут собираться именно под i386. То есть — без какой-либо разницы с тем, что собирается на билд-машинах.
Я спрашивал не в контексте конкретного дистрибутива, а вообще в контексте линукс.
И мой вопрос сводится к следующему: если вся система — и ядро и пакеты — скомпилирована с оптимизацией под конкретный процессор, сколько это даст прироста производительности?
И сколько добавит геморроя (не времени сборки, не загромождения пакетами, а именно ручной работы)?
И мой вопрос сводится к следующему: если вся система — и ядро и пакеты — скомпилирована с оптимизацией под конкретный процессор, сколько это даст прироста производительности?
И сколько добавит геморроя (не времени сборки, не загромождения пакетами, а именно ручной работы)?
даст. но не более 5%. тесты gento vs fedora/ubuntu легко гугляцо.
геморроя добавляют.
геморроя добавляют.
И нередко позволяют сэкономить пару-другую сотен МБ, избавившись от лишних зависимостей. А иногда и повысить производительность с помощью, например, USE="-dbus -hal".
время потраченное на сборку я считаю дороже пары сотен МБ.
Производительность? Господи, -dbus -hal — дадут сущие копейки.
Зато когда вы вставите флешку и начнете открывать консоль дабы набить mount…
У меня правда-правда хватает работы которую нужно сделать на этом компе. Я хочу ее сделать и пойти отдыхать. ИМХО охота заниматься сборкой и прочими «оптимизациями» только студентам-красноглазам.
Производительность? Господи, -dbus -hal — дадут сущие копейки.
Зато когда вы вставите флешку и начнете открывать консоль дабы набить mount…
У меня правда-правда хватает работы которую нужно сделать на этом компе. Я хочу ее сделать и пойти отдыхать. ИМХО охота заниматься сборкой и прочими «оптимизациями» только студентам-красноглазам.
а мне например не влом подождать на 10-20 секунд больше, тем более когда я прихожу домой, я нажимаю кнопочку на компе и иду переодеваться, а переодеваюсь я дольше чем 30 секунд, так что это комп меня еще ждет =)
Для оптимизации загрузки только upstart, остальное для увеличения скорости работы.
и сильно от пересобранного ядра у меня скорость работы FF вырастет?
Так рекомендуется же еще и весь софт apt-build'ом пересобрать :)
Если влом собирать, то можно поставить swiftfox. Скорость работы FF вырастет.
Извините, что не в тему, но не подскажете ли хороший современный дистрибутив Linux (для десктопа, не сервера) под старое железо, но с GUI? Celeron 2400, 256 RAM, интегрированное видео.
Или набор деталек, из которых можно такую ОС собрать, чтобы летала :)
Debian :)
Железо вполне работоспособное, только памяти маловато. Debian и ставим только то, что нужно.
Use ArchLinux, Luke
Всем спасибо, долго допиливать желания нет, поэтому остановлюсь на Debian :)
А я то надеялся…
eINIT быстрее. Правда пока его настроишь не один час уйдёт и окажется, что конфиги ещё не для всех служб написали. И вообще он в бете. :) Но он быстрее, чем upstart.
1. для быстрой загрузки кроме апстарта ничего не нужно вообще.
2. на самом деле на нужен даже апстарт, ибо проще всего класть в гибернацию/суспенд а не выключать.
3. Персборка ядра дающая мизерный прирост и кучу геморроя с обновлениями/модулями/etc — абсолютно непонятна.
2. на самом деле на нужен даже апстарт, ибо проще всего класть в гибернацию/суспенд а не выключать.
3. Персборка ядра дающая мизерный прирост и кучу геморроя с обновлениями/модулями/etc — абсолютно непонятна.
Пересборка ядра для ext4, что бы точно не было проблем с модулями нужно подключить репозиторий sidux'а, для этого в /etc/apt/sources.list:
deb debian.tu-bs.de/project/sidux/debian/ sid main contrib non-free fix.main fix.contrib fix.non-free
deb-src debian.tu-bs.de/project/sidux/debian/ sid main contrib non-free fix.main fix.contrib fix.non-free
Меня сейчас закидают мышками, но я выскажусь по этому поводу.
Раньше, когда у меня был Sony VAIO, стояла ОС Ubuntu, саспенд даже не пробовал делать, выключал полностью.
Когда пересел на MacBook — я просто закрываю крышку ноута и он засыпает, открываю крышку и за 2 сек получаю свою систему в том же виде, что до закрытия крышки. Выводы делайте сами.
Раньше, когда у меня был Sony VAIO, стояла ОС Ubuntu, саспенд даже не пробовал делать, выключал полностью.
Когда пересел на MacBook — я просто закрываю крышку ноута и он засыпает, открываю крышку и за 2 сек получаю свою систему в том же виде, что до закрытия крышки. Выводы делайте сами.
Пофик на батарейку. У меня не было такого бешеного отжирания питания, кстати.
Несколько месяцев с момента покупки нетбука сидел на хубунте, никаких проблем и тормозов не было (вернее были огромные тормоза при компиляции проектов по сравнению с нормальным десктопом, но это спасибо интел атому). Недавно, правда, вместо xfce стал развлекаться с e17 из svn, но это уже совсем другая история :)
Делаем — в убунте Вы не делали саспенд, а в макоси делаете. Вы научились делать саспенд. Вот, собственно, и все.
Сколько Вам потребуется времени на уход системы в саспенд и возврат из него при убунте?
Не имею представления, Убунтой не пользуюсь.
Я просто не совсем понял Ваш прошлый комментарий.
На уход в саспенд — закрытие крышки. На выход из него — секунды 4-5 + ввод пароля.
> я просто закрываю крышку ноута и он засыпает, открываю крышку и за 2 сек получаю свою систему в том же виде,
> что до закрытия крышки.
Вы описали типичный сценарий пользования ноутбука с Debian`ом.
> Выводы делайте сами.
Автор исходного поста не знает про STR?
> что до закрытия крышки.
Вы описали типичный сценарий пользования ноутбука с Debian`ом.
> Выводы делайте сами.
Автор исходного поста не знает про STR?
имхо, если уж и сидеть на всём тестовом, новом и быстром, при этом не заморачиваясь компиляцией, то лучший выбор на данный момент это 64-битная Fedora
Зачем пытаться оптимизировать процессор на десктопе, если слабое место — i/o с жесткого диска? )
Я сделал apt-get install upstart но похоже, что ничего в загрузке не изменилось. Надо ли его где-то еще конфигурировать?
З.Ы. Ubuntu
З.Ы. Ubuntu
> Позже пакеты устанавливать через apt-build install, обновлятся через apt-build upgrade, более подробная информация в man apt-build
А apt-get пользоваться можно будет? Или один раз воспользуешься, и привет всей системе?
А apt-get пользоваться можно будет? Или один раз воспользуешься, и привет всей системе?
Sign up to leave a comment.
Оптимизация Debian