Dotaz: LSI 320-2E hrozne pomaly

[krnoha]

Máme tady server Primergy RX300S2 a v něm RAID5 řadič LSI 320-2E. Zapisovalo se na něj nějakých 50MB/s (XFS). Potom nám vyměnili MB a uživatelé si začali stěžovat na pomalost disku. Není divu, dosáhneme nejvýše 5MB/s. Chybová hlášení žádná. Něco se asi muselo špatně nastavit v rámci výměny MB. Neměl by někdo prosím myšlenku, co by to mohlo být? Uvnitř jsou SCSI disky 300MB a i ten RAID5 se tváří jako SCSI disk.

Odpovědi

[Petr Šobáň]

Vypnuté DMA ? Problémy s IRQ ? Špatný ovladač toho řadiče ? Jiné HW chyby na sběrnici ? Špatně nastavený BIOS který to nějak brzdí ?

Bez nějaké chyby se dá těžko usuzovat co nefunguje.

[František Ryšánek]

Ten řadič má dávat cca 100-150 MBps sekvenční průchodnost (při přístupu na holé blokové zařízení, tj. bez vlivu filesystému).

Nedokážu si představit, co by mohlo na PCI Expresu způsobit takové zpomalení. I pokud by se sběrnice dohodla na šířce x1, pořád je tam 250 MBps full duplex. Problémy s DMA a IRQ to teoreticky být mohou, pokud by byl čipset nějak správně vadný - ale pokud by PCI DMA nebo IRQ vůbec nefungovaly, sypalo by to chyby, resp. by server vůbec nenastartoval, boot jádra by skončil kernel panicem (pokud se bootuje z jiného systémového disku). (Rozhodně se nejedná o vypnuté ATA UDMA a nějaké banální ISA IRQ konflikty, bavíme se o PCI Express a U320 SCSI).

Eventuelně by to mohl být nějaký problém s routováním IRQček přes ACPI. Kdyby nějaké nesouvisející zařízení sdílelo IRQ s RAIDem a generovalo by neobsloužené interrupty, takže by byl systém přetížený obsluhou interruptů... není pro ten board k dispozici čerstvější BIOS? Nehlásí kernel při bootu, že škrtí nějaké splašené IRQ vstupy? Zkuste při bootu přidat v bootloaderu za jméno kernelu ještě parametr irqpoll, to by mohlo pomoci. Pokud to pomůže, máte problém s IRQčkama přes ACPI. V této souvislosti, zkuste si v BIOSu zkontrolovat, že máte onboard SATA řadič (v rámci ICH) přepnutý do řežimu "Enhanced mode", tj. jsou vidět jak IDE tak SATA kanály hezky za sebou... už jsem zažil, že "combined mode" dělal binec v ACPI interruptech.

Co máte za verzi kernelu?

Zkoušel jste koukat do BIOSu toho RAIDu, nebo stáhnout a spustit MegaMGR? Nebo vám to zatím nějak jede, tak jenom koukáte do /var/log/messages, že tam nejsou žádné chybové hlášky? Nebliká server failure ledkou u některého disku, nepiští na RAIDu alarm?

Co hlásí BIOS při bootu? Napočítá správně procesory a nahlásí hodinovou frekvenci? Kolik bogomipsů obenchmarkuje při startu Linux? Pokud je to server s Xeonama (tipuju čipset i7520), bude obsahovat ECC paměti. Když mrknete do BIOSu do System Event Logu (pokud stroj takovou věc má) nejsou tam nějaké hlášky od paměťového řadiče?

Nemáte uvolněný/nepodmazaný chladič na procesoru? Některé motherboardy (a ostatně i Linux sám) umí omezovat hodinovou frekvenci při přehřátí. Přesto si nedokážu představit, jak by se to mohlo takhle zpomalit, to podřazení je řádově na 50%, a linux to oznámí do logu a motherboard většinou rozsvítí alarmovou kontrolku přehřátí.

