Linux за българи: Форуми

Гледам,че няма такава тема,а ще е добре да си понастроим малко системите така,че да вървят по-бързо
Нека започнем с оптимизиране на хард диска.Чрез командата "hdparm" може да зададем няколко настройки на хард диска.Тази команда се използва само от root shell.При задаване на параметър  "hdparm -I" може да видите текущото състояние на хард диска ви.
Пример:

Примерен код

hdparm -I /dev/hda

Чрез параметъра "-A" може да включите или изключите read-lookahead .Препоръчително е "включено" за по-голяма производителност.Настройки "1" вкл. , "0" изклл.
Пример:

Примерен код

hdparm -A1 /dev/hda

Чрез периметъра "-c" може да включите/изключите 32-битова I/O поддръжка на хард диска.Настройки "1" 32-бит., "2" 16-bit, "3" 32-бит sync.
Пример:

Примерен код

hdparm -c3 /dev/hda

Чрез периметъра "-d" може да включите/изключите използването на DMA (Direct Memory Access).
Настройки "1" вкл. , "2" изкл.
Пример:

Примерен код

hdparm -d1 /dev/hda

Чрез периметъра "-M" може да включите/изключите опцията AAM (Automatic Acoustic Management)
Настройки от 0 до 254. При 128 главите на хард диска се движат най-тихо и съответно най-бавно.При 254 е най-шумно и съответно най-бързо.
Пример:

Примерен код

hdparm -M128 /dev/hda

Давайте още предложения как да оптимизираме системата си.

Няма такова нещо като hda в BSD (поне не и във FreeBSD)

Там няма и hdparm така че нищо не губиш а дето се вика където е hda, там е и ad... Ето и моята идея за оптимизация на системата ви. При възможност винаги ползвайте ядро оптимизирано за вашата процесорна архитектура - например i686. Ако вашата дистрибуция се предлага само с ядро за i386 силно ви съветвам да си го прекомпилирате, ако се захванете с това начинание добра идея ще е и да разкарате от ядрото всички ненужни Вам драйвери и възможности. В идеалния случай трябва всички пакети на системата ви да са компилирани с оптимизации специално за нея за да получите максимална производителност. Прегледайте и внимателно списъка с демоните които се стартират със системата ви и разкарайте всичко ненужно(при различните дистрибуции това е реализирано по различен начин затова няма да се спирам в детайли на процеса който е доста прост). Използването на модерна ФС като reiser4 също би повишило производителността на системата ви.

move

hdparm ми върши работа само за записвачката. SATA дисковете не можеш да ги настроиш по-добре от системата.

ReiserFS 4 може да е модерна, но това не прави изпитаните ext2 и ext3 по-слабо производителни. В единственото сравнение, което ми е попадало досега, се представят доста по-добре от нея.

За демоните съм съгласен, първото с което почвам, е да разкарам всички ненужни - повече свободна памет и по-малко на брой процеси.

Във fstab слагам опция noatime за всички дялове на диска. Това най-много ускорява търсенето.

Оптимизирането започва от BIOS-а. Като оставим настрана овърклокването на процесора и паметта, правя disable на всички неизползвани ресурси, като паралелни, серийни портове, IDE интерфейси, на които няма нищо закачено и пр. Постига се и по-бързо стартиране, понеже се спестяват проби на хардуера, освобождават се прекъсвания.

Не всички оптимизации са еднозначни, някои са въпрос на компромис, като напр. честотата на превключване на процесите, дали да има preempt на ядрото от потребителски процеси, кой алгоритъм на превключване да се избере. Аз съм на 1000 Хц с пълен preempt, понеже става въпрос за десктоп. Това реално намалява производителността, но усещането е за по-голяма производителност, понеже е намалено времето за реакция на системата.

Ядрото съм компилирал не само за процесора, но и с предаване аргументите на функциите през регистри, когато е възможно, -Os вместо -O2/3, понеже той включва повечето от оптимизациите за скорост, но прави кода доста по-малък, така че да излиза по-рядко от кеша. Много важно е да се компилира поддръжка на MTRR. И отново - съществено предимство на компилирането на собствено ядро е да отстраниш всичко ненужно, но това се постига с много четене, проби и грешки, затова компилирането на ядрото е последното нещо, към което човек трябва да прибягва, за да си ускори системата.

Здравейте. Ще Ви предложа няколко начина за увеличаване бързодействието на Вашата система(Fedora):

1. Много важна част в нашата цел да оптимизираме системата Fedora е да спретем services които се стартират при начално зареждане.

