[AIX] dramatische diskperformance

[GarBaGe]

Op mijn bedrijf hebben we een aantal servers staan, waaronder een aantal AIX machines van IBM. De diskperformance is nogal aan de lage kant en het lijkt wel alsof het inherent te maken heeft met AIX zelf OF met IBM's JFS2 filesysteem.

Nu heb ik een test progje getypt en was benieuwd of er mensen zijn die dit lezen, toegang hebben tot een AIX machine hebben en wellicht deze test ook eens kunnen doen en de resultaten posten hier (misschien een beetje teveel gevraagd )

Anyway, eerst de hardware:
Onze nieuwste AIX (OS versie 5.3) doos is een p-series 550 met een enkele dual-core G5 @ 1.2 GHz, 12 GB RAM en 2x 73 GB 10krpm disks (SCSI, natuurlijk).
De machine draait in LPAR mode. Iedere LPAR heeft 5.5 GB (1 GB moet naar de Virtual I/O server) en samen delen ze de 2 disks. De disks bevatten LVM en beide LPARs hebben 30GB is blokken van 32MB verdeeld over de disks.

Tevens heb ik deze test gedraaid op een Windows bak (desktop machine, P4@2.8 GHz, 1 GB RAM, 40 GB IDE disk) en een Linux Server (HP ProLiant 360, 2x Xeon HT@3.06 GHz, 3GB RAM, HW RAID-5 (HP Smart Array) met 4x 73 GB 15krpm disks en 64MB BBU write cache)

Nu de test applicatie. Sinds we veel werken met IBM WebSphere en onze applicaties allemaal geschreven zijn in Java, vond ik het toepasselijk om de test applicatie in java te schrijven:
Edit: Het grootste probleem is disk-access. Oftewel het schrijven van grote aantallen kleine bestanden naar de disk. Dit Java progseltje schrijft 1000 bestanden van 512 bytes naar de disk en verwijderd deze weer. (de echte bottleneck van onze AIX bak)

code:

import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.text.DecimalFormat;

public class DiskTester {
    public static int MAXFILES = 1000;
    
    public static void main (String args[]) {
        // Determine max number of positions needed
        String maxnumber = String.valueOf(MAXFILES-1);
        int numberlength = maxnumber.length();
        // Setup numberformatter
        String numberFormatString = new String();
        for (int i=0; i<numberlength; i++) {
            numberFormatString += "#";
        }
        DecimalFormat numberFormatter = new DecimalFormat(numberFormatString);
        // Setup filecontent
        byte[] filecontent = new byte[512];
        String filename;
        String filesuffix = ".tmp";
        try {
            long starttime = System.currentTimeMillis();
            System.out.println("Writing files...");
            for (int i=0; i<(MAXFILES-1); i++) {
                filename = numberFormatter.format(i) + filesuffix;
                FileOutputStream fos = new FileOutputStream(new File(filename));
                fos.write(filecontent);
                fos.flush();
                fos.close();
            }
            System.out.println("Deleting files...");
            for (int i=0; i<(MAXFILES-1); i++) {
                filename = numberFormatter.format(i) + filesuffix;
                File file = new File(filename);
                if (file.exists()) {
                    file.delete();
                }
            }
            long endtime = System.currentTimeMillis();
            long runtime = endtime - starttime;
            System.out.println("Done. Runtime: " + runtime + " ms.");
        } catch (FileNotFoundException fnfe) {
            System.err.println("File not found: " + fnfe);
        } catch (IOException ioe) {
            System.err.println("General IO exception: " + ioe);
        }
    }
}

En de resultaten (JVM 1.4.x):

Windows Desktop: +/- 1500 ms
Linux Server: +/- 500 ms
AIX server: 12000-16000 ms

Dat de Linux server met SCSI HW-RAID-5 en BBU write cache veel sneller is dan de Windows desktop met enkele IDE disk, is niet meer dan logisch.
Maar de AIX machine met dubbele geshared SCSI-disk valt wel heel erg uit de toon.

Dan voor mij het belangrijkste gedeelte van deze post:
wie kan dit test progje draaien op een AIX bak en dan ff de resultaten posten en de HW specs van de AIX bak erbij zetten...