Pokud je tohle všechno v pořádku, napadá mě: zkuste vrazit RAIDový řadič do nějakého jiného boardu a pustit to jenom tak rozložené na stole, kolik to pojede. Jako jiný board potřebujete něco s PCIe x8 nebo x16 (je ten RAID x8, ne?). Může posloužit třeba i nějaký desktopový s PCIe x16 slotem pro grafiku (a se starožitnou grafikou v PCI slotu, nebo s integrovanou onboard grafikou). Pokud to bude dávat v úplně jiném boardu rozumné hodnoty, je ten podezřelý board skutečně nějak nemocný. (Proč Vám vlastně měnili board?)

Pro zběžnou kontrolu průchodnosti bych doporučil třeba cp /dev/sda /dev/null a koukat na to z druhé konzoly iostatem z balíku "sysstat". Zápis nedestruktivně nevyzkoušíte. Jako test přes filesystém můžete použít třeba Bonnie/Bonnie++, část benchmarku běží v sekvenčním režimu a její výsledky jsou hlášeny samostatně.

Další věc: zkuste si připojit disky na obyčený SCSI HBA do nějakého jiného živého Linuxu. Dejte pozor ať na disky nic nezapíšete. Stáhněte si scsiinfo a zkuste ze všech disků vytahat "grown defects list" - tuším scsiinfo -d . Grown defects list by měl být prázdný. Pokud není, disk má problém. Disk s velkým počtem relokovaných sektorů je často hodně pomalý. Pokud je v RAIDu, tak třeba reaguje na příkazy, ale pomalu, a zbytek RAIDu tak brzdí. Nejhorší jsou disky, které mají "grown defects list" prázdný (nebo SMART error log), při čtení se tváří dobře, ale při zápisu začnou házet fatální chyby (ale to by RAID řval hodně nahlas). Ostatně už jenom kolísající rychlost sekvenčního zápisu signalizuje nemocný disk, i když jinak je všechno OK. Bohužel zápis nelze otestovat jinak než destruktivně (pokud se týče dat).

BTW, nezmrvili Vám při té výměně motherboardu SCSI sběrnici? Kabely, terminátory... Už jsem několikrát viděl zohýbané nožičky v konektorech HD68 a VHDCI. Taky to může být jenom povytažený kabel. LSIčka dokážou ustát leccos, a to tím způsobem, že provedou fallback na nižší SCSI rychlost. A moc nahlas při tom nenadávají. Vámi zmiňovaná rychlost by řádově odpovídala základnímu synchronnímu narrow SCSI, asynchronní režimy jsou ještě pomalejší.

Jak jste vlastně testovali rychlost? Zkoušeli jste to na lokále, nesoudíte jenom podle síťové průchodnosti? Nemáte link spojený na 10/half, špatně proti sobě full/half, nebo nějaký binec kus dál v Ethernetu? Tady poskytne základní přehled ethtool/miitool (a login na příslušný switch) plus lokální test průchodnosti.

Ještě mě napadá, že novější LSIčka mají BIOS (resp. už jenom "WebBIOS"), který bez bateriové zálohy neumožní povolit write-back cache. Takže 128MB cache RAIDu jede v režimu write-through, což může kapku brzdit. Ale to zpomalení se projeví jenom při větší zátěži, drobných transakcích, více uživatelích. A řekněme na půlku, ne na dvacetinu. Zapnout se to dá přes linuxový MegaMGR.

[krnoha]

Dík to bylo vyčerpvaíjcí. Zkusím se podívat po novějším BIOSu, to se mi zdá dobrá stopa. Zkusím to s volbičkou irqpoll a když tak nějak zacvičím s ACPI. Podívám se, jestli je tam nějaký Event log.

Koukal jsem se do BIOSu toho RAIDu. Všechny disky se hlásí bez chyb. RAID tvrdí, že je OK. V logu z bootování mi to píše 6807.12 BogoMIPS . Já nevím co to znamená. Nic mi nebliká a nepiští. V messages žádná chyba.