2. Имате възможност да намалите ползваемостта на Вашата памет, чрез намаляване броя на конзолите. Трябва да редактирате файл:  /etc/inittab и примерно да си оставите 2 конзоли. Всичко това в /etc/inittab ще изглежда по следния начин:
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
#3:2345:respawn:/sbin/mingetty tty3
#4:2345:respawn:/sbin/mingetty tty4
#5:2345:respawn:/sbin/mingetty tty5
#6:2345:respawn:/sbin/mingetty tty6

3. Намаляване тенденцията кернела да ползва swap файла. Зада извършите предното действие сложете "vm.swappiness=10" в /etc/sysctl.conf.

4. Ускоряване действията на OpenOffice може да извършите като въведете следните стойности в настройките на OpenOffice:
В меню Tools->Options->Memory:
Number of steps: 20
Use for OpenOffice.org: 128 MB
Memory per object: 20 MB
Remove for memory after: 00.10
Number of objects: 20

5. Имате възможност да увеличите продуктивността на Firefox като въведете "about:config" в address bar.Необходимо е да коригирате следните настройки:
network.http.max-connections                    128
network.http.max-connections-per-server            48
network.http.max-persistent-connections-per-proxy    24
network.http.max-persistent-connections-per-server    12

6. Ако сте на Gnome може да намалите натовареността на процесора с командата:
gconftool-2 --type string --set /apps/metacity/general/theme Atlanta

7 Отново за Gnome може да деактивирате Splash Screen с командата:
gconftool-2 --type bool --set /apps/gnome-session/options/show_splash_screen false

8.hdparm бе разгледан млако преди написването на тази статия и не виждам смисъл в повтаряне на информацията за него.

Всичко хубаво и похвално е, че сте си направили труда да прочетете и преведете, но написано така си е живо плагиатство. Моля уважете труда и на истинските автори на тези съвети:

http://ubuntuforums.org/showthread.php?t=24416
http://www.linuxjournal.com/article/8308
и т.н.

това не е плагиатство, а превод!

Статиите са добри, но не са споменали, че OpenOffice се ускорява най-много от изключване употребата на Java среда. Използваната памет също намалява драстично.

Не е разумно да се изключва Джавата защото аз лично ползвам азуреус денонощно, а той работи със джава

Такава тема бях зачеканал преди време... появата на тази показва, че е необходимо или да има такава тема "ОПТИМИЗАЦИЯ /ОПТИМИЗАЦИИ/" (която да НЕ се МАХА) или нещо систематизирано във Wikи-то /не знам обаче колко хора щъкат там/.
За да не бъде пълен offtopic това което пиша ето и моите (проверени от практиката) наблюдения за "ускоряване" на системата (искам да не се хващаме за думата "ускоряване"), за ООо няма да коментирам нищо, офиса си е тежък за зареждане по рождение.
1. Както бе написано повече RAM;
2. Прекомпилиране на кернела само с това, което е нужно (за устройствата твърдо вързани в кутията, направо в кернела - не модули) - въобще май е по добре модулите да паднат до възможния минимум (лични наблюдения, не искам да флеймим тука дали това е добре или не);
3. Пркомпилиране на софтуера (и графичната среда), които се ползват - който може да го прави, който не, се научава;
4. Ползване на готови пакети, сведен до минимум... т.е. нещо ако ти е необходимо, го компилирай (мазохистично;
5. Флагове за компилиране, съобразене с процесора (при мен Р4 - march=pentium4), компилирам с -march=pentium4 -O3, -fomit-frame-pointer -pipe -funroll-loops (не бих желал да спорим дали -Оs или -О2 е по-добре... всеки може да експериментира);
6. При компилиране на самото ядро аз лично добавям тези оптимизации в /usr/src/linux-2.*.*/Makefile;
7. Махат се всичи сервизи които не са необходими - беше споменато в предишен пост;
8. Ако наистина конзолите не Ви трябват - по-горе беше описано как става.
9. Файлова система... ползвам XFS, минах през ext2fs, 3, reiserfs и за мен като обикновен потребител XFS  ми допадна най-много /естествено това е личен избор и предпочитание/;
10. Тунинг на hd* - по горе бе описано как - аз ползвам - hdparm -u1 -d1 -c1 -a1024 /dev/h**
11. Ако случайно имате поблем с 80 жилен кабел и не ви разпознава АТА100-133, тогава може да опитате с append="idebus=66 ide0=ata66 ata1=**" (ако сте с Lilo, за Grub нямам идея това работи ли);
12. При компилирането на кернела ползвам "preemptive" и възможните оптимизации за моя процесор (това е малко повторение на т. 2)
13. Видео - драйвери за картата и възможни (позволени ускорения, които се предлагат от драйвера);

Толкоз се сещам сега...
Много бих искал да пишат хора, които имат практически опит при оптимизация... не е нужно да изпадаме в полемики с колеги чели man за нещо си или ревю-та и станали компетентни от това!!!
Дистрибуцията, която ползвам е Yoper 2.1, P4, 512ram, Sygate Baracuda 7200 (имам проблем с АТА-100 и го сетнах правилно по гореописания начин). Всичко което съм описал съм го проверил, недостатък е, че някои оптимизации могат да дадат различен резултат от резултата при мен, т.е. не бих казал, че всичко което съм написал ще има 100% "ускоряващ" ефект!
Поздрави
P.S. Като гледам какво съм писал за оптимизациите и компилиране на пакети, май ще трябва да караме на Gentoo;)

