[ risk @ 20.07.2006. 06:28 ] @
| do skora sam imao 32-bitni athlon na kome se vrteo gentoo i kad sam upgrade-ovao masinu na 64-bitni dual core intel, resio sam da odradim gentoo ispocetka, medjutim imam problem koji mi se cini da ranije nisam imao.
imam na masini 1gb rama i nemam swap. medjutim sad kad se popuni ram sistem krene da koci najstrasnije, zamisli windows u najgorim danima. ni strelica od misa ne ide glatko, treba mu po 30 sec da odgovori na tastaturu, uzas.
kad mu dam jedno 2gb swap-a da bi mogao da prodje emerge onda je sve ok, napuni se ram krene swap da se puni i to je uredu.
kad mu dam 100MB swap opet popuni swap i opet krene da koci.
da li je to normalno da se tako ubije ko siroce ili to ima veze sa tim sto ima 2 cpu-a, ili se to moze nadoknaditi nekim kernel tuning-om ?
kako se vama ponasa u takvim uslovima jel moze neko da napravi mali experiment i da proba?
ah da, kad se ram ponovo oslobodi sve je ok. |
[ warhead @ 20.07.2006. 13:47 ] @
Prvi put cujem, a da instaliras ponovo cijelu distru 64-bitnu?
[ Comrade @ 20.07.2006. 15:06 ] @
BTW formula kao sto sigurno znas glasi:
swap = 2 * ram
Zasto se ne bi pridrzavao ovog pravila?
Citat:
kad mu dam jedno 2gb swap-a da bi mogao da prodje emerge onda je sve ok, napuni se ram krene swap da se puni i to je uredu.
Ti zapravo nemas problem.
P.S. Emerge je izgleda uzasno pohlepan.
[ risk @ 21.07.2006. 11:52 ] @
pa da?
emerge eclipse-sdk je bio krivac.
mogu zamisliti kompajliranje open office-a ?
nije mi jasno zasto ne pukne jednostavno ta aplikacija koja ostane bez rama i sve ok, nego se ceo sistem zagusi i kswapd pocne da jede 100% na oba jezgra.
a za to swap = 2x ram, reci ti meni kako ja da znam koliko rama meni treba da mi ne bi trebao swap? to mi zvuci logicnije.
[ Marko_R @ 21.07.2006. 12:50 ] @
Meni to ne deluje kao normalno, i sam kažeš da na 32-bitnoj instalaciji nisi imao tih problema, a ni je takođe, sa 512MB ni jednom nisam primetio rad sa virtuelnom memorijom. A instalirao sam i eclipse. Imam 800MB swap, ali to nije bitno.
Kad malo bolje razmislim, to mora da je neki bag, jer taj eclipse se ni ne kompajlira, on treba samo da se raspakuje i to je to,
[ risk @ 24.07.2006. 15:52 ] @
Gentoo je u pitanju, 1024 rama. instaliran je svez. ukljucen je "High Memory" u kernel-u 2.6.17.
ranije sam otvorio kde/kopete/amarok/openoffice/firefox/azureus i desavalo mi se da mi za vreme kompajliranja zabodu programi koji ostanu bez rama ali nikad da sistem krene da se vuce, do neupotrebljivosti.
eclipse na gentoo-u za standardnu instalaciju koristi javac umotan u neki "ecj" koji se izvrsava u java virtuelnoj masini, treba mu dosta rama, ali kao sto rekoh, nije problem da mu odvojim privremeno za tu svrhu swap u fajlu. Problem je sto zakuca ceo sistem kad ostane bez memorije bez memorije ?
igracu se malo - probacu da izbacim iz kernel-a neke drajvere (intel HD audio) i probacu da napravim memory split 2g/2g umesto 1g/3g i da iskljucim high memory.
[ random @ 26.07.2006. 11:35 ] @
Citat:
risk: nije mi jasno zasto ne pukne jednostavno ta aplikacija koja ostane bez rama i sve ok, nego se ceo sistem zagusi i kswapd pocne da jede 100% na oba jezgra.
A šta se dešava sa buffer cache-om u tom trenutku? (sad nagađam, ali možda ga sistem kad ostane bez RAM-a za user procese agresivno prazni pa opet puni i tako dolazi do zagušenja?) I šta se dešava sa diskom?
Citat:
risk: a za to swap = 2x ram, reci ti meni kako ja da znam koliko rama meni treba da mi ne bi trebao swap? to mi zvuci logicnije.
Pa onoliko koliko ti pojede sistem u najzahtevnijem trenutku (taj emerge recimo) i još barem 15-20% pride. Moj prijateljski savet ti je da ipak staviš barem neki swap (1G recimo) i igraš se malo sa
/proc/sys/vm/swappiness vrednošću. Zašto je swap važan? Zato što korišćenjem swappinga povećavaš kapacitet bafer keša, a bolje keširanje blagorodno utiče na performanse celog sistema (kod Linuksa je ovo posebno izraženo).
[ ilaj @ 30.07.2006. 13:41 ] @
@random
Da li mozes da bacis neki link za tuning swappines-a?
[ random @ 30.07.2006. 17:25 ] @
[ ilaj @ 30.07.2006. 17:57 ] @
Hvala :)
Copyright (C) 2001-2025 by www.elitesecurity.org. All rights reserved.