Stalo se, že začaly nějak postupně odumírat filesystémy, vypadalo to na úplný rozpad. Dělo se to při větším zatížení diskovým provozem. Ale po rebootu byla všechna data na svém místě. V BIOSu RAIDu se dá nastavit kešovaný nebo přímý režim. Když jsem dal přímý, tyhle problémy vymizely. Udělal jsem /var/log jako zvláštní filesystém a zase zapnul kešovaný provoz. Rozpad opět nastal a v logu něco bylo, že se spouští nějaká patrola. RAID si vnitřně zřejmě dělal nějakou kontrolu nebo opravu. To stačilo servisní firmě, aby vyměnili MB. Po výměně nám to po hodině provozu zase padlo. Ale že jsem nevěděl co dál, jenom jsem to rebootoval a od té doby to už pár měsíců běží, kešovaně. Až uživatelé přišli na to, že je to nějak pomalý. Tak jsem se tím začal zabývat. Především jsem to zase přepnul na nekešovaný režim, ale rychlost se nezměnila.

Ten stroj je v záruce. Já vyzkouším co jsi mi poradil, pustím HW testy a budu znovu reklamovat. Každopádně děkuji za řadu pěkných tipů.

[frr]

6800 BogoMIPS na cca 3GHz serveru vypadá jako zdravá hodnota (cca 2 instrukce na takt). Mám pocit že to je na jeden procesor (nezohledňuje počet procesorů).

To odumírání filesystémů je zajímavé. Co tím přesně myslíte? Jako že najednou kernel začal sypat chyby, že s tím svazkem není řeč? Timeouty? A jenom pod větší zátěží? Možná měli LSI nějaký bug ve firmwaru - napadá mě fragmentace paměti v cache, nebo bug v TCQ indexech, jestli je něco takového možné... takovou věc jsem ještě nepotkal. Taky by to mohl být projev problémů na SCSI, to už jsem psal. Jestli máte po ruce nějaký DIMM cca DDR333 ECC unbuffered, můžete v tom LSIčku zkusit vyměnit paměť. Nicméně si myslím, že kdyby měl RAID problém s DIMMem, sypalo by to ECC errory do logu.

Ohledně cachí se v nastaveních RAIDu dají obecně vystopovat cca tyto oblasti:

1) write-through/write-back - týká se DIMMu na RAIDu, bývá per-volume

2) buffered IO / direct IO - týká se bufferů uvnitř disků

3) read-ahead on/off/adaptive (performance random/sequential) - týká se čtení z disků

Aby nakonec nebyl problém s firmwarem disků...

[krnoha]

Některé adresáře tam byly ale nedalo se v nich udělat ls. V jiných se dalo, ale chyběly tam soubory. Některé soubory byly vidět pomocí ls ale nešly přečíst. Chybová hlášení byla jedině I/O error. SCSI chyby žádné. Filesystémy se postupně dělaly read-only, nakonec i / . Ono to / je taky na tom poli.

Podle mě takhle by se to chovalo, kdyby byl problém mezi raidem a keší. Po vypnutí keše to skutečně začalo fungovat. Ale firmware RAID řadiče je prý aktuální. Vyloudit tuto chybu uměl jenom jeden z uživatelů nějakým specifickým výpočtem. Ostatní výpočtáři neměli problém. Rozhodně nestačilo libovolné větší zatížení.

[frr]

Cim dyl o tom premejslim, tim vic bych navrhoval toto: pujcit nekde LSI HBA (LSIU320 nebo 20320 nebo dvoukanalovou variantu 22320 apod.), vymenit ho za RAID, nastartovat nejakou "live" distribuci a prohnat po te SCSI sbernici nejakou zatez (read-only). Nahnila SCSI sbernice se skutecne muze chovat tak, ze se chyby zacnou objevovat az pod zatezi, a holy HBA dost podrobne hlasi do syslogu, ze ma problem.

[krnoha]

Nezapomeň že jsme vyměnili Mb i s RAID řadičem, on je integrovaný. to bychom museli mít dvě různé závady.

[frr]

320-2E *integrovaný* ? To slyším poprvé, ale mrknu se na to

Jinak výměna 320-2E za holý HBA pro potřeby testování dává smysl i v tomto případě, protože Vám dá příležitost lépe si ohmatat SCSI sběrnici. Je možné, že RAID leccos skryje - chybové hlášky ze SCSI sběrnice se do syslogu hostitelského Linuxu dostanou zprostředkovaně přes z principu mírně dementní RAIDový firmware skoupý na slovo, kdežto od LSI HBA je to z první ruky.

[frr]