[ Voor 6% gewijzigd door GarBaGe op 15-09-2005 09:58 ]

[Wilke]

De gebruikte JVM kan ook behoorlijk veel uitmaken, dus vermeldt dat er ook even bij als je hier post.

[zomertje]

Ik moet zeggen dat ik die bak van ons ook wel warm gedraaid krijg als ik een database ga dumpen. Dat zijn ook een aantal kleinere files op disk, veel reads/writes enzo. Maar of ie traag is of niet, op windows duurt dezelfde bewerking een factor 4 langer. Moeilijk te zeggen dus. Heb ook even geen bak ter beschikking nu, lang weekend

[ Voor 14% gewijzigd door zomertje op 15-09-2005 19:55 ]

[GarBaGe]

Wilke schreef op donderdag 15 september 2005 @ 13:41:
De gebruikte JVM kan ook behoorlijk veel uitmaken, dus vermeldt dat er ook even bij als je hier post.

Linux draait Sun's JVM 1.5.0
AIX draait IBM's JVM 1.4.1 (IBM AIX build ca1411ifx-20040810 (141SR3))
Windows draait (zeer waarschijnlijk) IBM JVM 1.4.x (de standaard JVM van WSAD 5.1.2)

Op zich is de AIX-bak niet langzaam. De processor is echt supersnel. Maar metname disk-access is gewoon niet vooruit te branden.

[zomertje]

Maar dat hangt er toch gewoon vanaf wat voor schijven je erin stopt. Dikke 15.000 scsi schijven zullen toch niet traag zijn?

[ Voor 22% gewijzigd door zomertje op 16-09-2005 11:36 ]

[Verwijderd]

Heb je toevallig een UW cdrom speler op dezelfde bus hangen als je disken? Ik heb ooit eens wat performance probs op wat oudere AIX systemen op weten te lossen door de cdromspeler op een andere bus te hangen. (correct me if I'm wrong: de scsi bus past zich aan aan het traagste apparaat op je bus)

edit:

Probeer ook eens de 1.4.2 JDK, mischien dat dat verschil uitmaakt.

[ Voor 14% gewijzigd door Verwijderd op 16-09-2005 13:44 ]

[GarBaGe]

De CDROM speler (eigenlijk een DVD-RAM writer oid) is een IDE en hangt aan zijn eigen "other mass storage controller"

Mijn grootste vermoeden echter, is dat ALLE AIX machines dus een (zeer) slechte disk performance leveren bij veel kleine bestanden.

Overigens, wat nog vervelender is, is dat we binnenkort moeten beslissen over de aanschaf van een nieuwe AIX doos die deze opvolgt. Dan wil ik eigenlijk dit probleem uit de wereld helpen.

15krpm schijven ipv 10krpm schijven scheelt natuurlijk wel iets, maar hooguit 30-40%
Echter, vergeleken met Windows en Linux test heb ik minimaal factor 10-30 nodig (1000%-3000%)

De Java versie verhogen gaat niet. De dev-environment moet dezelfde versie draaien als wat onze klanten gebruiken, oftewel: WAS 5.1.1.3. Alles draait op de JVM die hier bij zit.

Wellicht komt het door de micro-partitioning (LPARs), maar het enige wat IBM kan zeggen is: er is een nieuwere update van *vul iets in*, wellicht verhelpt dat het probleem. Maar ja, de bak ff rebooten is er niet (zomaar) bij

[GarBaGe]

Nog ff een leuke aanvulling...

Op de Linux server wordt reiserfs gebruikt.
Als ik daar ext3fs gebruik, wordt het nog sneller. <200ms voor ext3 vs <500ms voor reiserfs.

IBM heeft ondertussen aangegeven dat de mount-optie "nointegrity" wel zorgt voor een hele goede performance (<200 ms, vergelijkbare tijden als met ext3), maar geeft tevens aan dat deze optie niet ge-support wordt.
Effectief wordt met deze optie het "journalling" uitgeschakeld.

Hierdoor krijg ik het idee dat het probleem wellicht metname in de JFS2 zit en niet eens zo zeer in de AIX hardware of AIX OS.

Toch ben ik benieuwd of er nog mensen zijn, die een dergelijke machine tot hun beschikking hebben en deze test hebben geprobeerd....