FreeBSD 7.1 amd64 naponta egy fagyás

FreeBSD-all

Sziasztok,

Olyan gondom van hogy a szerverünk kb. naponta egyszer lefagy. Mindig reggel, kb. ugyan abban az időben. De van néha olyan nap amikor nem fagy le. Lefagyás alatt a következőt kell érteni:

- ping-elni lehet
- ssh-zni lehet, de nem jön válasz
- ugyanígy a webszerver is ilyet csinál

gandalf@saturnus:~$ telnet shopzeus.com 80
Trying 195.228.74.135...
Connected to shopzeus.com.
Escape character is '^]'.
GET /

Tehát mindennel lehet csatlakozni, de utána nem történik semmi. A gépet újra kell indítani. A logokban semmi nincs, amennyire én meg tudom állapítani, mintha elvágták volna. Fagyás után a következő ami a logokban van az a következő reboot eredménye.

Próbáltam készíteni saját logot ilyennel:

* * * * * date >> /root/crashlog ; uptime >> /root/crashlow ; ps axulwwwww >> /root/crashlog

Ebből az látszódik hogy a 8 processzorból kb. 7 semmit nem csinált a lefagyás előtt. Utána ez a log is elakadt.

Voltam már bent a szerverteremben, a kártyák nem büdösek, a kábelek jól be vannak dugva stb.

Tiltottam le cron job-okat is (ilyeneket mint "find -sx /"), megnöveltem a dir cache mem méretét 128MB-ra, mert nagyon sok a file.

A gép garanciás, de ez a "néha lefagy" az tipikusan az a probléma mire nem érvényesítik a garanciát.

Mit tegyek? :-(

  • 1500 megtekintés

( thuglife | 2008. 10. 16., cs – 09:35 )

:) hasznalj normalis operacios rendszert

( godot v | 2008. 10. 16., cs – 09:37 )

A 7.1 még béta nem?? vagy 7-STABLE ágat használod?

A 7.1 még béta, a 6.4-RC1 jött ki nemrég, amit majd a 7.1-RC1 fog követni hamarosan. Production környezetben nem feltétlen mernék 7.1-et használni. Azért a 7.1-es stabil ág még messze van, szerintem.

/mazursky 

Love your job but never love your company!
Because you never know when your company stops loving you!

És te hallgattál rá? Az egy dolog, hogy nemsokára release lesz, de béta rendszert felrakni, ezzel az indokkal az szerintem ritka nagy önbizalom kell az üzemeltetéshez.

Egyébként igen, nézd meg először stabil verzóval (7.0 pl.), utána van értelme bármi további feltételezésnek.

----------------
Lvl86 Troll

Most néztem és a 7.1 kódja már "frozen" állapotban van. Ezek szerint már nem fejlesztik csak hibát javítanak.

Megpróbálom a downgrade-et a "standard" módon:

csup (RELENG_7_0)
make buildworld
make buildkernel
make installkernel
make installworld
mergemaster
reboot

Mire figyeljek még? Tudtok leírást arról hogy mik lehetnek a buktatói?

Lehet, hogy én vagyok paranoid, de egy éles szerveren nem merném ezt megcsinálni.
Rakj fel egy másik gépre 6.3-at, vagy 7.0-t, tedd át oda a szolgáltatásokat, aztán meg lehet ezzel kísérletezni, s nem lesz baj, ha esetleg félnapot áll a gép.

szerk.: egyébként hasonló hibát én akkor tapasztaltam, amikor két távoli gép között vpn kapcsolaton keresztül nfs-ek voltak mountolva, s szakadozott a gépek között a kapcsolat.

Igaz, de Te 7.1-et sem mertél volna tenni rá. Magamtól én sem. :-)

A probléma csak annyi, hogy ebben a gépben 10 vinyó van és kb. 8 millió file. Nincs másik olyan gép amire át tudnám tenni, hogy aztán kisérletezzek. De ha lenne, akkor sem fél nap leállás lenne, hanem kettő (egy amíg odamásolom, egy amíg vissza...)

NFS-t nem használok. Viszont sshfs-t igen, bár gondolom ez nem okozhat fagyást?

...akkor sem fél nap leállás lenne, hanem kettő (egy amíg odamásolom, egy amíg vissza...)
A félnapos leállást a kísérletezés alatt bekövetkezett hibalehetőségekre gondoltam, amikor már máshol futnak a szolgáltatások, ezzel a géppel meg azt csinálsz, amit akarsz, nem lógnak rajta felhasználók. Igaz, én csak ~milliófájlos szervereket migráltam, ezesetben a szolgáltatás max. 20 percig állt egy előre bejelentett időpontban. (persze elő volt készítve minden, de az előkészületekhez nem kellett leállítani semmit).

SSHFS-sel kapcsolatban nekem is voltak hasonló gondjaim...
A gép látszólag fagyott, bementem, gombokra reagált, de nem engedett be.
Alt+Ctrl+Del-re hosszan várt, áram el, áram vissza segített.

SSHFS helyett más megoldás került bevezetésre, azóta nincs gond.
Ugyanaz az OS, ugyanaz a hardver.

Csak UFS2 + gjournal van rajta.

Tudom a gjournal okozhatna fagyást, de mielőtt ezt számításba vennénk, elmondanám hogy ezekre a partíciókra mind külön van journal terület:

/home
/usr
/var
/pgdata0 (postgres adatbázisnak)
/data

és ezek közül a /home-ot kivéve midegyik 40 Gb-os. Tehát összesen 170Gb journal terület van, ami gondolom elég sok ahhoz hogy ne fagyjon...

( kiuka | 2008. 10. 16., cs – 13:57 )

ha fut rajta munin akkor azt lodd le mert nekem az gondot okozott a 8 processzoros gepeken, 4en siman ment, nem tudom mibaja van a 8al:)

Nincs munin. Alapvetően ezek futnak (azok közül amik terhelhetnek is):

- apache22 + php5
- postgresql83-server
- postfix
- egy csomó Python-ban írt program meg hálózatos szolgáltatás
- sshfs (szerver oldalként, nem kliensként)

Persze más dolgok is, de azok nem igazán terhelik a gépet.

( nagylzs v | 2008. 10. 18., szo – 11:08 )

Ahh, kezdem feladni! Ma downgrade-eltem 7.0 STABLE ágra, és átállítottam a scheduler-t ULE-ről 4BSD-re.

Eredmény: most már óránként fagy.