Fakt že jo, je tam IOP332 onboard, a má svůj vlastní DIMM. http://manuals.fujitsu-siemens.com/serverbooks/content/manuals/english/1889-2089th-e.pdf

Údajně se to dá vypnout pomocí nějakého "iButton", pak by mohl být vidět rovnou holý LSI 1030 HBA (skrz vypnutý IOP332 v režimu PCI bridge). Ale řekl bych, že tohle zkoušet je možná lehce o hubu. Navíc osobně bych už věřil víc stand-alone PCI HBA, už proto, že se odstíní případný systematický problém někde v PCI+SCSI cestách okolo integrovaného RAIDu.

Se stand-alone HBA bude ten problém, že ve skříni je moc krátký SCSI kabel. Takže by byl potřeba ještě taky delší SCSI kabel a přístup ke SCSI backplanu, aby ho bylo kam připojit.

Některé chyby na SCSI skutečně potřebují poměrně specifickou zátěž, aby se projevily. Třeba mě se osvědčila Bonnie ve fázi "rewriting". Pokud někdo dokáže takovou chybu spolehlivě reprodukovat, je třeba mu tleskat a hýčkat si ho. Nejhorší jsou chyby, které se objevují náhodně a nejsou reprodukovatelné. Chybu lze považovat za odstraněnou teprve ve chvíli, kdy postup pro spolehlivou reprodukci přestane zabírat.

Hmm... teď mám takový pocit, že nějaký starší LSI HBA pro rychlost U160 (1010?) se mi na problematické SCSI sběrnici choval tak, že si zapamatoval poslední rychlost, na které to bezchybně chodilo, a té se HBA držel i ve chvíli, kdy už chyba ve SCSI sběrnici byla odstraněna. I přes rebooty - prostě si to zapsal do své konfigurační flashky. Nikde žádná chybová hláška, všechna data OK, jenom to bylo hrozně pomalé. Rychlost bylo třeba manuálně znovu zvednout v BIOSu HBA. Holý LSI HBA vypisuje detekované disky a rychlosti při bootu jeho Fusion MPT BIOSu. Nevím jak MegaRAID (který má za IOPem svůj privátní LSI1030 HBA). Třeba u Adaptecu lze zapnout v BIOSu RAIDu, že má vypisovat detekované disky (ne jenom logické jednotky), a vedle konfigurace AAC RAIDu je k dispozici i klasická HBA utilita pro konfiguraci SCSI sběrnice a disků (SCSI Select Utility). Pokud by se Vám podařilo dostat na konfiguraci toho MegaRAIDího privátního 1030 HBA, možná by se z ní dalo něco zjistit. Pokud se na jeho konfiguraci nedostanete, máte o důvod víc zkusit to se stand-alone HBA v PCI slotu...

[krnoha]

Stačilo nastavit režim zápisu WRITEBACK, to znamená že pole přijme požadavek na diskovou operaci a potvrdí ho, aniž by čekalo na fyzické provedení zápisu. Je to vlastně riskantní, protože zápis se taky nemusí podařit a zapisující linux už se o tom nedozví. U obyčejního disku bych do toho nešel, ale tohle je diskové pole navíc obdařené baterií. Při poruše disku se to zapíše na ostatní disky a chybující disk bude vyřazen. I při výpadku elektřiny to baterka podrží, než se nadržené operace provedou. Takže to riziko snad není tak velké. Původně bylo WRITETHROUGH, to je ta bezpečná varianta.

Dále jsem nastavil režim čtení na READAHEAD, takže po provedení zadaného čtení si pole do keše připraví ještě následující kousek dat, neboť už tuší, že na ně brzy dojde. Původně tam bylo NORMAL.

Načež se nám pole zrychlilo na osminásobek a běhá zase jako dřív, jako před první výměnou motherboardu. Ono je to celé takhle: RAID řadič je integrovaný na MB. Servisní RAID data jsou v paměti toho řadiče a kopie na discích. Po výměně MB nový řadič servisní data neměl, tak si je vzal z disků. Ale optimalizační parametry na discích nebyly, tak tam nechal defaulty. Nový RAID řadič staré parametry skutečně nemohl znát. To spíš je mohl znát ten servisní technik. který nám MB vyměnil, žeano.