Szerver gyorsaság javítás

Debian GNU/Linux

Szerver gyorsaság javítás

  • 846 megtekintés

( hawk | 2004. 05. 14., p – 08:24 )

A problémám a következő.

Van egy szerver, amit olykor teljesen lefog a SAMBA protokolon
történő másolás (25 gép telepítése). Ez a teljes hálózati sávszélességet
jelenti, ami jelenleg 100MBit/sec.
Valamikor a közeljővőben átállunk 2*100MBit/sec-re vagy
1GBit/secre de már most látszik, hogy a gép (1,6 P4) nem bírja
el a dolgot, ugyanis teljesen megfogja ez az adatforglom a gépet.

Elvileg a merevlemezek simán viszik a 30Mbyte/sec
adatforgalmat, amiből linux alatt max 20-25 Mbyte/sec-et ki is
tudtam préselni. Viszont ebben az esetben a gép processzorának
terheltsége 100%.

Meg lehet valahogy oldani a, hogy ne foga le ennyire a gépet
a merevlemezművelet??
Illetve lehet valahogy állítani a samba szerver futási prioritásán?
Vagy esetleg van valami jó javaslatotok a további gyirsaság érdekében.

-----------------------------------------------------------------------------------
A gép 1.6 p4 CPU, 512 Mbyte RAM, 2*120Gbyte Seagate HDD,
a nagyban leterhelt egy szoftveres RAID 1 be kötött 20Gbytos partíció.

hdparm mindkét hddre beállítva.
-d1 -c1 -m16 -X69 paraméterrel

( hawk | 2004. 05. 17., h – 11:31 )

[quote:454965624a="_Joel"]
Az adott peldaban a szoftver raid 1 pl kifejezetten hasznal az I/O teljesitmenynek, hogyha round-robin tud olvasni rola az operacios rendszer.

Vannak vmstat, sar mereseid a rendszerrol, hogy lasd hogy pontosan milyen teljesitmenycsokkenest okoz a terheltseg, es az pontosan hol keletkezik (elkezd swap-pelni a sok samba processztol, tele van az IO queue keresekkel, nincs idle cpu time - ebben az esetben a system es a user space terheltsegmegosztasa is erdekes, hogy tudd, hogy a samba vagy pedig a kerneldriver okozza a cpu terhelest, stb)?

Ahogy en neztem foleg a CPU IDLE time hianya okozza
a problemat. Most azon gondolkozok, hogy esetleg a samba
keresek prioritasat lejebb veszem mint asz SSH meg az egyebb fontos
cuccok prioritasa. Talan az segit valahogy rajta.

Swappelni meg szinte egyaltalan nem swappel szerintem.
Ezt mar a sajat laptopomnal is eszrevettem, hogy a swappot
szinte egyaltalan nem hasznalja.

( Jedite | 2004. 05. 17., h – 11:57 )

[quote:51882fbbb1="hawk"]
Swappelni meg szinte egyaltalan nem swappel szerintem.
Ezt mar a sajat laptopomnal is eszrevettem, hogy a swappot
szinte egyaltalan nem hasznalja.

Nagy memóriánál, nincs is nagyon szükség a swap-re. Nekem otthon a 320 Sd-RAM-nál rá se bagózik a Swap partícióra. Szerintem ez teljesen természetes.
Annak régen volt nagy szüksége, mikor még a 16 és 32 Mega volt a menő.

( mukk | 2004. 05. 14., p – 09:33 )

Ha jól tudom scsi nem eszik processzort.

Én SCSI sw raiddel nem birtam kihajtani PIII 800-as procit samban keresztül 100 -as hálón....

( anr | 2004. 05. 14., p – 09:47 )

[quote:331a9b0df0="hawk"]
Meg lehet valahogy oldani a, hogy ne foga le ennyire a gépet
a merevlemezművelet??
Illetve lehet valahogy állítani a samba szerver futási prioritásán?
Vagy esetleg van valami jó javaslatotok a további gyirsaság érdekében.

