[Kaufberatung] Was muss ich aufrüsten, um an 50MB/s über SMB zu kommen? [FERTIG, 95MB/s ERREICHT!]

[Michael`]

Mein bisheriger Homeserver ist mir zu langsam. Per SMB gehen ca. 18MB/s über die Leitung. Bei zwei parallelen kopierbefehlen lässt sich der Server auch zu 24MB/s gesamt überreden. Das teil ist gut ein Jahr alt und hat vorgestern drei neue Festplatten (3x2TB) bekommen. Bisher waren es 6x500GB @ SW-RAID5 (mdadm) - die fliegen raus, sobald die ich die Dateien aufs neue RAID kopiert habe.

Soweit ich das erkennen kann ist die CPU mein limitierender Faktor, da das RAID mit dmcrypt + LUKS verschlüsselt ist.

Hat jemand einen Vorschlag, wie ich möglichst günstig an 50MB/s über LAN komme? Reicht es, die CPU gegen eine bessere auszutauschen?

top:

top - 14:19:05 up 5 days, 2:22, 5 users, load average: 3.22, 3.22, 3.14
Tasks: 92 total, 3 running, 89 sleeping, 0 stopped, 0 zombie
Cpu(s): 14.6%us, 69.1%sy, 0.0%ni, 2.3%id, 1.0%wa, 3.0%hi, 10.0%si, 0.0%st
Mem: 1944164k total, 1896648k used, 47516k free, 4408k buffers
Swap: 0k total, 0k used, 0k free, 1262480k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3066 root 15 -5 0 0 0 R 49.9 0.0 694:08.84 kcryptd
5573 root 18 -2 592m 538m 14m S 37.0 28.4 960:31.51 filezilla
5549 root 18 -2 22884 16m 4764 S 5.0 0.9 122:11.00 Xvnc4
999 root 15 -5 0 0 0 S 3.3 0.0 43:08.00 md0_raid5
3065 root 15 -5 0 0 0 S 1.7 0.0 22:21.26 kcryptd_io
5556 root 18 -2 10908 5164 3848 S 0.7 0.3 0:15.76 fluxbox
1 root 20 0 1984 692 592 S 0.0 0.0 0:02.92 init
2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
4 root 15 -5 0 0 0 S 0.0 0.0 0:57.28 ksoftirqd/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.26 watchdog/0
6 root 15 -5 0 0 0 S 0.0 0.0 0:16.02 events/0
7 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
39 root 15 -5 0 0 0 S 0.0 0.0 3:33.83 kblockd/0
41 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
42 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kacpi_notify
123 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
162 root 15 -5 0 0 0 S 0.0 0.0 5:13.30 kswapd0
163 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
621 root 15 -5 0 0 0 S 0.0 0.0 0:00.08 ata/0
622 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ata_aux
625 root 15 -5 0 0 0 S 0.0 0.0 0:00.36 ksuspend_usbd
626 root 15 -5 0 0 0 S 0.0 0.0 0:00.04 khubd
716 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_0
717 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_1
718 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_2
719 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_3
720 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_4
721 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_5
724 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_6
725 root 15 -5 0 0 0 S 0.0 0.0 0:00.06 scsi_eh_7
726 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_8
1032 root 15 -5 0 0 0 S 0.0 0.0 0:17.88 kjournald
1112 root 16 -4 2164 784 472 S 0.0 0.0 0:00.14 udevd
1650 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kpsmoused
1924 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kstriped
2080 daemon 20 0 1768 492 400 S 0.0 0.0 0:00.00 portmap
2282 root 20 0 27388 1620 968 S 0.0 0.1 0:12.86 rsyslogd
2293 root 20 0 1648 596 496 S 0.0 0.0 0:00.00 acpid
2303 messageb 20 0 2484 876 684 S 0.0 0.0 0:00.00 dbus-daemon
2318 root 20 0 5736 3624 1732 S 0.0 0.2 52:23.71 openvpn
2607 Debian-e 20 0 6132 920 608 S 0.0 0.0 0:00.06 exim4



cat /proc/cpuinfo:

processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 127
model name : AMD Sempron(tm) Processor LE-1200
stepping : 2
cpu MHz : 2114.949
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow up pni cx16 lahf_lm extapic cr8_legacy 3dnowprefetch
bogomips : 4233.34
clflush size : 64
power management: ts fid vid ttp tm stc 100mhzsteps



dmidecode --type baseboard:

# dmidecode 2.9
SMBIOS 2.4 present.

Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: GA-MA74GM-S2H
Version: x.x
Serial Number:


hdparm -tT /dev/md0:

/dev/md0:
Timing cached reads: 2058 MB in 2.00 seconds = 1029.73 MB/sec
Timing buffered disk reads: 206 MB in 3.03 seconds = 68.01 MB/sec



MfG,
Michael

 

[Hadan_P]

So auf den ersten Blick würd ich auch auf die CPU tippen. Der kleine Sempron muss die Verschlüsselung und die Paritätsinformationen fürs Raid berechnen, das dürfte zu viel sein.
Eventuell auch noch den RAM aufrüsten, sieht auch recht knapp aus.

Alternative dazu wäre ein eigener RAID-Controller, dann müsste sich die CPU nur noch um die Verschlüsselung kümmern.

mfg
Hadan

 

[arcademaster]

Würde auch viel helfen eine CPU mit 2 Kernen zu haben, dann ginge das Entschlüsseln und die Paritätsberechnungen parallel. Das es jetzt zu langsam ist hängt eindeutig mit der CPU zusammen.

Und ja mit einem richtigen RAID Controller sollte es auch schneller werden. Aber ich glaube die Verschlüsselung der Platte ist Bremse Nr.1. Eine neue CPU sollte auch günstiger sein als eine richtige Raid Karte.

 

[hostile]

bekommst du auf reiner tcp-ebene denn mindestens 50 mb/sec? kannst du ja mal mit netio testen.

gruß
hostile

 

[mr.no-name]

Eventuell auch noch den RAM aufrüsten, sieht auch recht knapp aus.

Das würde ich so nicht sagen. Swap wird ja nicht genutzt und 2 GB sind für einen reinen Fileserver meist vollkommen ausreichend.

 

[Taderaz]

Ja da spielt so einiges rein bei dir. Software Raid 5 bremst gut und die Verschlüsselung auch nochmal. Sollte dazu noch lvm zum Einsatz kommen zieht der auch nochmals was ab.
Möglichkeiten sehe ich per CPU die Verschlüsselung zu beschleunigen (Neues Board +CPU, RAM). Vom Software Raid 5 auf ein hardware Raid5 zu gehen oder statt raid 5 auf ein Raid 1+0 zu gehen. lvm (sofern verwendet) weglassen und normal partitionieren.

 

[Michael`]