EDIT /31.01.2007/: След поредните експеримнти по отношение на флагове това дава доста по-добър резултат:
-Os -march=pentium4 -msse2 -fomit-frame-pointer -pipe
забележимо по-добър...

sky: http://kernelnewbies.org/faq/index.php3#compile

Оптимизиране на Lilo boot manager:
редактирайте с текстов редактор /etc/lilo.conf ,и добавете настройката "compact".Пример:

Примерен код

default="Linux" boot=/dev/hda map=/boot/map keytable=/boot/bg.klt menu-scheme=wb:bw:wb:bw compact prompt

След редактирането на lilo.conf трябва да стартирате lilo за да запише промените.
the_real_maniac и все пак стигна до извода,че няма такава тема,нали?

JRE наистина е една топ дупка. Толкова течове на памет има там че е направо чудничко. Ако можете да минете без Java приложения - по-добре за вас и системата ви...

/offtopic

Lord_Bad, не се ли изсили малко с това изказване за Java?

В световната мрежа наречена интернет има доста машини, които денонощно изпълняват услуги базирани на Java (JBoss, Tomcat, WebSphere, etc.). Нима твърдиш, че тези машини през определен период се рестартират с цел осводождаване на памет, заета от утечки?

За течове в JRE ли говорим или за приложения писани на Java? Понеже ако е второто, то няма нищо общо с това на какъв език е писано.

А може би става дума за това, че самата виртуална машина гълта много памет? Ако е така - това си е факт, но той няма нищо общо с течовете на памет.

edit: не се заяждам, просто бих искал да дадеш конкретен пример.

Аз не се занимавам с Java така че се извинявам ако кажа нещо погрешно предварително. Доколкото знам паметта на виртуалната машина се освобождава от тъй наречения garbage collector и негови несъвършенства
са причина за течовете на памет при продължителна употреба на на някое Java приложение. Разбира се тези недостатъци може да са скромни и главната вина да е в разработчиците на Java приложенията, но е факт че ако си държа Азуреус да работи на компа няколко дни нон-стоп потреблението му памет расте линейно докато не ме принуди да направя killall java, която ми освобождава в този момент 500МБ RAM... Явно програмата заделя памет, която или тя или garbage collector-a не освобождават.... В старата работа един tomcat периодично си забиваше поради сходни проблеми и съпорта дебнеше денонощно кога ще си отиде... Хубаво - архитекрно независими програми, но на каква цена? Виртуалната машина също си е тежичка, но това е приемливо с оглед на това какво ти спестява.

Ами аз от своя страна не съм ползвал Azureus, така че не мога да се изкажа компетентно по въпроса, но все си мисля, че проблема е по-скоро в него.

В Tomcat също нищо чудно да е имало такива проблеми.

Мисълта ми беше друга - като се изкаже едно такова мнение и като е формулирано по такъв начин, хората, които не са наясно с материята, си правят извод на базата на това мнение, че Java принципно е (образно казано) "кофти" технология. По този начин се насажда неприязън у хората, която не е базирана на личен опит.

Аз докато не започнах да се занимавам с Java също дълго време имах мнение, че това е нечовешки тежка платформа и бягах надалеч. Истината е, че би следвало човек да си изгражда мнение за каквото и да било на базата на опит (когато това е възможно разбира се).

Това е от мен.

Поздрави.

И аз съм останал с такива впечатления за Азуреус. Не знам за Джава като цяло, ама едновременно толкова многофункционална и толкова тромава програма като азуреус още не съм виждал

Не знам, аз си мисля че въпреки скромния ми опит в областта мнението ми не е лишено от добри доводи, а и с друго Java технологии съм имал подобни проблеми. Честно казано надявам се в моно нещата да са на по-добро ниво. Според мен поне всичко, което натоварва системата сериозно трябва да е писано за конкретната платформа на език тип с/с++. Това разбира се си е лично мое мнение, което може и да променя някой ден.