-----------------------------------------------------------------------------------
A gép 1.6 p4 CPU, 512 Mbyte RAM, 2*120Gbyte Seagate HDD,
a nagyban leterhelt egy szoftveres RAID 1 be kötött 20Gbytos partíció.

hdparm mindkét hddre beállítva.
-d1 -c1 -m16 -X69 paraméterrel

Bar nem irtad a disztriber, de tippelnem, hogy binaris terjesztes. Ekkor a P4-re optimalizalt ujraforditott samba is segit a dolgon.
A samba buffer mereteit is erdemes felemelni. Az hogy meddig azt teszteld ki konkretan a te problemadra.
Trivialitas, de switch-elt halo kell, a hub szar.
Ha emelsz a gep memoriajan, hogy tobbet tudjon cache-elni az szinten rengeteget segithet. A memoria olcso, emeld fel nyugodtan 2-4 GB-ra

( Névtelen (nem ellenőrzött) | 2004. 05. 14., p – 09:56 )

[quote:d1093968cc="anr"][quote:d1093968cc="hawk"]
Meg lehet valahogy oldani a, hogy ne foga le ennyire a gépet
a merevlemezművelet??
Illetve lehet valahogy állítani a samba szerver futási prioritásán?
Vagy esetleg van valami jó javaslatotok a további gyirsaság érdekében.

-----------------------------------------------------------------------------------
A gép 1.6 p4 CPU, 512 Mbyte RAM, 2*120Gbyte Seagate HDD,
a nagyban leterhelt egy szoftveres RAID 1 be kötött 20Gbytos partíció.

hdparm mindkét hddre beállítva.
-d1 -c1 -m16 -X69 paraméterrel

Bar nem irtad a disztriber, de tippelnem, hogy binaris terjesztes. Ekkor a P4-re optimalizalt ujraforditott samba is segit a dolgon.
A samba buffer mereteit is erdemes felemelni. Az hogy meddig azt teszteld ki konkretan a te problemadra.
Trivialitas, de switch-elt halo kell, a hub *****.
Ha emelsz a gep memoriajan, hogy tobbet tudjon cache-elni az szinten rengeteget segithet. A memoria olcso, emeld fel nyugodtan 2-4 GB-ra

Hát a 2-4G az nem megoldhato
a switchelt háló az meg alap, CISCO the best
cachelest meg meglassuk

( antiemes | 2004. 05. 17., h – 13:35 )

Hi!

Szerintem a hdparm-nak nem artana egy -u1 parameter sem. Ha minden igaz, ez arra valo, hogy amig az IDE buszt valami foglalja, akkor mas IO muvelet is folyhat. Vagy legalabbis valami ilyesmi.

By(t)e
TBS::Antiemes

( ToNyo | 2004. 05. 14., p – 10:22 )

<flame> Nem kivanok flamet inditani, csak a tapasztalatok miatt jegyzem meg, de nekem adott vason mindig tobbet birt a freebsd, meg olyankor is megbizhatoan mukodott amikor linuxal megaldva a gep kevesnek bizonyult. Merhetoen nagyobb forgalmat volt kepes produkalni, illetve tobb processt birt egy pl htttpdbol v ftpd childbol. Azthiszem ugyan ez volt a regi ftp.fsn.hu-val is amikor atallt freebsdre.
</flame>

Egyebkent sokat segithet a halozati puffer meretenek novelese komolyabb terhelesnel erre szukseg van.

( mocsi | 2004. 05. 14., p – 11:56 )

Az IDE egy nagyon jo dolog desktop-ra, olcso es gyors tud lenni de csak akkor ha egy task hasznalja, ha mar tobben akkor irtora nehezen tud vele megbirkozni. Ilyenkor csak a SCSI rendszer johet szoba.

( Névtelen (nem ellenőrzött) | 2004. 05. 14., p – 13:29 )

