Festplattenprobleme, Grosse Dateimengen, massig Zugriffe
Hallo, ich habe folgendes Problem. Ich habe nun erstmalig einen Imap-Server im Netz dieser bedient einige 10.000 User eine Community. Dabei greifen wir auf Maildirs zurueck. Woran nicht gedacht wurde war die Festplatte, leider. Die macht jetzt etwas stress. Die Geschwindigkeiten der Imap-Aufrufe sind nicht mehr akzeptabel. Allgemeine arbeiten auf der Shell die mit dem Dateisystem zu tun haben sind auch nicht mehr lustig. Hier mal ein paar Infos: # hdparm /dev/hda1 /dev/hda1: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 14593/255/63, sectors = 117884680704, start = 63 # hdparm -tT /dev/hda1 /dev/hda1: Timing cached reads: 1104 MB in 2.00 seconds = 552.00 MB/sec Timing buffered disk reads: 4 MB in 3.32 seconds = 1.20 MB/sec # hdparm -i /dev/hda /dev/hda: Model=WDC WD1200BB-00DWA0, FwRev=15.05R15, SerialNo=WD-WMAEK2137238 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=74 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16 CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=234441648 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 AdvancedPM=no WriteCache=enabled Drive conforms to: device does not report version: * signifies the current active mode Zustaetzlich liegt das Gesamte System auf einer Gesamtpartition. Es wird hierfuer einen neuen Server geben. Welche Vorschlaege habt Ihr um all dem moeglichs weit aus dem Weg zu gehen. Und noch wichtiger: Welche einfachen, (remote-)durchfuehrbaren Loesungen seht Ihr um hier etwas herauszuholen? Danke, Gruss Marius
Am Mittwoch, 15. Dezember 2004 18:49 schrieb Marius-Dieter Noetzel:
ich habe folgendes Problem. Ich habe nun erstmalig einen Imap-Server im Netz dieser bedient einige 10.000 User eine Community. Dabei greifen wir auf Maildirs zurueck. Woran nicht gedacht wurde war die Festplatte, leider. Die macht jetzt etwas stress.
Die Geschwindigkeiten der Imap-Aufrufe sind nicht mehr akzeptabel. Allgemeine arbeiten auf der Shell die mit dem Dateisystem zu tun haben sind auch nicht mehr lustig.
[...]
Zustaetzlich liegt das Gesamte System auf einer Gesamtpartition. Es wird hierfuer einen neuen Server geben. Welche Vorschlaege habt Ihr um all dem moeglichs weit aus dem Weg zu gehen. Und noch wichtiger: Welche einfachen, (remote-)durchfuehrbaren Loesungen seht Ihr um hier etwas herauszuholen?
1. Ram 2. SCSI (mehrere Platten) 3. teuer :) 4. wenn Du viele gleichzeitige IMAP-Prozesse hast und auch noch auf der Shell arbeiten willst ist ein Dual-CPU-System nicht das schlechteste 5. bevor ichs vergesse: teuer 6. Ram. 7. und wenns wirklich wichtig ist: 2. Server, der regelmäßge Backups bekommt oder sogar als hotspare läuft 8. es wird teuer. Andreas
Am 12/15/2004 06:49 PM schrieb Marius-Dieter Noetzel:
Es wird hierfuer einen neuen Server geben. Welche Vorschlaege habt Ihr um all dem moeglichs weit aus dem Weg zu gehen.
- möglichst schnelle Festplatte (für IMAP-Server dieser Größenordnung ist die Zugriffszeit deutlich wichtiger als die Transferrate) - evtl. ein RAID-System und/oder SCSI-Platten - passendes Dateisystem, das mit vielen kleinen Dateien, wie sie im Maildir-Format vorkommen, effizient umgehen kann, ich empfehle gerne XFS (siehe http://suse-linux-faq.koehntopp.de/q/q-filesystems-auswahl.html). - viiiel Arbeitsspeicher (möglichst schneller Markenspeicher), und ein ordentliches Mainboard, evtl. ein Dual-Prozessor-System, falls sehr viele Zugriffe gleichzeitig erfolgen - 2.6'er Kernel (besonders wegen des O(1) Schedulers, bei sehr vielen Prozessen sollte man einen deutlichen Unterschied zum alten O(n) Scheduler des 2.4'er Kernels merken)
Und noch wichtiger: Welche einfachen, (remote-)durchfuehrbaren Loesungen seht Ihr um hier etwas herauszuholen?
- Kernel 2.6.x (siehe oben) - falls als Dateisystem noch ext2 oder ext3 im Einsatz ist: Umstieg auf z. B. XFS, falls Du eine freie Partition dafür übrig hast - evtl. probieren, den readahead zu verändern, wenn Du vor allem sehr viele kleine Maildateien (<= 2kB) hast, könnte man 4 statt 8 mal probieren (ich erwarte davon aber keinen allzu großen Effekt) MfG, Michael.
Danke erstmal für die Infos. Ein Sache hab ich da noch. Wo kann ich denn kurzfristig evt. noch brauchbar schrauben? Momentan ist es wirklich grausam. Ruft ein User seine Inbox alle 0,5 bis 1 Minuten ab ist alles gut... Ansonnsten gibts latenzen im zweistelligen Sekundenbereich. Der Ram ist dicht (512mb) die cpu langweilt sich... Das System muss nun noch einige Tage laufen, stellt sich nur die Frage, ob ich's den Usern evt. Etwas angenehmer machen kann. Das eigentliche Problem resultiert daraus, dass die User auf dem IMAP (ueber .Outbox) senden. Der Exim die dann zur lokalen zustellung bekommt (externe mail gibts momentan nicht). Ist der Versand aus, hab ich traumverhaeltnisse bei mehr Inboxaufrufen. Fuer den "neuen" Server habe ich mir folgendes überlegt(Das haben wir zusammengebaut im Rechenzentrum stehen) -Ein Raid 1 für die Datensicherung & System -Ein Radi 0 für die Maildirs Das ganze bei 2.8 Ghz und 2 GB Ram. Darauf kommen dann ca. 100.000 Postfächer. Was ist bei der groesse sinniger, courier oder cyrus? Danke & Gruss Marius
Hallo, Am Mittwoch, 15. Dezember 2004 22:53 schrieb Marius-Dieter Noetzel:
Danke erstmal für die Infos.
Ein Sache hab ich da noch. Wo kann ich denn kurzfristig evt. noch brauchbar schrauben? Momentan ist es wirklich grausam. Ruft ein User seine Inbox alle 0,5 bis 1 Minuten ab ist alles gut... Ansonnsten gibts latenzen im zweistelligen Sekundenbereich. Der Ram ist dicht (512mb) die cpu langweilt sich... 0,5Gig bei der Anzahl User ??? Kurzfristig noch einen Riegel reinstecken ...
Das System muss nun noch einige Tage laufen, stellt sich nur die Frage, ob ich's den Usern evt. Etwas angenehmer machen kann. Das eigentliche Problem resultiert daraus, dass die User auf dem IMAP (ueber .Outbox) senden. Der Exim die dann zur lokalen zustellung bekommt (externe mail gibts momentan nicht). Ist der Versand aus, hab ich traumverhaeltnisse bei mehr Inboxaufrufen.
Fuer den "neuen" Server habe ich mir folgendes überlegt(Das haben wir zusammengebaut im Rechenzentrum stehen)
-Ein Raid 1 für die Datensicherung & System
-Ein Radi 0 für die Maildirs
Denk noch mal über Raid 0 nach! Die 0 kann man mit Null-Sicherheit übersetzen! Soll heissen: eine Platte kaput == alles Kaput!!! (wie viele Platten verwendet Du da?) Besser RAID 5 (eine zusätzliche Platte, dann kann aber auch eine Platte ausfallen OHNE das gleich alles weg ist).
Das ganze bei 2.8 Ghz und 2 GB Ram.
Darauf kommen dann ca. 100.000 Postfächer. Was ist bei der groesse sinniger, courier oder cyrus?
Danke & Gruss
Marius
-- MfG Rolf Masfelder EMail: rolf.masfelder@nector.de
Hallo Marius-Dieter, zuerst mal vielleicht etwas allgemeines. Für ein Produktivsystem mit 10000 gleichzeitigen Benutzern sollte heute IMHO mindestens die folgende Hardware drin sein. SCSI System mit 64Bit PCI Bus oder PCI-X RAID 0 bzw. 5 und "genügend" Platz pro User (Qutoa!?) RAM jenseits 5GB Anbindung Gigabit evtl. bonding zweier Netzwerkkarten. So, nun zu deinem Problem :) Sinnvolle Backuplösung (Zweitserver + Band) Dual Opteron System (bin kein Freund von HT deshalb keine Xeon) On Wed, Dec 15, 2004 at 06:49:43PM +0100, Marius-Dieter Noetzel wrote:
Dabei greifen wir auf Maildirs zurueck.
Maildir --> viele kleine Dateien --> ReiserFS4 ist das ideale Dateisystem. Allerdings nur, wenn du ein ordentliches Backup hast. Die Performance von ReiserFS4 ist toll. Die Stabilität könnte besser sein. Alternativ XFS mit kleiner Blockgrösse um weniger Speicherplatz zu verschwenden.
Die Geschwindigkeiten der Imap-Aufrufe sind nicht mehr akzeptabel. Allgemeine arbeiten auf der Shell die mit dem Dateisystem zu tun haben sind auch nicht mehr lustig.
Hier mal ein paar Infos:
# hdparm /dev/hda1
/dev/hda1: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 14593/255/63, sectors = 117884680704, start = 63
Bis auf die Tatsache, dass das eine IDE Platte ist sind die Daten OK
# hdparm -tT /dev/hda1
/dev/hda1: Timing cached reads: 1104 MB in 2.00 seconds = 552.00 MB/sec Timing buffered disk reads: 4 MB in 3.32 seconds = 1.20 MB/sec
ich gehe mal davon aus, dass es sich dabei um eine Messung unter Last handelt :) Wenn nicht dann schau in /var/log/messages mal nach Meldungen deiner Platte.
Zustaetzlich liegt das Gesamte System auf einer Gesamtpartition. Es wird hierfuer einen neuen Server geben. Welche Vorschlaege habt Ihr um all dem moeglichs weit aus dem Weg zu gehen.
Das neue System ähnlich dem was ich oben sagte dimensionieren. Und am besten mind. 4 Platten (2xRaid0) verbauen. Auf das eine Raid die ganzen Mailverzeichnise, auf das andere Raid das System,+SWAP.
Und noch wichtiger: Welche einfachen, (remote-)durchfuehrbaren Loesungen seht Ihr um hier etwas herauszuholen?
Vorläufig das logging minimieren, oder komplett abstellen (temporär) cronjobs (updatedb etc.) vermeiden cron evtl. komplett stoppen. alle Dienste, die nicht unbedingt gebraucht werden stoppen. Sprich vorläufig kein Spamcheck und kein Viruscheck. Remote benötigte binaries in eine RAM Disk legen. Tmpfs ist weniger geeignet, da hier sicher geswapped wird. Evtl. vorhandene Quota vorläufig deaktivieren. /etc/motd /etc/issue* leer lassen evtl. async Parameter beim mounten der Platte Wenn du irgendwie zusätzlichen RAM und eine zusätzliche Platte für SWAP und System in den Rechner bekommen kannst ... tun. Greetings Daniel -- http://www.incredimail.com/english/splash.html :0 # SAY *PLONK* TO BULLSHIT * ^X-Mailer: IncrediMail # find 'em /dev/null # fix 'em and finish 'em
participants (5)
-
Andreas Loesch -
Daniel Lord -
Marius-Dieter Noetzel -
Michael Schachtebeck -
Rolf Masfelder