Намаляване времето за стартиране.
По принцип всички демони,които стартират се изчакват един-друг.Със следващата команда може да накарате да се зареждат възможно най-бързо без да се изчакват,което драматично намалява времето за стартиране на машината ви,НО ИМА РИСК НЯКОИ ДЕМОНИ ДА НЕ СЕ СТАРТИРАТ! За целта трябва да редактирате  "/etc/rc" с текстов редактор и да добавите & след $i start

Примерен код

if egrep -q "(daemon |action |success |failure )" $i 2>/dev/null \          || [ "$subsys" = "single" -o "$subsys" = "local" ]; then       $i start &    else

Изпробвайте го и ако всичко си стартира нормално може да го оставите.А ако нещо отказва да стартира просто трябва да махнете това & след $i start

Честно казано доста се чудя на хора, които мерят времето за стартиране.
Вие толкова често ли си стартирате/рестартирате машините, че това е от някакво значение за вас?
При мен рестарт се прави средно веднъж на седмица, най-често за да експериментирам с някое новооткрито дистро.

loxs темата не е деградиране на системата!!! Като искаш направи си я да я чакаш 1 час.
И стига сте писали глупости тука! Много ясно и четливо съм написал,че има риск като се прави това!И всеки трябва да си знае,че когато нещо се ускорява има риск или поне в повечето случай.
Бързо-нестабилно<->Бавно-стабилно

Първо може би е важно да спомена, че съм Java програмист. Личното ми мнение е че работата с паметта в Java е доста сложна процедура с оглед на това, че трябва да следиш всичко което си инициализирал да не се преинициализира по няколко пъти. За тези които не разбират мога и един елементарен пример да дам:

Примерен код

StringTokenizer strTk = null; int i = 0; for(int i = 0; i < 100; i++) { strTk = new StringTokenizer(...); ... }

За тези които разбират - сами разбирате, че в края на изпълнение на този код ще имате 99 практически неизползваеми StringTokenizer-а (които заемат памет). За тези които не разбират - цикъл който постоянно генерира нови елементи, но не премахва старите и те остават в паметта. Ето поради такива причини Azureus и други подобни Java приложения започват да заемат огромно количество памет след около ден-два. Това трябва да бъде стриктно следено от програмиста. Доста код съм написал и доста често ми се е случвала подобна ситуация, последното ми приложение обаче (един листънър) специално един ден си играх за да премахна такива грешки и вече 3 седмици работи без да е създало проблем.

Значи това е така и не е така. Ще се алокират нови обекти ако има свободен heap за да не се забавя машината с garbage collector-a. Обаче ако heap-a е изчерпан ще се пусне метлата и ще изчисти неизползваните обекти. Това ще доведе до забавяне но и до по-малко заета памет от виртуалната машина. Не говорим за случаите когато има memory leaks. Което си е доста гадно за проследяване особено без нещо като JProbe.

Малко да посъбудя тая тема...

Цитат (PAIN1 До колко е безопасна тази манипулация с оборотите на главата ?И в какви граници е безопасно ? Това не са оборотите @ само скоростта на местене на галвите (те само се местят наляво-надясно, не се въртят). Както казаха по-горе при по-голямо число (скорост) има по-рязко спиране и връщане в обратна посока което създава повече тракащ шум... При по-малко число се местят по-бавно (и по-плавно), при някои харддискове за да изчезне шумът трябва да се намали с около 5% максималното число, при други с над 50%.... [QUOTE=amri)

5. Имате възможност да увеличите продуктивността на Firefox като въведете "about:config" в address bar.Необходимо е да коригирате следните настройки: network.http.max-connections                    128 network.http.max-connections-per-server            48 network.http.max-persistent-connections-per-proxy    24 network.http.max-persistent-connections-per-server    12

Освен това трябва да е включен и pipelining-a....

Какво да правим с модулите на ядрото, които се зареждат по няколко пъти?

Докато стартирам системата си винаги се опитва да зарежда някои модули, след като са били вече заредени. Това сигурно води до някакво забавяне.

Системата е Дебиан Тестинг.

Не мисля. И без това няма начин да се заредят повече от един път. И надали толкова често се опитват да се заредят. Пък и зареждането от диска или pagecache-a на няколко десетки килобайти е доста бърз процес. Проверката има ли зареден такъв модул пък е много по-бърза и от него. Покрай което някой друг context switch в повече, който надали би могъл да усетиш по някакъв начин. Все пак не се случва няколкостотин пъти в секунда

Пичове, май аз не съм нещо в ред, ама Kubuntu-то ми 6.10 май няма /etc/inittab. Как да си спра виртуалните конзоли тогава?