Month: March 2008

Aikanaan Mappia suunnitellessani olin ihmetellyt, mistä johtuu noin 11 tunnin syklillä kuormituskäyrissä näkyvä piikki, joka ei heijastu missään muissa kuormitusmittareissa kuin juurikin Linuxin loadissa. Sain lopulta selville, että se liittyy Red Hat Linuxin klusteritoteutuksen tiedostojärjestelmänkäsittelyskriptiin, ja jätin bugiraportin. Sen jälkeen olen elänyt haamukuormituksen kanssa – siitä ei ole ollut Mapin toiminnalle mitään muuta haittaa kuin se, että kuormituskäyrien seuraaminen on ollut hieman hankalampaa kuin ilman sitä olisi.

Taannoin tulikin sitten Red Hatin kehittäjiltä C:llä kirjoitettu korvausehdotus tiedostojärjestelmäntarkistus-skriptille. Asensin sen toissijaiseen klusteriin, ja voilá – tontunhatut (eli kuormapiikit) katosivat. Ehkä sekin saadaan laaduntarkkailusta läpi RHEL 5.2:een mennessä, niin sitten voisin ottaa sen mukaan myös ensisijaiseen klusteriin samalla, kun uuden LVM2:nkin. Ainahan sitä saa toivoa…

Viime keskiviikkoiltana sain tekstiviestin: Mapissa on pahoja kuormitusongelmia. Niitä ei ollutkaan näkynyt sitten viime kesän.

Mistä oli kyse

• Yksi Vallilan EVA-levyjärjestelmästä Mapille annetuista levyistä tapissa. Ilmeisesti juurikin tarkkaan sen ajan, kun muuan 250 gigan levyosiota siirrettiin EVAssa paikasta toiseen. Ja tämä taas oli ongelma, koska EVA-levyjärjestelmässä on ohjainta kohti vain 500 megatavua kirjoitusvälimuistia – se oli siis täynnä, joten Mapin suunnasta samalle ohjaimelle tulevat kirjoituspyynnöt hidastuivat.
• Tämän vuoksi pääsy TLS-istuntovälimuistiin tietyilla Mappi-frontendeillä (p01,p02,p02) hidastui huomattavasti.
• Tämän seurauksena Webmailin imapproxy (ilmeisesti) kyllästyi odottelemaan tls-kättelyn läpimenoa ja antoi IMPille FAILED LOGINnia.
• Lopputuloksena ne käyttäjät, joille on Webmailissa konfiguroitu frontendiksi p01-p03, eivät päässeet sisään niin kauan kuin osion siirto kesti.
• Ne käyttäjät, jotka käyttivät posti.mappi-osoitetta jollain muulla asiakasohjelmalla kuin Webmaililla, pääsivät kyllä sisään, mutta SSL/TLS-kättelyyn meni useita minuutteja.
• Käyttäjillä, jotka lopulta pääsivät sisälle, esiintyi havaittavaa hidastelua; ei kuitenkaan vielä käyttökelvottomaksi tekevää (koska myös muut EVA-levyt hidastelivat; vastaavia pullonkauloja niihin ei kuitenkaan syntynyt).
• Huomattavaa hidastelua esiintyi samaan aikaan myös Aleksandriassa: Netware-levyihin käsiksi pääseminen kesti ikuisuuden. Ongelma ei siis ollut Mappi- eikä edes Centos Linux -spesifinen.

Mitä asialle tehtiin

• Siirsin Mappi-frontendien metadataosiot eri EVA-levyille, ettei kolme neljästä ainakaan väkisin ole samalla ohjaimella.
• Poistin TLS-istuntovälimuistin käytöstä – välimuistista lienee ollut hyötyä lähinnä muutamalle käyttäjälle, ja sisäänkirjautumiseen liittyvä pullonkaula poistui.

Kun EVA-järjestelmässä seuraavana iltana siirrettiin yksi 320-gigainen osio paikasta toiseen, Mappi ei mennyt jumiin. Mutta siinä saattoi olla kyse siitäkin, että siirtoa oli hidastettu tarkoituksella, ettei se käyttäisi levyjärjestelmän koko kapasiteettia.

Mitä vielä tulevaisuudessa voidaan tehdä

• Kunhan LVM2:n bugin n:o 252150 korjaus on saatu asennetuksi Mappi-koneisiin (ilmeisesti Centos 5.2:ssa joskus ensi kesänä), voidaan lopulta poistaa 28 ylimääräistä LVM:n fyysistä taltiota eli 28 ylimääräistä pientä EVA-levyä, jolloin EVA todennäköisesti hukkaa vähemmän kirjoitusvälimuistia, kun levyjäkin on vähemmän.