[quote:30db5a84c8="anr"][quote:30db5a84c8="hawk"]
Meg lehet valahogy oldani a, hogy ne foga le ennyire a gépet
a merevlemezművelet??
Illetve lehet valahogy állítani a samba szerver futási prioritásán?
Vagy esetleg van valami jó javaslatotok a további gyirsaság érdekében.

-----------------------------------------------------------------------------------
A gép 1.6 p4 CPU, 512 Mbyte RAM, 2*120Gbyte Seagate HDD,
a nagyban leterhelt egy szoftveres RAID 1 be kötött 20Gbytos partíció.

hdparm mindkét hddre beállítva.
-d1 -c1 -m16 -X69 paraméterrel

Bar nem irtad a disztriber, de tippelnem, hogy binaris terjesztes. Ekkor a P4-re optimalizalt ujraforditott samba is segit a dolgon.
A samba buffer mereteit is erdemes felemelni. Az hogy meddig azt teszteld ki konkretan a te problemadra.
Trivialitas, de switch-elt halo kell, a hub *****.
Ha emelsz a gep memoriajan, hogy tobbet tudjon cache-elni az szinten rengeteget segithet. A memoria olcso, emeld fel nyugodtan 2-4 GB-ra

Mármost nemazért, de a memóriák drágulnak.

( _Joel | 2004. 05. 14., p – 14:23 )

En egy regi okolszabalyt ismerek: minden Megabit halozati forgalomra szamoljunk masfel Megaherz processzorteljesitmenyt. Ez foleg a TCP/IP es az alkalmazasszintu protokoll overhead-jebol adodik (nemhiaba nem ad ugyanakkor teljesitmenyt a SCSI over IP mint az FCAL).

Amire neked igazabol szukseged van, az a Quality of Service beallitasa az egyes szolgaltatasokra. Linux-on ilyet nem csinaltam, de x86-os Solaris 9-nek gyarilag mindenfele hack-eles nelkul nehany konfiguracios parameterrel be lehet ezt allitani (bovebben: docs.sun.com, search: network QoS).

( _Joel | 2004. 05. 14., p – 14:36 )

[quote:5ab0c19c55="mocsi"]Az IDE egy nagyon jo dolog desktop-ra, olcso es gyors tud lenni de csak akkor ha egy task hasznalja, ha mar tobben akkor irtora nehezen tud vele megbirkozni. Ilyenkor csak a SCSI rendszer johet szoba.

Szerintem kevered a dolgokat. Az IDE es SCSI kozotti fo kulonbseg az volt, hog IDE eseten ha egy buszt tobb eszkoz hasznal, akkor keres-valasz teljes idotartamara lefoglalja az egyik a buszt - akkoris, ha tobb millisec-et kell varni amig a drive felolvassa a kert blokkokat. SCSI-nal maskent mukodik az arbitracio, a busz "inteligensebb".

Manapsag - foleg szerverekben - azonban minden IDE diszkhez kulon busz tartozik (vagyis csak egy master device log a buszon) - ilyen problemak nem lepnek fel.

Az adott peldaban a szoftver raid 1 pl kifejezetten hasznal az I/O teljesitmenynek, hogyha round-robin tud olvasni rola az operacios rendszer.

Vannak vmstat, sar mereseid a rendszerrol, hogy lasd hogy pontosan milyen teljesitmenycsokkenest okoz a terheltseg, es az pontosan hol keletkezik (elkezd swap-pelni a sok samba processztol, tele van az IO queue keresekkel, nincs idle cpu time - ebben az esetben a system es a user space terheltsegmegosztasa is erdekes, hogy tudd, hogy a samba vagy pedig a kerneldriver okozza a cpu terhelest, stb)?

( mocsi | 2004. 05. 14., p – 14:58 )

Konkretan a TQC nem eppen az IDE erossege, erre gondoltam. Semmi optimalizacio a fejmozgatasanal, semmi tervezes stb.stb. IDE eseteben mindez tisztan az OS->CPU dolga.

Amit irsz az teljesen igaz, de itt magarol a vezerlo egysegrol van szo.