ThomasChr
Active Member
@andreas0
Ich hab nochmal nachgeprüft (diesmal mit strace).
Wir verlieren tatsächlich sehrviel Zeit mit read - ABER auch das write braucht länger (ca. Faktor 4).
Problem ist nur, der große Unterschied den du misst und damit auch die Zeitverzögerung die kommt vom read - selbst wenn der write mit den Zufallszahlen auch ein gutes Stück langsamer ist.
Ich bin schon so oft bei Benchmarks reingefallen, und auch so oft beim interpretieren all der schönen Daten die man hier hat.
Vorallem strace hat natürlich einen erheblichen Overhead der das Bild auch wieder verschieben kann. Und das Profiling misst natürlich eher on-cpu als off-cpu time, erwischt also eine CPU die gerade idle ist evtl. garnicht (denn beim I/O macht die CPU ja nichts mehr).
Ich bin mir recht sicher dass es trotzdem beweist dass das lesen von /dev/urandom hier hauptsächlich bremsend wirkt.
/dev/urandom:
-> read braucht 78713 Mikrosekunden pro Call
-> Insgesamt 78.949348 Sekunden read bei 1003 Calls
-> Write braucht 52 Mikrosekunden pro Call
-> Insgesamt 0.052598 Write bei 1003 Calls
/dev/zero:
-> read braucht 2 Mikrosekunden per Call
-> Insgesamt 0.003538 Sekunden read bei 1003 Calls
-> Write braucht 12 Mikrosekunden per Call
-> Insgesamt 0.031711 Sekunden write bei 1003 Calls
Vermutung warum dein dedi-Server hier schneller ist:
Hardwarezufallsgenerator.
Auf dem Dedi einer für den Server, beim vServer nur einer für viele Server.
Ich glaub fast alle neueren Prozessoren haben Zufallsgeneratoren in Hardware die der Linux Kernel nutzt.
Ich hab nochmal nachgeprüft (diesmal mit strace).
Wir verlieren tatsächlich sehrviel Zeit mit read - ABER auch das write braucht länger (ca. Faktor 4).
Problem ist nur, der große Unterschied den du misst und damit auch die Zeitverzögerung die kommt vom read - selbst wenn der write mit den Zufallszahlen auch ein gutes Stück langsamer ist.
Ich bin schon so oft bei Benchmarks reingefallen, und auch so oft beim interpretieren all der schönen Daten die man hier hat.
Vorallem strace hat natürlich einen erheblichen Overhead der das Bild auch wieder verschieben kann. Und das Profiling misst natürlich eher on-cpu als off-cpu time, erwischt also eine CPU die gerade idle ist evtl. garnicht (denn beim I/O macht die CPU ja nichts mehr).
Ich bin mir recht sicher dass es trotzdem beweist dass das lesen von /dev/urandom hier hauptsächlich bremsend wirkt.
/dev/urandom:
Code:
0.001207 read(0, "\324W\230\17\302\256\236\256\373\205Z\34\253y\36\237\235\365\5r;\347\377\332\251\21\4c\"\342\356\236"..., 1048576) = 1048576
0.079115 write(1, "\324W\230\17\302\256\236\256\373\205Z\34\253y\36\237\235\365\5r;\347\377\332\251\21\4c\"\342\356\236"..., 1048576) = 1048576
0.001449 read(0, "e\205\261\3101n\215\36\nILRd~\32\362\376\20\265i\373\333\314\37\20\301[\215\272\322\202g"..., 1048576) = 1048576
0.077722 write(1, "e\205\261\3101n\215\36\nILRd~\32\362\376\20\265i\373\333\314\37\20\301[\215\272\322\202g"..., 1048576) = 1048576
0.001092 read(0, "%\346\304\245\205\264\235*\335\242,\201\212\321\354\224u\247\7}b\256\324\301J\326\255x\356\221\203\20"..., 1048576) = 1048576
0.078041 write(1, "%\346\304\245\205\264\235*\335\242,\201\212\321\354\224u\247\7}b\256\324\301J\326\255x\356\221\203\20"..., 1048576) = 1048576
0.001092 read(0, "d3\354k{p\326$'4\n\33P\34\330\376\202i\214\1}\36~\7\0203:\355M\247\375t"..., 1048576) = 1048576
0.086590 write(1, "d3\354k{p\326$'4\n\33P\34\330\376\202i\214\1}\36~\7\0203:\355M\247\375t"..., 1048576) = 1048576
Code:
1048576000 bytes (1,0 GB, 1000 MiB) copied, 81,1233 s, 12,9 MB/s
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.93 78.949348 78713 1003 read
0.07 0.052598 52 1003 write
0.00 0.000000 0 10 3 open
0.00 0.000000 0 10 close
0.00 0.000000 0 5 fstat
0.00 0.000000 0 1 lseek
0.00 0.000000 0 11 mmap
0.00 0.000000 0 4 mprotect
0.00 0.000000 0 1 munmap
0.00 0.000000 0 3 brk
0.00 0.000000 0 3 rt_sigaction
0.00 0.000000 0 3 3 access
0.00 0.000000 0 2 dup2
0.00 0.000000 0 1 execve
0.00 0.000000 0 1 arch_prctl
0.00 0.000000 0 2 clock_gettime
------ ----------- ----------- --------- --------- ----------------
100.00 79.001946 2063 6 total-> Insgesamt 78.949348 Sekunden read bei 1003 Calls
-> Write braucht 52 Mikrosekunden pro Call
-> Insgesamt 0.052598 Write bei 1003 Calls
/dev/zero:
Code:
0.001095 read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
0.000145 write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
0.001492 read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
0.000161 write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
0.000997 read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
0.000153 write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
0.001048 read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
0.000139 write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
Code:
1048576000 bytes (1,0 GB, 1000 MiB) copied, 1,05237 s, 996 MB/s
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
85.43 0.012319 12 1003 write
14.57 0.002101 2 1003 read
0.00 0.000000 0 10 3 open
0.00 0.000000 0 10 close
0.00 0.000000 0 5 fstat
0.00 0.000000 0 1 lseek
0.00 0.000000 0 11 mmap
0.00 0.000000 0 4 mprotect
0.00 0.000000 0 1 munmap
0.00 0.000000 0 3 brk
0.00 0.000000 0 3 rt_sigaction
0.00 0.000000 0 3 3 access
0.00 0.000000 0 2 dup2
0.00 0.000000 0 1 execve
0.00 0.000000 0 1 arch_prctl
0.00 0.000000 0 2 clock_gettime
------ ----------- ----------- --------- --------- ----------------
100.00 0.014420 2063 6 total-> Insgesamt 0.003538 Sekunden read bei 1003 Calls
-> Write braucht 12 Mikrosekunden per Call
-> Insgesamt 0.031711 Sekunden write bei 1003 Calls
Vermutung warum dein dedi-Server hier schneller ist:
Hardwarezufallsgenerator.
Auf dem Dedi einer für den Server, beim vServer nur einer für viele Server.
Ich glaub fast alle neueren Prozessoren haben Zufallsgeneratoren in Hardware die der Linux Kernel nutzt.
Last edited by a moderator:
