ubuntu server lefagy (talán megoldódik)

Linux-kezdő

Üdv!

Van egy ubuntu 10.04 64bit-es szerverem egy atom procis alaplapon (Gigabyte GA-510UD) 1 gb rammal.
Ezek mennek rajta:
-1 külön vinyó a linuxnak
-mdraid (raid5, 3db wd green 1tb vinyóval)
-rtorrent rtguival
-cups (amit még mindig nem tudtam beállítani)
-samba (azt hiszem, a 3-ast tettem fel)

Időnként lefagy a server, ssh-n nem érem le. Gondoltam, ha ráteszek egy monitort meg bill-t,
akkor konzolon még menni fog, de kiderült, hogy be sem kapcsolja a monitort, tehát kompletten lefagyott.
Ahogy észrevettem, akkor fordul elő, ha samba megosztás megy, de akkor sem mindig.
Az a baj, hogy ha hard-resetet csinálok, mert máshogy nem tudom újraindítani, mindig szétesik a raid-tömb,
amit utána újraépít, de ugye ez nem valami biztonságos.

Mi az ötletetek, milyen logot, vagy mit nézzek, hogy mi miatt fagyhat a szerver.
Esetleg mit ajánlotok, amivel megtalálom a hibát?

  • 3881 megtekintés

Szia!

Én is kipróbáltam az ubi előző verzióit, + a servert is, és gyakran fagyott ez is, az is, és ha valami nem megy akkor nem érdemes eröltetni, ezért tettem fel debiant cirka 2 éve megy gond nélkül. Pedig nagyon sokan dícsérték az ubit, de otthon is maradt a debian, azon a gépen sem akart túl jó lenni. Debian kicsit nehezebb első nekifutásra, de megéri utánnaolvasni dolgoknak.

( petyka2 | 2010. 09. 08., sze – 12:22 )

kaptam egy ilyen hibaüzenetet:
BUG: soft lockup - CPU#3 stuck for 61s [swapper:0]

ez mi lehet?

Vicces dolog, en is ezzel kuzdottem, bar en kvm-es virtualizalt geppel.. Egyelore ott tartok, hogy biosban kikapcsoltam a power managementet (vagy cpu throttling, vagy barmi egyeb, ami proci sebesseghez hozzanyulna). Logokat ha nezel, nincs benne idougras?
Esetleg tsc helyett masik clocksource, mondjuk bootmenube kernelopcio "clocksource=hpet".
Meg csak most tesztelem, h ezek segitettek-e, szoval messze nem biztos h barmi koze van a dologhoz..
Mindenesetre a soft lockup-rol eleg sok infot szerezhetsz google segitsegevel.

( balintdavid | 2010. 09. 08., sze – 12:52 )

Hard reset elég barbár megoldás, próbáld újraindítani magic sysrq-val.
(Amíg nem jössz rá hogy mi a ludas)
Meg nem oldja a hibát, de legalább nem esik szét a RAID.
-------------------------------------------
http://www.youtube.com/watch?v=Qw7LEIDFCX4

Jo, ez kicsit erzelmi alapu hozzaallasom a raid5-hoz, de a mac billel egyutt mar nem birtam megallni:-)

Szerintem nagyobbat lehet vele szivni, mint amennyit nyer vele az ember raid1 vagy raid 10-hez kepest, egy ilyen hard-reset-es kornyezetben ennek a valoszinusegi faktora pedig nagyobb, mint normal uzemnel.

De a sync-es resz volt az erdemibb a hozzaszolasban, ezt a reszt skip-pelheted.

Ne lovagoljunk mar legyszi a hulyesegeken, irtam olyat, hogy 3 diskbol csinaljon raid10-et?

En akkor is inkabb 2 diskbol csinaltam volna raid1-et, vagy 4 diskbol raid 10, mert 4 diskje van (bar gondolom az elso nem olyan, mint a tobbi, igy ez kiesik utolag mar), de irtam, hogy ez az egyeni szocproblemam, es nem ez a lenyeg a hozzaszolasomban.

Ez volt a lenyeg: sync-eljen es umountoljon is a poweroff elott sysrq-nel (is), mert kulonben gyorsabb, ha a kirantja a tapkabelt, a hatas meg ugyanaz.

( lucaluca | 2010. 09. 08., sze – 15:31 )

nem tudom segit-e valamit, de nekem is volt ilyen problemam, szinten raid (bar en ket vinyot raktam raid1-be) es szinten samba. minden hw teszt tokeletes eredmenyt adott. vegul megprobaltam visszaemlekezni hogy mikor kezdodott a jelenseg, es arra a kovetkeztetesre jutottam, hogy kb akkor, amikor bekapcsoltam a samban az extended logolast. ezt kikapcsoltam, es honapok ota nem vol fagyas.

tudom hogy vekony szalmaszal, de hatha tudsz kezdeni valamit az infoval.

( petyka2 | 2010. 09. 08., sze – 21:00 )

Új fejlemény, hogy amikor egy másik gépről megpróbálom elérni samba-n keresztül, akkor befagy.
Konzolon rögtön ez a hibaüzenet jön:
BUG: soft lockup - CPU#3 stuck for 61s [swapper:0]
Kernel bug lenne az atom procik esetén?

( petyka2 | 2010. 09. 08., sze – 21:41 )

lehet, hogy megtaláltam a megoldást.
egész egyszerűen kernel bugról van szó.
itt egy link, elég sok ember találkozott már vele:
https://bugs.launchpad.net/linux/+bug/585765?comments=all

itt azt írják, hogy ezeket kell beállítani a kernelnek:
- noacpi noapm
- nohz=off
- acpi_skip_timer_override

és ezeket hol állíthatom be?

( petyka2 | 2010. 09. 12., v – 19:00 )

kikapcsoltam a biosban a hpet-et, és beírtam a kernel opciókhoz, amit fentebb írtam.
azt hittem, hogy megoldottam a problémát, mert több, mint 1 napig nem fagyott, pedig de.
sajnos megint hard-reset kellett (a sysreq se segített), és azóta el sem indul a gép.
fsck után (az sda-ra clean, amin a linux van) utána udev hiba és azt írja, hogy a következő frissítésnél valamit fog csinálni.
(udevd(404) hiba, sysfs will be removed the next update vagy valami ilyesmi a hiba, hpmud.rules10-nél van a hiba)
na innen nem megy tovább.
valami ötlet?
vagy legalább milyen linux disztribúciós tegyek fel, mert ez használhatatlan, hogy mindig lefagy.
esetleg ubuntu 10.10 (tudom, hogy még 28 nap mire megjelenik, de hátha ennél a f*snál jobb)

A Lenny olyan, mint a Lucid Lynx, egy kiadás fantázianeve, jelenleg ez a stabil változat.
Infó: Debian kiadások

Általánosságban az ubuntuhoz készült leírásokat tudod használni Debianon (és viszont). A különbségekről nem szeretnék hosszú leírást írni, gazdagon van eltérés a kettő között.

A következőre úgy tekints, mint építő jellegű kritika:
Ha ilyen kérdésekkel nem vagy tisztában, kérlek ne vállald komolyabb kiszolgálók üzemeltetését.
Természetesen senki sem úgy születik, hogy tisztában van a Linuxok (és sokminden más) működésével, meg kell tanulni. Ez az oldal azért jött lére, hogy az ezen a területen dolgozók segítsék egymást, de elvárható az, hogy legyen önállósága az itt író embereknek. Tehát a google a barátod és ha nem árul el semmit, akkor kell ide fordulni.

( petyka2 | 2010. 09. 15., sze – 12:57 )

Sajnos a sok fagyás miatt, a raid-tömb behalt.
Feltettem a debian lenny-t.
Azonban amikor új raid tömböt akarok létrehozni, mindig azt írja ki,
hogy ext2fs filesystem van rajta.
A cat/proc/mdstat mindig recovery-t ír a készítés alatt, ami ugye az, hogy vissza próbálja állítani a régi tömböt, de én teljesen újat szeretnék létrehozni.
Igaz, hogy a recovery nem új tömböt csinál, hanem a régit próbálja visszaállítani?
És még egy érdekesség, hogy debian alatt kb. 20-30mb/s volt a recovery, míg ubuntu alatt 60-70mb/s.

Mért baj az, ha szerencsétlen próbálja összerakni a tömböt?

Ha nem kell a tömb, hanem mindenképpen újat akarsz csinálni, akkor vedd ki belőle a lemezeket és állítsd le (valahogy így):

debian:~# mdadm --manage /dev/md0 -f /dev/hdb1
mdadm: set /dev/hdb1 faulty in /dev/md0
debian:~# mdadm --manage /dev/md0 -r /dev/hdb1
mdadm: hot removed /dev/hdb1
debian:~# mdadm --manage /dev/md0 -f /dev/hda1
mdadm: set /dev/hda1 faulty in /dev/md0
debian:~# mdadm --manage /dev/md0 -r /dev/hda1
mdadm: hot removed /dev/hda1
debian:~# mdadm --stop /dev/md0

de az a furcsa, hogy ha törlöm a partíciót, attól még a uuid alapján asszem tudja, hogy raid tömb volt valamikor
és az alapján újrarakja.
már rátettem egy új ext3 filerendszert, de akkor is ezt írta ki.
hogy tudnám úgy törölni a vinyót, hogy teljesen újnak hasson, ne írogassa, hogy már van rajta valami?
és miért lehet az, hogy debian alatt ennyivel lassabb? igaz, ubuntu alatt a resync volt annyi, nem a recovery.

( petyka2 | 2010. 09. 16., cs – 22:26 )

Úgy néz ki, rájöttem mi lehet a bibi.
Debian Lenny-t tettem fel végül.
-samba
-apache
-rtorrent
-rutorrent
ezek vannak fent.

Friss indításnál még minden megy rendesen.
Egy idő után nagyon belassul.
Rájöttem, hogy a memory cache iszonyatosan megnő és lecsökken az üres memória. (szerintem az rtorrent miatt)
Rtorrent-nél találtam egy olyan opciót, hogy max_memory_usage, ezt beállítottam 748mb-ra, de így is elfogy a memória.

Hogy tudom úgy beállítani, hogy ne fogyassza el teljesen a memóriát, ne csináljon annyit cache-t, legalább 100mb maradjon üresen a memóriából?
ulimit -m -mel beállítottam a max memória méretet 748kb-ra, de nem sokat értem el vele, egy idő után mint ha be sem állítottam volna.
Vagy valami más ötlet?

Régebbi rtorrent verziókban volt egy pár brutális memory leak.

Rakj fel frissebbet lenny-backportsból. Én mondjuk SVN-ből forgattam a legfrissebb verziót, mert beletúrtam pár helyen libtorrentbe...
Olyan 50 Mb-ot eszik debian squeeze apachestul mindenestül.
-------------------------------------------
Suddenly the Dungeon collapses!! - You die...

libtorrent 0.12.6 és rtorrent 0.8.6 a legújabbak vannak fent, svn-ből forgattam.
azt értem, hogy kitölti a cache a memóriát, de ha pl. kicsit több torrentet indítok el,
akkor behal a gép, holott a htop-al max. 10%on van a prociterheltség.
hogy tudom megnézni, hogy hány nyitott fájl van? mert lehet állítani az rtorrentben, hogy mennyi legyen a max nyitott fileok száma. (most épp 128)

( petyka2 | 2010. 09. 19., v – 14:01 )

az rtorrent a ludas mindenért, pedig a legújabb van fent.
ki milyen torrent klienst használ helyette, ami tud webgui-t?
vagy esetleg valami ötlet, hogy mi baja lehet az rtorrentnek?

Nem tudom, én torrentflux-ról váltottam transmission-re.
FreeBSD 8.1.
A torrentflux evett 2GB RAM-ot (kb. 40-50 torrent volt mindig benne, seedelte őket éjjel-nappal), most a transmission meg valami 100 megát...
És a torrentflux csinált egymaga 5-ös load-ot, a transmission alig mérhető, 0.01-en van a load, úgy, hogy közben fut a többi alkalmazás is.
Egyébként a transmission-t én a remote gui-val szoktam csesztetni, nekem jobban bejön, mint a webes felület.

( petyka2 | 2010. 09. 20., h – 11:52 )

ulimit -n -nél az open files értéke 1024.
próba képpen hol tudom árítni, hogy minden induláskor 2048 legyen az értéke?
melyik fileban?
(hátha csak kevés a nyitható fileok száma az rtorrentnek és azért akad)

( petyka2 | 2010. 11. 13., szo – 23:48 )

Egy-két fejlemény.

Amióta Debian Lenny van fent, fagyásmentesen megy minden. Gyári kernellel, 2.6.26-ossal.
Viszont így nagyon lassú a vinyó művelet. Torrent is lassú, meg a samba másolás is lassú. (kb. 18 mbyte/s)

Meguntam, hogy lassú, gondoltam felteszem a 10.10-es ubuntu_64-et.
Sokkal gyorsabb a vinyó művelet, torrent alatt is, meg samba alatt is. (kb. 38mbyte/s)

De sajnos megint elkezdett lefagyni. Épp most építi újra a raid tömböt.

Azt olvastam, hogy lehet, hogy ezzel a vinyóval gondok vannak raidben (wd10ears)
Nem értem igazán, hogy mi a baj a vinyókkal, mert ha debian lenny alatt megy fagyásmentesen a raid,
akkor miért fagy ubuntu 10.10 alatt? (2.6.35ös kernellel)

Valakinek valami ötlet?
Ha bejezi a raid-újraépítést és nem sérült semmi, akkor megpróbálom a debian_testing_64-et, hátha az abban
lévő kernellel már gyorsabb a vinyóművelet és nem fog fagyni.

A debianhoz miért nem fordítasz kézzel egy kernelt? Könnyen lehet egyébként, hogy valami a gépeddel a 2.6.26-nál újabb valamelyik kernellel jön elő a bug. Én minden esetre a 2.6.32-es utolsó verzióát próbálnám meg problémás gépen. Utána a 2.6.30-asat, ha a .32-es nem jó.