При очень большой нагрузке на слабые процессоры появляется некоторая дерганность в поведении окон из-за нехватки вычислительной мощности. Вылечилось просто - повышением приоритета 2-х процессов X и kwin.
Повод с одной стороны шуточный, а с другой… В общем задумался над расстановкой некоторых приоритетов в системе. К изменению приоритетов меня подтолкнула простая ситуация, когда при серьезной загрузке процессора (средняя нагрузка составляла около 75%) у меня окно сначала перепрыгивало, а потом недопрыгивало при перетаскивании. Вот и решил, что лучше перетащить окно быстро и точно, чем долго мучить себя и машину, вытягивая из нее остатки сил) Вообще это кажется разумным - работа с графикой (раз уж пользуемся иксами) должна иметь более высокий приоритет, чтобы не вызывать дискомфорт при большой загрузке процессора. Если кто подскажет как назначать программам более высокий приоритет при старте системы - буду признателен. Заранее благодарен.
P.S.
Поставил у себя пока так (хотя можно и обычным повышением было обойтись):
X - FIFO67
kwin - FIFO61
Значения приблизительные - не слишком долго возился с подбором значений, но по моим субъективным ощущениям работа стала намного комфортнее. Надо будет проверить не прервется ли звук при приоритете FIFO, если да то ограничусь повышением обычного приоритета.
…
При одновременном открытии нескольких программ наблюдались зависания, сменил FIFO на менее жесткий планировщик Round Robin с теми же приоритетами.
Михаил, я знаю, что такое nice;) Однако помощью nice Вы не сможете переключить (или сможете?), например, на планировщик Round Robin - получится только выставить приоритет обычного планировщика. Но основной вопрос у меня состоит в том, что я не нашел, где именно находятся команды стартового запуска иксов и kwin в Calculate. Как вариант, можно ли переназначить их запуск с тем же nice через alias, чтобы при старте иксы и kwin запускались с нужным приоритетом? И где тогда прописывать такой alias - в bashrc? Вообще хотелось бы понять суть и сделать назначение приоритета в правильном месте. Пока еще не нашел решения самостоятельно - в процессе.
Прикрутил и попробовал еще в самом начале - эффект пока положительный. Если есть другие мнения разумеется выслушаю и приму к сведению. С повышенными приоритетами X и kwin у меня получилось нормально поработать, менюшки ожили, программы стали открываться-закрываться достаточно оперативно для загруженной системы. Собственно мне пришлось выкручиваться. При фоновой компиляции обновлений системы в определенный момент стало все в буквальном смысле ворочаться. Хотя свои параметры в make cчитаю нормальными (MAKEOPTS="-j3" EMERGE_DEFAULT_OPTS="-jobs=4"). Поэтому и пришла мысль повысить приоритет программ, отвечающих за отрисовку графики. Можно конечно и ручками подправлять приоритеты я в принципе сейчас так и делал при необходимости, но хотелось бы понять, где прописан старт этих 2-х программ, чтобы указать уже там повышение приоритета. Свой вопрос задавал в надежде, что возможно уже кто-то сталкивался с такой ситуацией. Специально для меня решений искать ни в коем случае не нужно! Как в поговорке - мы и сами немного с усами) Поищу спокойно - найду решение. Про помощников приношу извинения я нескладно написал - возможно сказывается некоторая усталость. В любом случае большое спасибо всем, кто пытается помочь. Что касается nice - я понимаю что это за команда, определенный багаж знаний и опыта есть, но он, к сожалению, еще пока недостаточен, чтобы удовлетворить все возникающие потребности в администрировании системы. По возникшему у меня вопросу все еще нахожусь в стадии поиска решения.
Согласен с Вами, только было бы куда уменьшить - ведь у компиляции и так самый низкий приоритет выставлен по умолчанию. Все потоки идут как раз с приоритетом 19 (использую eselect profile set 1). Возможно я чего-то недопонимаю конечно, но у меня при компиляции тяжелых пакетов (libreoffice, chromium и др.) при обновлении системы в этот раз было тяжко с отзывчивостью. Поэтому пришлось прибегнуть к увеличению приоритета графической системы. Возможно, в моем случае, виноват 2-х ядерный процессор atom n270. Слабоват он все же. С остальными подсистемами проблем не наблюдалось. Приложения после повышения приоритета X и kwin стали нормально открываться без тормозов. Я пока еще разбираюсь в ситуации, но вроде бы все остальное скомпилировано и подогнано более менее в приличных рамках. Ядро скомпилировано с параметрами для версии desktop: CONFIG_PREEMPT=y CONFIG_HZ_1000=y CONFIG_HZ=1000, планировщик тоже более менее приличный DEFAULT_CFQ=y по отзывчивости, ну и остальные опции выбраны только необходимые для asus n10j, т.е. в принципе тормозить ничего не должно…
На данный момент у меня уже хорошо выправленное ядро, запускаются только необходимые модули и сервисы. Система в принципе без сильной фоновой нагрузки летает в рабочем режиме. Конечно такой быстрой загрузки, как в случае с асусовским линуксом (это сильно урезанный по функциональности, подтормаживающий в работе линукс, с файловой системой монтированной только для чтения и прочими неудобствами как выяснилось, к сожалению) с его 5-ти секундным холодным стартом мне добиться не удалось, но некоторое ускорение загрузки реализовать получилось. Как обкатаю систему, соберусь с мыслями, возможно получится рассказать про настройку этого нетбука под дистрибутив Calculate, с Вашего одобрения конечно. В общем потихоньку обустраиваю систему, а отсюда и появляются вопросы, на которые я не всегда сразу отыскиваю хорошие решения.
Опять таки MAKEOPTS="-j1" высвободит второе ядро, что увеличит отзывчивость системы. По поводу скорости загрузки, не задумывались об SSD винте? Признаться для меня было большой неожиданностью, когда я решил засечь скорость загрузки своего ноутбука. 9 секунд до приглашения KDM мне кажется совсем неплохо. При этом почти половина времени ушла на нагрузку ядра с модулями. Обратите внимание на OCZ VTX3-25SAT3-120G. С таким малышкой ваш нетбук просто залетает
Признаюсь, что MAKEOPTS="-j1" просто боюсь ставить. Как вспомню, что этот двух ядерный atom n270 полностью компилирует кдешную систему за 4-ре дня, так мне не по себе становится)))) А что будет если у него половину мощности отобрать и попасть на серьезное обновление?)))) Я не могу понять одного, чем плохо повышение приоритета этих двух процессов? (субъективно я получил очень хорошую отзывчивость системы к своим действиям при нагрузке, в принципе могу протестировать работу системы для всех с и без, если подскажете чем и привести результаты тестов сюда, например)
Красавчик… не думал, что у современных SSD такие нешуточные(!) параметры быстродействия (первые SSD вроде были по 40-80 Мб в сек., но это ведь и жесткие диски могут при 7200 оборотах в мин…), и я читал, что у них есть серьезные ограничения на циклы перезаписи - по крайней мере у первых моделей, когда интересовался(. Видимо пора освежить информацию о SSD.
P.S.
По статье - как только буду уверен, что полностью удовлетворен работой настроенного нетбука, то в свободное времечко попробую законспектировать опыт и перенести его в раздел блогов.
По поводу “-j1” мне было интересно Ваше мнение. Что касается SSD, то не все на ноут поставят 7200, т.к. это подсаживает аккумулятор. По поводу циклов записи, обычно ноутбук устаревает или ломается раньше. Ну там кофе, край стола и т.д. SSD дает колоссальный выигрыш по производительности, причем без ущерба, а даже во благо времени работы аккумулятора. Ну и плюс тепловыделение меньше.
По MAKEOPTS="-j1" вопрос больше психологический возможно, к примеру в шустром 4-х ядерном я оставил бы ядрышко свободным не сильно раздумывая. А в моем же случае, предполагаю, это может обернуться приличным увеличением времени сборки обновленных пакетов. Для моего нетбука бинарные пакеты хороши для проверки функционала программ. Последующая же компиляция проверенных программ затем существенно увеличивает их производительность и комфортность работы с приложениями. Ради эксперимента, при случае, попробую замерить разницу во времени компиляции. Тут может сыграть эффект кеша ядра и свести к минимуму разрыв по времени компиляции, хотя не уверен, что это сильно поможет. Вероятнее будет увеличение времени компиляции примерно в 2 раза (на 2-х ядерном).
В общем именно поэтому я искал удобный source-base дистрибутив. Мне правда повезло больше, чем я рассчитывал на самом деле. В сумме я приобрел качественно(!) собранную ОС, очень добротную документацию на русском(!) языке (хотя английский технический у меня неплохой, но предпочитаю все же русский), хорошую техническую поддержку. Со своей стороны я пытаюсь привнести хоть небольшую пользу для развития весьма удачно (на мой взгляд) задуманной системы. Конечно польза от меня пока можно сказать никакая - осваиваюсь еще только. Финансово постараюсь поддерживать по мере своих возможностей. К сожалению, у меня сейчас не лучший период в этом отношении, но решу и этот вопрос.
У меня невольно все больше разгорается любопытство - еще ни разу не высказались за повышение приоритета X и kwin. Чем может обернуться повышение их приоритета для системы? Единственно, что я могу предположить сам, так это то, что процессы, например, звук могут прерываться при большой нагрузке, если не находятся в режиме РВ (реального времени). Или есть и другие нюансы?
У меня невольно все больше разгорается любопытство - еще ни разу не высказались за повышение приоритета X и kwin. Чем может обернуться повышение их приоритета для системы? Единственно, что я могу предположить сам, так это то, что процессы, например, звук могут прерываться при большой нагрузке, если не находятся в режиме РВ (реального времени). Или есть и другие нюансы?
а мне как раз выбор этих процессов не совсем понятен, разве что с точки зрения эксперимента и наглядности
верю, что окошки-меню и т. п. отрисовывается быстрее, но ведь работа (да и отдых) за компьютером не сводится же к просмотру графических эффектов
сидишь в интернете - значит надо повысить и приоритет браузера, фильм или музыка - приоритет плеера и звуковой системы, фото - приоритет просмотрщика или графического редактора
или при, например, открытии страницы в интернете нагрузка на X-ы больше чем на сам браузер?
Вы меня очень растрогали… Хотя может я сам заблуждаюсь??? Вы уверены, что знаете для чего нужен kwin? kwin - прежде всего нужен для прорисовки приложений, а не для эффектов. Был бы другой менеджер окон - повышать приоритет пришлось бы ему вместе с иксами.
Описание пакета - KDE window manager.
Для сведения: эффекты отключены, КДЕ пользуюсь из-за удобного комплекта программ, включение эффектов на данном нетбуке отнимает 10-12% производительности.
Выбор этих процессов обоснован тем, что именно они дали возможность отморозить замедленные действия, причем повышать приоритеты других программ мне не пришлось. Попробуйте нагрузить компьютер вычислениями с реально приличной нагрузкой (у меня средняя вычислительная нагрузка в тот момент находилась на отметке примерно 75%) и все встанет на свои места. Повышение приоритета конкретной программы не спасает - прорисовка окон будет работать с меньшим приоритетом и будет продолжать оставаться узким местом в системе. Думаю на иксы и менеджер окон больше действует пиковая кратковременная нагрузка и если они будут достаточно долго ожидать освобождения ресурсов Вы заметите как резко упадет производительность Ваших действий. Я не стараюсь тут никого убедить в том, что нужно повышать приоритет этих программ. Мне помогло.
Предполагаю, что при такой нагрузке - в любом варианте любого дистрибутива с 2-х ядерным процессором будет дискомфортно работать в любой графической оболочке с обычным приоритетом иксов и менеджера окон. Другое дело, что такая нагрузка обычно очень редко встречается в повседневной работе.
я знаю, что такое kwin и именно поэтому мне стало интересно, неуж-то прорисовка приложений и окон является наиболее ресурсоемким процессом на домашнем компьютере?
P.S. возможно это ещё зависит и от установленной видеокарты?
Не стоит переворачивать все с ног на голову;) Если вдумчиво все прочитать, то можно понять, что речь не идет о повышении приоритета ресурсоемких приложений, а об уменьшении времени отклика на действия пользователя при работе в иксах. И, на мой взгляд, ресурсоемкость здесь играет роль ограничения производительности процессора, а не видеокарты. Если не ошибаюсь в zen-kernel есть возможность запуска иксов с увеличенным приоритетом. Так что я не один сталкивался с такой ситуацией. Раз добавляют такие опции в ядро (пусть и неофициальное), значит в этом есть необходимость. Вы можете спросить КАК я определил, что эти 2 процесса влияют на время отклика на действия пользователя. Все предельно просто - в момент большой нагрузки открыл диспетчер процессов и посмотрел какие из процессов начинали пытаться потреблять ресурсы системы при запуске программ и работе с ними. Этими процессами оказались иксы и менеджер окон. Меня больше удивляет другое - почему процессы с низким приоритетом (к примеру компиляция, имеет приоритет всего 19) очень медленно возвращают управление системе. В случае быстрого возврата управления не было бы нужды повышать приоритет ни иксов ни менеджера окон. Еще один подводный камень - при большой нагрузке может не хватать ресурсов самому ядру для адекватного отклика системы.
В общем итоге уперлись в планировщик)))
На мой субъективный взгляд логичнее было бы определить вычислительную мощность системы и, исходя из требуемой величины отклика процессов (включая и ядро и все его подсистемы с учетом накладных расходов на управление) распределять ресурсы системы. Причем тут можно столкнуться и с тем, что время отклика процессам может меняться динамически в зависимости от потребностей (например, начала перемещаться мышь - уменьшили время отклика графической системе). В этом случае о ручном накручивании всяких найсов можно было бы вообще забыть.
