Mikko Hyvärinen, Lead DBA, DB Pro Services Oy
Maailmanlaajuisesti toimivan teollisuusyrityksen ERP-järjestelmä palvelee 8 000 käyttäjää ympäri vuorokauden. Kun järjestelmä hidastui ja katkoja alkoi tulla toistuvasti, yritys kokosi asiantuntijoista taskforcen. Lopputuloksena oli vakaampi ja nopeampi ERP – puolet pienemmällä palvelimella.
Lähtötilanne: järjestelmä, joka ei saa levätä
ERP on teollisuusyrityksen selkäranka. Tilaukset, tuotanto, varastot ja talous kulkevat sen kautta, ja kun se hidastuu, hidastuu koko liiketoiminta. Asiakkaallamme ongelmat olivat kasautuneet:
- Hitaat vasteajat – käyttöliittymä takkusi, ja käyttäjät odottivat ruutujen latautumista.
- Runsaasti tietokantalukituksia – yksittäiset prosessit tukkivat kymmeniä muita.
- Ei huoltoikkunaa – järjestelmää käytetään 24/7 eri aikavyöhykkeillä ympäri maailman.
- Toistuvat käyttökatkot – palvelu ei ollut aina saatavilla.
- Nopeasti kasvava datamäärä – uutta dataa syntyy joka päivä paljon.
Ensimmäinen ajatus olisi lisätä rautaa, mutta se ei ollut enää mahdollista. Tietokanta pyöri fyysisellä palvelimella, jossa oli 48 ydintä ja 768 Gt muistia, ja kaikki suoritin- ja muistipaikat olivat jo täynnä. Laajennusvaraa ei ollut, joten ongelma oli ratkaistava tietokannan ja sovelluksen päässä.
Taskforce
Asiakas kokosi kokeneiden asiantuntijoiden taskforcen, jonka tehtävä oli yksinkertainen: saada ERP jälleen käyttökelpoiseksi. Ja aikaa oli ruhtinaalliset 3 kuukautta
Mitä teimme
Työ eteni mittaamisesta korjauksiin. Koska huoltoikkunaa ei ollut, jokainen muutos piti suunnitella niin, että sen sai tehtyä tuotannon pyöriessä.
- Aloitimme diagnostiikkaprojektilla, jolla tunnistimme tietokantaympäristön todelliset pullonkaulat. Ilman mittausdataa korjaukset olisivat olleet arvailua.
- Levyasetelman muutokset. Uudistimme levyjen konfiguraation, jotta luku- ja kirjoituskuorma jakautuu tasaisemmin.
- Indeksien ja tilastojen ylläpito. Optimoimme ylläpitorutiinit niin, että ne pitävät tietokannan kunnossa kuormittamatta käyttäjiä.
- Kyselyjen optimointi. Osa työstä oli yksittäisten raskaiden kyselyjen läpikäyntiä ja tehostamista.
- Indeksointimuutokset:
- uusia indeksejä sinne, missä niitä todella tarvittiin
- käyttämättömien ja vanhentuneiden indeksien poisto käytöstä
- datan pakkaus (data compression), joka pienentää levytilan ja muistin tarvetta
Tulokset: enemmän suorituskykyä puolella raudasta
Kun tietokanta tekee vain tarpeellisen työn, se ei tarvitse yhtä paljon resursseja. Muutosten jälkeen tietokanta voitiin siirtää täynnä olleelta fyysiseltä palvelimelta virtuaalipalvelimelle, jonka resurssit ovat selvästi pienemmät:
| Resurssi | Ennen | Jälkeen | Muutos |
| Ytimet | 48 | 24 | −50 % |
| Muisti (RAM) | 768 Gt | 368 Gt | −52 % |
| Levytilan käyttö | 5 Tt | 3 Tt | −40 % |
Lisenssisäästöt
SQL Server Enterprise Edition lisensoidaan ydinkohtaisesti, joten puolitettu ydinmäärä näkyy suoraan lisenssikuluissa. Kun 2 ytimen lisenssipaketin hinta on arviolta 15 000 dollaria, säästö on noin 180 000 dollaria:
| Ennen | Jälkeen | Säästö | |
| Ytimet | 48 | 24 | 24 |
| 2 ytimen lisenssipaketit | 24 | 12 | 12 |
| Lisenssikustannus (arvio) | 360 000 $ | 180 000 $ | 180 000 $ |
Laskelma on suuntaa antava ja perustuu arvioituun pakettihintaan; todellinen hinta riippuu sopimusmallista.
Pienempi palvelin ei tarkoittanut heikompaa palvelua – päinvastoin. Alla mittarit ennen ja jälkeen.
Page Life Expectancy – data pysyy muistissa
Page Life Expectancy kertoo, kuinka kauan (sekunteina) datasivu säilyy SQL Serverin muistissa. Mitä korkeampi arvo, sitä harvemmin dataa joudutaan hakemaan levyltä.
Ennen: arvo pysytteli jatkuvasti lähellä 3 000:n raja-arvoa, eli muisti oli koko ajan ahtaalla.
Jälkeen: arvo nousee parhaimmillaan yli 300 000:een. Viikonloppuisin suurimpien taulujen tilastopäivitykset laskevat arvoa hetkellisesti, mikä on odotettua.
Suoritinkuorma – tasaisempi puolella ytimistä
Ennen: pitkäkestoisia piikkejä jopa yli 90 %:iin, vaikka ytimiä oli 48.
Jälkeen: kuorma pysyy tasaisena ja enimmäkseen alle 50 %:n – nyt 24 ytimellä.
Levyn luku ja kirjoitus – piikit poissa
Ennen: levylukuja oli toistuvasti yli 10 000 sekunnissa.
Jälkeen: lukukuorma on selvästi pienempi ja tasaisempi, koska data löytyy useammin muistista.
Tietokantalukitukset – maanantaiaamu ilman jonoja
Ennen (maanantaiaamu): viisi pitkäkestoista lukitusta, jotka kestivät 5–30 minuuttia ja tukkivat kerrallaan yli 50 muuta prosessia.
Jälkeen (maanantaiaamu): lukitukset ovat lyhyitä ja yksittäisiä, eikä pitkiä jonoja enää synny.
Mitä tästä voi oppia
- Lisärauta ei korjaa tehotonta tietokantaa. Tässä tapauksessa resurssien puolittaminen oli mahdollista vasta, kun tietokannan työkuorma saatiin kuriin.
- Mittaa ensin, korjaa sitten. Diagnostiikka näytti, mihin aika ja resurssit todella kuluivat.
- Pienet asiat kasautuvat. Yksittäinen puuttuva indeksi tai raskas kysely voi pysäyttää kymmeniä käyttäjiä.
- 24/7-käyttö vaatii suunnitelmallisuutta. Ilman huoltoikkunaa ylläpito ja muutokset on ajoitettava ja mitoitettava huolella.
Onko teidän ERP-järjestelmänne hidas tai epävakaa? Ota yhteyttä asiantuntijoihimme – selvitetään yhdessä, missä pullonkaulat piilevät.
Terveisin, Mikko Hyvärinen