Alternative dazu wäre ein eigener RAID-Controller, dann müsste sich die CPU nur noch um die Verschlüsselung kümmern.

Ich bin mir zwar bewußt, das ein Hardware-RAID mehr Performance bringt, aber die teile sind leider sehr teuer. Ich möchte da lieber bei Sofware-RAID bleiben. MDADM ist so ausserdem so schön flexibel und einfach.

Würde auch viel helfen eine CPU mit 2 Kernen zu haben, dann ginge das Entschlüsseln und die Paritätsberechnungen parallel. Das es jetzt zu langsam ist hängt eindeutig mit der CPU zusammen.

Das Problem daran ist, das der crypt-thread nur ein Kern benutzt. Mit 2.6.30 wurde das glaube ich optimiert, ist aber immer noch nicht wirklich behoben ( http://git.kernel.org/?p=linux/kern...it;h=254eff771441f4ee7aa9cf770a6e4820492c9dab ). Ich glaube ob nun Dual oder Quad macht keinen unterschied. Ein zweiter Kern ist aber sicherlich nicht verkehrt

bekommst du auf reiner tcp-ebene denn mindestens 50 mb/sec? kannst du ja mal mit netio testen.

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 90243 KByte/s Tx, 90602 KByte/s Rx.
Packet size 2k bytes: 92251 KByte/s Tx, 93161 KByte/s Rx.
Packet size 4k bytes: 92407 KByte/s Tx, 96424 KByte/s Rx.
Packet size 8k bytes: 92656 KByte/s Tx, 96685 KByte/s Rx.
Packet size 16k bytes: 93328 KByte/s Tx, 93275 KByte/s Rx.
Packet size 32k bytes: 92509 KByte/s Tx, 91771 KByte/s Rx.
Done.

Sollte dazu noch lvm zum Einsatz kommen zieht der auch nochmals was ab.

Kein LVM.

Möglichkeiten sehe ich per CPU die Verschlüsselung zu beschleunigen (Neues Board +CPU, RAM)

Mach mal einen Vorschlag. Das Problem ist, dass wenn ich in mein Board eine AM2+ CPU einbaue, das HT3.0 auf HT1.0 sinkt (2000 MT/s). Hört sich erstmal schlimm an, aber gibt es da überhaupt Performance-Einbrüche?

Hier ist die CPU-Supportliste: GA-MA74GM-S2H (rev. 1.x) - GIGABYTE - Support - Mainboard - CPU Support List


MfG,
Michael

 

[Taderaz]

Hallo, hmm ich habe nicht umsonst auch Board + Ram noch erwähnt... aber schau selbst:
TrueCrypt - Free Open-Source Disk Encryption Software - Documentation - Hardware Acceleration
ka obs da was vergleichbares mit AMD und dmcrypt + LUKS gibt...

 

[Michael`]

Für AMD leider nicht. Die neuen Intel können AES-NI, dass auch von dmcrypt + LUKS unterstützt wird. Leider aber erst ab 2.6.32 und ich kann nicht über 2.6.30, da sonst meine FritzCard-ISDN nicht mehr funktioniert.

 

[Taderaz]

hmm dann teste das ganze doch mal wenn du deine Daten umgezogen hast mit Raid 0+1 (auf den alten Platten). Schlimmstenfalls wirds performanter und du müßtest die Daten nochmals umziehen. Bei den 2TB käme eine weitere HDD dazu; verglichen mit den Kosten für einen hardware Controller imho noch günstig und du kannst bei mdadm bleiben

 

[Michael`]

hmm dann teste das ganze doch mal wenn du deine Daten umgezogen hast mit Raid 0+1 (auf den alten Platten). Schlimmstenfalls wirds performanter und du müßtest die Daten nochmals umziehen. Bei den 2TB käme eine weitere HDD dazu; verglichen mit den Kosten für einen hardware Controller imho noch günstig und du kannst bei mdadm bleiben

Probleme dabei:

- Nochmals 2x kopieren (dauert 2x1,5 Tage)
- Neue 2TB HDD (100 Euro)
- Eine Festplatte mehr im Stromverbrauch
- Ein HDD-Einschub weniger Platz im Server

Und dann bin ich 30MB/s schneller wie vorher?



MfG,
Michael

 

[Taderaz]

Probleme? Nein, es geht ja nur erst einmal ums testen. Du möchtest wissen wie und ob es evtl. schneller geht... zumindest wäre das eine Möglichkeit heraus zu finden ob das Raid 5 bremst (tut es sicher nur obs reicht für deine Anforderung?)... die alten Platten sind eh noch eingebaut und mit mdadm hast du die schnell in ein Raid 10 verwandelt. Dann kannst du dort erst einmal mit einem kleinen Datenvolumen testen... denke mal so 4-8 gb sollten zum testen reichen was über smb geht... so war das gemeint.
Wenns schnell genug ist kannst du dir immer noch überlegen wie es weitergehen soll zum testen jedoch entstehen erst einmal keine Kosten

btw habe ich Transferraten auf meinem Linux Server von gut SMB 100 MB/s.
Ich nutze dafür auch mdadm und auf 2 nicht-raid-platten noch ein lvm.
Anbindung mit 2 GBit Netzwerkkarten (Host + VM), Intel Core2Duo e6400 (2,13GHz), 4GB Ram, HDDs sind Seagate 1TB 7200 und Western Digital EARS 2TB (3 und 4 Platter Versionen).

 

[therealJMC]

load average: 3.22, 3.22, 3.14

Respekt... Da dürfte die Nadel aufm Tacho ja schon fast im Kreis laufen...

Du bräuchtest generell was das mehr "dampf" in Sachen CPU, ob mdadm wirklich der "entscheidende" Faktor ist... Ich denke eher dmcrypt + LUKS schlägt da zu. Aber sicherlich ist der Vorschlag von WickedClown nicht verkehrt das ganze mal mit 1+0 zu testen...

 

[Michael`]

Probleme? Nein, es geht ja nur erst einmal ums testen. Du möchtest wissen wie und ob es evtl. schneller geht... zumindest wäre das eine Möglichkeit heraus zu finden ob das Raid 5 bremst (tut es sicher nur obs reicht für deine Anforderung?)... die alten Platten sind eh noch eingebaut und mit mdadm hast du die schnell in ein Raid 10 verwandelt. Dann kannst du dort erst einmal mit einem kleinen Datenvolumen testen... denke mal so 4-8 gb sollten zum testen reichen was über smb geht... so war das gemeint.
Wenns schnell genug ist kannst du dir immer noch überlegen wie es weitergehen soll zum testen jedoch entstehen erst einmal keine Kosten

Hmm, das alte RAID wollte ich erstmal 4-8 Wochen in den Schrank legen, um sicherzustellen, dass die Dateien auf dem neuen RAID konsistent sind (bei den Kopiervorgängen weiß man ja nie so genau ob alles glatt gelaufen ist. Sind immerhin 380.000 Dateien).
Klar würde ich auch gerne ein anderes RAID ausprobieren. Aber da müsste ich dann noch entsprechend abwarten.

Du bräuchtest generell was das mehr "dampf" in Sachen CPU, ob mdadm wirklich der "entscheidende" Faktor ist... Ich denke eher dmcrypt + LUKS schlägt da zu.

Schlage mal eine CPU vor, die meinen Anforderungen entspricht. Das war ja eigendlich auch die Ursprungsfrage


MfG,
Michael

 

[cuco]

ein richtiger raid controller würde hier doch viel besser passen. Mit cache und bbu bist du dann auch gut abgesichert und hast reichlich performance. kann ich nur empfehlen. by the way verkaufe ich recht günstig gerade einen

 

[Michael`]

ein richtiger raid controller würde hier doch viel besser passen. Mit cache und bbu bist du dann auch gut abgesichert und hast reichlich performance. kann ich nur empfehlen.

Toll, danke für das zuspammen meines Threads....


Ich werfe dann mal eine CPU in den Raum: AMD Phenom II X2 550, 2x3,1GHz; Kostet 80 Euro und wird lt. CPU-Support-Liste von meinen Board unterstützt.

Werde ich damit mein Ziel erreichen?


MfG,
Michael

 

[arcademaster]

Ja wirst du.

 

[Michael`]

Alles klar. Hab mir die CPU gerade bestellt. Werde das ding morgen einbauen und dann berichten.


MfG,
Michael

 

[Colty]

Vielleicht mal als Vergleichswert, ich habe eine ganz ähnliche (Software-) Konfiguration laufen:

6x 1TB SATA (waren mal 4, es wurde vergrößert)
mdadm r5
luks-aes (iirc 256bittig)
kein LVM

Der Untersatz ist ein C2D E8400 (2x3GHz), 4 GB Speicher. Platten hängen an den Controllern auf dem Board.

Das Raid 5 selbst liefert etwa 300MB (war mit 4 Platten schon so), die Leserate vom verschlüsselten Volume liegt bei knapp 100MB (mit aes-i586, das brachte btw. ca. 12MB/s mehr als das aes modul).

Über SMB kommen leider nur klägliche 30-35MB beim schreiben und halbwegs akzeptable 40-55MB beim lesen an (die Transferraten schwanken, abhängig von der zu lesenden Datei, warum auch immer). Aus'm cache gelesen sind's über 70MB/s. Alles gemessen bei single-transfer.

Die Auslastung zeigt auch bei mir, dass die CPU bremst. Wenn Du Deine CPU hast und ein paar benches gemacht hast lass uns bitte auch mal Deine Verschlüsselungsparameter wissen.

Grüße,
Kai

 

[McLaine]

Das würde ich so nicht sagen. Swap wird ja nicht genutzt und 2 GB sind für einen reinen Fileserver meist vollkommen ausreichend.

Das stimmt soweit nicht ganz. Der verfügbare Ram wird als Cache verwendet. Linux ist so klug und verwendet für den Cache nicht die Swap Partition, was auch kontraproduktiv wäre.

Bei meinem NAS (4 GB) wird der komplette freie RAM zum Cachen verwendet. Mit meinem NAS (s.SIG) hab ich Datenraten von 100+ MB/s. CPU Auslastung ca 50-60% auf einem Core.

Daher kann zusätzlicher Ram schon was bringen. Wobei ich auch erstmal die CPU austauschen würde.

Grüsse

McLaine

 

[hostile]

Der verfügbare Ram wird als Cache verwendet. Linux ist so klug und verwendet für den Cache nicht die Swap Partition, was auch kontraproduktiv wäre.

Ja, das kann man auch bei mir z.B. sehen (Signatur, einfach auf den Link klicken).

gruß
hostile

 

[Skrewdriver]

Im endeffekt wäre aes-ni das sinnvollste, das problem bei dm-crypt ist das kein multicore unterstützt wird. Das heisst pro device benutzt dm-crypt nur ein thread. Dies gillt vor allem für hardware Raids. Hatte auf einem hardware raid0 aus 4 platten mit aes256 bit einen write und read von max 110 mb/s. Und das mit einem quadcore xeon.
Habe abhilfe geschaffen indem ich jede festplatte einzeln verschlüsselt habe und die einzelnen dm-crypt devices dann per mdadm in ein raid 0 gesetzt habe.
Nun werden alle 4 cores ordentlich genutzt.

Hier wirds verdeutlicht:

Maximise dm-crypt - Gentoo Linux 64-Bit on Intel® Atom

 

[Michael`]

Soooo

Die CPU ist leider noch nicht da, aber die neuen 3x2TB HDDs sind nun in den Server gewandert. Hier die Ergebnisse:

hdparm -tT /dev/md0:
/dev/md0:

Timing cached reads: 1482 MB in 2.00 seconds = 741.00 MB/sec
Timing buffered disk reads: 300 MB in 3.01 seconds = 99.71 MB/sec


SMB-Performance:

Lesend: 34MB/s
Load Average: 1.1

Schreibend: 31MB/s
Load Average: 1.2


Das ist ja erstmal richtig toll, aber wirft Fragen auf:


An der Hardware hat sich ausser die neuen Platten nichts geändert, die Transferraten sind um 1/3 gestiegen und der Load Average drastisch gesunken (von ~3.2 auf ~1.2). Warum?


Bringt es jetzt überhaupt noch etwas die neue CPU einzubauen?


MfG,
Michael

 

[hostile]

poste mal deine smb-config (kann dir zwar nicht erlären, warum der load runtergegangen ist, dafür weiss ich nicht wie dm-crypt funktioniert).

gruß
hostile

 

[Michael`]

Wenn du Vorschläge zur besseren Performance hast, immer her damit


Hier die smb.conf:

#======================= Global Settings =======================

[global]

workgroup = WORKGROUP
server string = %h server
dns proxy = no


#### Debugging/Accounting ####


log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d


####### Authentication #######

security = user
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes

passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .

pam password change = yes


#======================= Share Definitions =======================

[Mediathek]
comment = Mediathek
browseable = yes
read only = no
create mask = 0700
directory mask = 0700
valid users = ***
path = /media/RAID5/***/***

 

[dexus]

Soooo
An der Hardware hat sich ausser die neuen Platten nichts geändert, die Transferraten sind um 1/3 gestiegen und der Load Average drastisch gesunken (von ~3.2 auf ~1.2). Warum?

Das berechnen der Paritätsdatenblöcke über sechs Platten kostet mehr Leistung als über drei. Das wäre ein möglicher Grund.

Soooo
Bringt es jetzt überhaupt noch etwas die neue CPU einzubauen?

Die Frage liesse sich einfacher beantworten, wenn wir nicht nur den Load als Anhaltspunkt hätten.
Man kann auch einen Load von 10 haben und die CPU läuft im Leerlauf weil sie auf Daten wartet.

 

[Michael`]

Die Frage liesse sich einfacher beantworten, wenn wir nicht nur den Load als Anhaltspunkt hätten.
Man kann auch einen Load von 10 haben und die CPU läuft im Leerlauf weil sie auf Daten wartet.

OK, wie kann ich feststellen, wo der Flaschenhals momentan liegt?



MfG,
Michael

 

[fdsonne]

An der Hardware hat sich ausser die neuen Platten nichts geändert, die Transferraten sind um 1/3 gestiegen und der Load Average drastisch gesunken (von ~3.2 auf ~1.2). Warum?


Bringt es jetzt überhaupt noch etwas die neue CPU einzubauen?


MfG,
Michael

Das wird mit ziemlicher Sicherheit daran liegen, das weniger Platten gleichzeitig auch weniger Last auf der CPU bedeutet um die Paritätsdaten zu berechnen.

Aber bedenke weiterhin, wenn du nun einen Dualcore einsetzt und die CPU Ressourcen um den Faktor 100% steigen, die Datenraten nicht auch um den Faktor 100% steigen werden. Denn einerseits müssen für doppelte Schreibperformance die doppelte Menge an Paritätsdaten berechnet werden und es müssen die doppelte Menge Daten verschlüsselt werden.
Macht in Summe bei 100% mehr CPU Ressourcen ~50% mehr Schreibperformance. Beim lesen sollte es aber etwas mehr als 50% werden, da hier die CPU ausschließlich entschlüsseln muss.


Ich würde an deiner Stelle schauen, das du irgendwie eine Software einsetzt, welche Multicore optimiert ver/entschlüsseln kann.
Das Softwareraid 5 ansich ist normal Multicoreoptimiert, sprich nutzt auch alle Ressourcen aus. Nur nutzt dir das gar nix, wenn der Ver/Entschlüsslungsprozess aufgrund nur eines Cores nicht hinterher kommt.

Wie man anhand deiner geposteten Werte mit den 3 Platten wunderschön sieht, ist wohl eindeutig der Ver/Entschlüssungsprozess für die niedrige Performance schuld. Denn normal müsste zwischen Lese und Schreibrate ein drastischer Unterschied zu verzeichnen sein

Ich hätte an deiner Stelle wohl aber eher zu einem Tripple oder Quadcore gegriffen. Denn so hast du erstmal viel Luft für den Paritätsberechnungsprozess. Es bleibt zwar weiterhin das Problem mit der Verschlüsslung, aber wer weis ob sich da die Software irgendwann mal breitschlagen lässt und dann ebenso funktioniert.

 

[dexus]

OK, wie kann ich feststellen, wo der Flaschenhals momentan liegt?

z.B. mit vmstat sieheKlick
oder top.

einfach mal posten was ausgegeben wird.

 

[Michael`]

top lesend:

top schreibend:

vmstat lesend:

vmstat schreibend:

Was kann man da rauslesen?



MfG,
Michael