Re: Podivne zaseky - jak dal postupovat? [dlouhe]
On Wed, 25 May 2016 12:39:25 +0200, Miroslav Lachman wrote: Dan Lukes wrote on 05/25/2016 12:00: Kazdopadne, takovy seznam neznam. Muzu ti tak maximalne rict na cem to dlouhodobe a bezproblemove bezi tak poruznu v mem okoli: FUJITSU SIEMENS | PRIMERGY RX100 S5 HP | ProLiant DL180 G6 Dell Inc. | Precision WorkStation R5500 Dell Inc. | PowerEdge 2950 Moje zkusenosti se servery: IMB x3550 - funguje vse perfektne IBM x3650 - funguje vse perfektne Dell PowerEdge R720 - je tam divna RAID karta, ale opet vse funguje jak ma Dokud v tom neni nekde nejaka Broadcom sitovka, tak funguji i jiny masiny, meli jsme Supermicro, Tyan atd. ale po spatnych zkusenostech jsme prevedli komplet vse na IBM a jeden Dell server a je to aktualne rock solid. Gabriel -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Podivne zaseky - jak dal postupovat? [dlouhe]
Dan Lukes wrote on 05/25/2016 12:00: Kazdopadne, takovy seznam neznam. Muzu ti tak maximalne rict na cem to dlouhodobe a bezproblemove bezi tak poruznu v mem okoli: FUJITSU SIEMENS | PRIMERGY RX100 S5 HP | ProLiant DL180 G6 Dell Inc. | Precision WorkStation R5500 Dell Inc. | PowerEdge 2950 Pridam svoje zkusenosti z toho, co je, nebo jeste nedavno bylo v provozu: Sun Fire X2100 M2 [tech jsme meli nejvic, ale uz jsou zastaraly] Dell PowerEdge T110 II + PERC H200A Dell PowerEdge T20 Dell PowerEdge R610 + PERC 6/i HP ProLiant ML110 G5 Supermicro TwinServer s Xeon E5520 Supermicro s Xeon E3-1240 a E3-1240v3 [ty mame ted jako nejpouzivanejsi] Cisco UCS 200 M2 Zname problemy: Sun Fire - nachylny na ATA DMA timeouty (vetsinou pomohlo vymenit SATA kabel) Dell s PERC H200A - radic pro boot ukaze jen prvni disk, takze nefunguje ZFS RAIDZ boot, ale da se to vyresit tak, ze se systemovy pool udela jako 4 way mirror treba s velikosti 10GB HP ML110 G5 - zatuhava management karta iLO100, ale da se pres ipmitool restartovat, funguje i se 4TB disky a ZFS RAIDZ rootem Supermicro Twin - obcas taky zatuhle remote management, ale opet se da restartovat pres ipmitool Supermicro s Xeon E3-1240v2 - pred rokem byl ten neprijemny password leak v IPMI, ale jinak je to slusny stroj za malo penez. Kde neni HW RAID, tam je gmirror, nebo ZFS. Mirek -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Podivne zaseky - jak dal postupovat? [dlouhe]
On 05/23/16 23:29, Miroslav Prymek wrote: Kdyz uz jsme u toho, existuje nejaky neoficialni aspon trochu duveryhodny list kompatibility hw s FreeBSD - podle znacky a modelu misto podle komponent jako v oficialnich dokumentech? Dneska je spousta sestav variantnich a stejne bys nakonec musel sestavu doplnit popisem komponent. Kazdopadne, takovy seznam neznam. Muzu ti tak maximalne rict na cem to dlouhodobe a bezproblemove bezi tak poruznu v mem okoli: FUJITSU SIEMENS | PRIMERGY RX100 S5 HP | ProLiant DL180 G6 Dell Inc. | Precision WorkStation R5500 Dell Inc. | PowerEdge 2950 Your mileage may vary. Dan P.S. S ohledem na par. 2950 NOZ prohlasuju, ze tomu o cem mluvim vubec nerozumim. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Podivne zaseky - jak dal postupovat? [dlouhe]
Dne 23/05/16 v 16:45 Miroslav Lachman napsal(a): Jeden stary HP ML110 G5 s 5GB RAM mam v provozu asi 7 let. ZFS je na nem od pocatku. Je to uloziste zaloh a podobny problem jsem na nem jeste nezaznamenal. I kdyz tam nepouzivam salt-ssh, tak si myslim, ze je to chyba jen toho konkretniho kusu, co mas. Nemyslim si, ze by to nejak zvlast souviselo prave s tim saltem, pouzivam ho na vic serverech a nikde jinde jsem na to nenarazil. Navic tenhle server byl pred cca 2ma lety normalne v produkci a bez problemu. Vypada to fakt na hw zavadu starim (viz niz). Pokud hledas nejakou levnou dobrou nahradu, tak se podivej na Dell PowerEdge T20 s tim Xeon procesorem (ta lacinejsi varianta je myslim s Celeronem). Jsem s tim strojem spokojenej i na desktopu (PC-BSD) - jen jsem tam dal nVidia grafiku. Dik moc za tip, vypada to jako presne ten typ zeleza, ktery na tohle pouziti potrebuju a cena je dobra. Kdyz uz jsme u toho, existuje nejaky neoficialni aspon trochu duveryhodny list kompatibility hw s FreeBSD - podle znacky a modelu misto podle komponent jako v oficialnich dokumentech? Dne 23/05/16 v 17:22 Dan Lukes napsal(a): Zaprve, mas byt pri podobnem testu prihlaseny dvakrat - pak se po zaseknuti prihlasovat znovu nemusis. Za druhe, mas si, na te konzoli, kde bys ten 'kill -9 ' psal pred tim nez to zadreso spustit 'kill -0 '. Pak je vse potrebne v cache a je slusna sance, ze ten prikaz pujde spustit i nad zadrenym diskem neb disk potrebovat nebude. Jo, to je dobrej tip. Moc jsem to neresil, protoze v tomhle stavu to stejne v produkci byt nemuze, tak jsem to nechal bezet jenom tak mimo, nic neriskoval a moc nad tim nepremyslel. Kazdopadne takhle je to aspon cenny poznatek, ktery si zapamatuju - ze ZFS mirror fakt rozumne sahne na druhy disk, i kdyz je ten prvni v takhle divnem stavu (z pohledu ZFS vlastne "v poradku" a presto nefunkcni). Jsem dost rad, ze jsem si to takhle nadrsno prakticky vyzkousel ;) Ten "novy" disk, ktery se ti zadrel taky - to byl stejny vyrobce a model ? Stary byl WD Black 500G, novy WD RED 3T. Sice stejny vyrobce, ale jina rada a navic je deli hezkych par let, tak by ten firmware snad ani nemusel být moc stejnej. Ale samozrejem to muzou bejt i ty kondenzatory (ostatne, zminoval jsem tu moznost taky) a pak ti novy server problem vyresi. Uz se k tehle variante zacinam klonit jako k nejpravdepodobnejsi. Po restartu tlacitkem dneska se mi totiz ten zasek pro zmenu zase vubec nepodarilo vyvolat stejnym postupem, ktery mi predtim nekolikrat vysel kratce po sobe. A to jsem tam ten salt nechal bezet ve smycce nekolik hodin. Takhle divne chovani se dvema ruznymi disky, neodhadnutelne, nepredvidatelne, to mi fakt prijde jako nejaky ten kondik, ktery si dela co chce, podle teploty nebo kdoviceho... Vidim to na to nove zelezo... ...a jestli se to zopakuje, tak me asi odvezou houkackou do blazince ;) diky moc za vase rady Mirek -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Podivne zaseky - jak dal postupovat? [dlouhe]
On 05/23/16 14:28, Miroslav Prýmek wrote: Takze prozatimni zaver je, ze salt-ssh dela neco Jelikoz k tomu zaseku doslo na _novem_ disku (opet ada1), pojal jsem podezreni, ze je vadny ATA kanal na radici nebo kabel (ten jsem nemenil). Zkusil jsem teda ada1 z mirroru vyhodit a znovu spustit X. A opet se to zaseklo. Tentokrat uz mi ale watchdog nepomohl, protoze se jelo jenom z jednoho disku, ktery se sekl a timpadem uz ani neslo spustit zadny prikaz ani se prihlasit. Zaprve, mas byt pri podobnem testu prihlaseny dvakrat - pak se po zaseknuti prihlasovat znovu nemusis. Za druhe, mas si, na te konzoli, kde bys ten 'kill -9 ' psal pred tim nez to zadreso spustit 'kill -0 '. Pak je vse potrebne v cache a je slusna sance, ze ten prikaz pujde spustit i nad zadrenym diskem neb disk potrebovat nebude. 1. salt-ssh dela neco netradicniho, v cem je proste ve FreeBSD chyba, ale pri jinem provozu se neprojevi 2. nejaka hw zavada kdovikde (ale je divny, ze ji neodhali stresstesty) Od doby co maji disky bezne NCQ je vsechno o dost komplikovanejsi. Muze jit klidne o to, ze disk zadrou dva konkretni requesty, ktere jdou ve spravnem poradi po sobe. A tobe se podarilo najit software jehoz aktivity k takovemu poradi vedou, zatimco jiny software, byt' by delal neco podobneho, nedela to uplne stejne a requesty an disk prijdou v trochu jinem poradi coz staci aby se interne nezadrel. Coz je, samozrejme, jen hypoteza. Ten "novy" disk, ktery se ti zadrel taky - to byl stejny vyrobce a model ? Mozna by stacilo vzit podoben velky disk jineho vyrobce, nebo alespon jine modelove rady. Proste aby to melo pokud mozno jiny firmware. Pokud jsem se totiz nahodou trefil, tak pri trose smuly ti to muze delat i ten novy server, pokud se v nem znovu nestastne sejde hardware se softwarem. Ale samozrejem to muzou bejt i ty kondenzatory (ostatne, zminoval jsem tu moznost taky) a pak ti novy server problem vyresi. Bohuzel, v tomhle pripade nedostanes radu, u ktere by byla jistota trefy. Dan -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Podivne zaseky - jak dal postupovat? [dlouhe]
Ahoj, resil jsem podobnou zalezitost zde na foru par let dozadu. Problem byl v nepatrne nafouklych kondikach kolem SATA portu. Vymena zakladni desky problem vyresila. G -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Podivne zaseky - jak dal postupovat? [dlouhe]
Miroslav Prýmek wrote on 05/23/2016 14:28: Prijde mi, ze uz jsem vycerpal tu "rezervu", kterou jak jsi psal, mam na tyhle problemy zaplacenou, a asi prijde na radu jednani se zakaznikem o koupi noveho serveru (coz vede k otazce, jake soucasne male servery maji dobrou kompatibilitu s FreeBSD, ale tenhle dotaz kdyztak polozim v novem vlakne). Jeden stary HP ML110 G5 s 5GB RAM mam v provozu asi 7 let. ZFS je na nem od pocatku. Je to uloziste zaloh a podobny problem jsem na nem jeste nezaznamenal. I kdyz tam nepouzivam salt-ssh, tak si myslim, ze je to chyba jen toho konkretniho kusu, co mas. Pokud hledas nejakou levnou dobrou nahradu, tak se podivej na Dell PowerEdge T20 s tim Xeon procesorem (ta lacinejsi varianta je myslim s Celeronem). Jsem s tim strojem spokojenej i na desktopu (PC-BSD) - jen jsem tam dal nVidia grafiku. Mirek -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Podivne zaseky - jak dal postupovat? [dlouhe]
Šance na úspěch jsou minimální, ale ještě bych se zkusil podívat po různých updatech typu BIOS apod. Miroslav Prýmek wrote (2016/05/23): > ... > 2. nejaka hw zavada kdovikde (ale je divny, ze ji neodhali stresstesty) > ... Mně to zas až tak divný nepřipadá a vůbec bych se nedivil, kdyby šlo o problém konkrétního kusu HW v konkrétní konfiguraci a v konkrétním prostředí. -- Rudolf Cejka http://www.fit.vutbr.cz/~cejkar Brno University of Technology, Faculty of Information Technology Bozetechova 2, 612 66 Brno, Czech Republic -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Podivne zaseky - jak dal postupovat? [dlouhe]
Diky, Dane, minimalne jsem si diky tvym komentarum utridil myslenky a posunul se v dalsim postupu. Samozrejme jsem zapomnel napsat dost podstatnou informaci: doslo k tem samovolnym resetum, ktery jsem pricital vadne UPSce (asi opravnene, po jeji vymene se neopakovaly), potom doslo k zaseku na disku ada1 pri operaci X (viz dal), tak jsem disk ada1 vymenil (za jiny model jineho vyrobce) - a pak doslo pri operaci X opet k temuz i s novym diskem. To jsem zapomnel napsat :( Diky moc za radu s watchdogd, nikdy jsem to zatim nepouzil a je to super vec pro takovyhle situace! No takze jsem watchdogd zapnul a nekolika pokusy overil, ze se zasek opravdu da vyvolat akci X, coz je vzdalene spusteni salt-ssh ( https://docs.saltstack.com - konfiguracni management ). K zaseku nedojde deterministicky, ale po par pokusech k nemu vzdycky doslo. (cca dvakrat, trikrat jsem zasek + reset zopakoval, takze to fakt vyvolat jde). Na jinych serverech se mi to nestalo ani jednou. Takze prozatimni zaver je, ze salt-ssh dela neco, co diskove stresstesty nedelaji. Prozatimni podezreni je, ze salt-ssh zjistuje "fakta" o serveru a v ramci toho mj. dela treba "camcontrol identify adaX" pro vsechny disky. A hned predtim a potom intenzivne saha na disky a sit, tak by tam mohlo dojit k nejake situaci, kterou normalni stresstest nenavodi. No a ted pres vikend jsem teda zkusil jeste jednu vec: Jelikoz k tomu zaseku doslo na _novem_ disku (opet ada1), pojal jsem podezreni, ze je vadny ATA kanal na radici nebo kabel (ten jsem nemenil). Zkusil jsem teda ada1 z mirroru vyhodit a znovu spustit X. A opet se to zaseklo. Tentokrat uz mi ale watchdog nepomohl, protoze se jelo jenom z jednoho disku, ktery se sekl a timpadem uz ani neslo spustit zadny prikaz ani se prihlasit. Takze vic uz jsem otestovat nestihl. Kazdopadne po tvrdem resetu tlacitkem probehlo vraceni do mirroru + resilver v poradku, takze samotne diskove operaci jsou asi v pohode. Takze zaver pro me je, ze bud 1. salt-ssh dela neco netradicniho, v cem je proste ve FreeBSD chyba, ale pri jinem provozu se neprojevi 2. nejaka hw zavada kdovikde (ale je divny, ze ji neodhali stresstesty) Prijde mi, ze uz jsem vycerpal tu "rezervu", kterou jak jsi psal, mam na tyhle problemy zaplacenou, a asi prijde na radu jednani se zakaznikem o koupi noveho serveru (coz vede k otazce, jake soucasne male servery maji dobrou kompatibilitu s FreeBSD, ale tenhle dotaz kdyztak polozim v novem vlakne). Takze, Dane, jeste jednou dik moc za konzultaci. Mirek -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Podivne zaseky - jak dal postupovat? [dlouhe]
On 05/20/16 17:33, Miroslav Prýmek wrote: zasek procesu v D stavu po pokusu o zapis na disk. No takze jsem logicky pojal podezreni, ze je to chyba disku. Nebo komponent s nim souvisejicich - radice, kabelu. Dale, se sestupnou pravdepodobnosti - to taky muzou byt vysychajici kondenzatory na desce nebo ve zdroji a s tim souvisejici vznik ruseni - a disk je jen prvni, ktery na problem citlive zareagoval (a kdo vi jestli prvni, byl tam taky jeste ten reset). A ruseni nemusi byt nutne interni, to muze prichazet ze site (napajeci i datove), kabelem od monitoru a ostatne jakymkoliv kabelem, treba i tim od klavesnice, pokud se tahne soubezne s necim, co zacalo rusit. # zpool set failmode=continue zroot ale to se zaseklo taky To jako indicie moc nepomuze. Jakmile uz je jednou fronta pozadavku na disk jednou zadrena, zadre se kazdy proces, ktery si do ni neco da a pokusi se cekat na dokonceni. A ja predpokladam, ze si zpool tyhle nastaveni na disk pise "pro priste". Stejne tak se zasekl pokus o vyhozeni disku z poolu. Ani na CAM urovni se mi to nepodarilo: # camcontrol eject ada1 Error received from stop unit command Oboji ze stejneho duvodu. Takze zbyla posledni sance ten disk natvrdo odpojit (porad za behu). Tohle je jedina sance. To probehlo v poradku, disk zmizel, dokonce z gstatu zmizely visici operace, ale ne vsechny - misto tech 12 tam byla jedna :( A to byla, zrejme, ta, ktera byla "zadrena". Ty ostatni byly jen ve fronte za ni a s odstranenim disku byly abortovane. Tahle jedna uz ale zrejme byla rozjeta a cekala na nejakou reakci hardware - a ta reakce neprichazela. Takze jsem dosel k nazoru, ze chyba bude v disku. Jenze SMART nerikal nic, offline test probehl bez chyby a jakekoli stresstesty jsem se snazil na disku poustet, vsechno bylo uplne v pohode. Chyba (v) disku je porad nejpravdepodobnejsi, nebo v bezprostredne souvisejicich komponentach. Ze SMART nic nerika neni dukaz niceho, on je dnesni disk uz jako vsechno ostatni procesorem rizena krabicka, a kdyz ten firmware (kdo vi, kdo ho psal) zblbne/zdechne, neni dukazem niceho, ze o zdechnuti nebyl timtez firmwarem ucinen radny zapis. Ani to, ze se ti pak vedome nepodarilo disk znovu dostat do tehoz stavu. Jeste me napadlo, jestli by to nemohlo souviset s jinou veci - pri pripojeni na tenhle server se mi obcas stavalo, ze jakoby na sekundu dve zamrzl a pak jel v pohode dal. Nedoresil jsem, jestli to bylo sitovkou nebo necim jinym. Bylo by mozny, ze by nejaka chyba v hw nebo v driveru zpusobila nejake takove cekani Ano. Staci aby nejaky driver zakazal veskera preruseni a z nejakeho duvodu nikoliv na par taktu procesoru ale na delsi dobu, a po onu delsi dobu se nepohne nic. neco v diskovych operacich by spravne nevytimeoutovalo a ZFS by se tim dostalo do vecneho cekani?! Zbytecne komplikovana uvaha. V diskovych operacich nemaji timeouty co delat - a pokud by se tam nejake objevovaly, je treba predevsim resit tenhle primarni problem. Ted fakt nevim, co s tim dal :( Jestli jsem to spravne pochopil, tak konkretni problem se objevil pouze jednou a nepodarilo se ho zopakovat. Takze statisticky vzorek k analyze je fakt hodne maly. - dost dobre nemuzu riskovat, ze se tohle bude se serverem stavat v ostrem nasazeni. Uz proto, ze to vyzaduje tvrdy reset na miste... Mozna ne - nezkusil's natvrdo sestrelit watchdogd. Pak by to mel chip hardwarove otocit. - nedokazu nijak urcit, jestli chyba byla v disku, radici nebo necem jinem a jestli se bude opakovat To se u jednoho pripadu opravdu rict neda. Vime jen, ze zaseknuty proces cekal na dokonceni zadaneho pozadavku na cteni dat z disku a podle vseho nikdy neobdrzel informaci o tom, ze je operace dokoncena nebo zrusena. Nevime ale ani, zda ta operace byla zadana s moznosti timeoutu. Jedna vec je, ze nebyla dokoncena - za to ZFS nejspis nemuze a ma to nejakou, spise hardwarovou nez softwarovou, pricinu. Krome mnoha jinych se napriklad mohlo "ztratit" preruseni. Zda byl pozadavek zadany s nejakym timeoutem (a jak dlouhym) je do znacne miry nesouvisejici otazka - ale tohle uz ZFS na triku mit muze. Otazka zni velmi pragmaticky - jsi schopen otevrit zdrojaky, projit cestu od zfs_freebsd_read k sleepq_wait a zjistit, zda je cekani v te sleep queue timeoutovatelne a pokud ano, zda pri pruchodu touto cestou je nejaky timeout nastaven ( a to nejaky kratsi nez "skoro nekonecny") ? A pokud ano a zjistis jak to funguje, jsi schopen si provest vlastni upravu a pouzivat vlastni upraveny kernel ? Pokud ne, pak nema smysl, abyses "softwaorovou" casti problemu zabyval. Pokud ano, uvedom si, ze vysledkem bude "jen" to, ze pro vyskytu problemu, ktery je primarni pricinou, se ti nezadre cely system, ale zrejme se podela jen neco mensiho. - jak jsem psal, pred timhle incidentem sel server do tvrdeho resetu asi dvakrat. Mohlo to poskodit zpool tak, aby se choval takhle divne? Melo by smysl ho smazat a vytvorit
