(Illustration by Gaich Muramatsu)
(Illustration by Gaich Muramatsu)
Hi Jan, thaks for reply, but still thinking that problem is anywhere in kernel. For eliminate network problems and others bugs describe configuration on problematic computer. There is no network operations only write on the same computer. I can send more information from /proc. IBM eServer 345, 2x XEON 2Ghz, 2GB RAM If you have more ideas..will be good soud for me :) Vojtech Only what change is kernel: -------------2.4.18-14smp------- uname -rva Linux sklad1 2.4.18-14smp #1 SMP Wed Sep 4 12:34:47 EDT 2002 i686 i686 i386 GNU/Linux time dd if=/dev/zero of=/coda/test bs=1024 count=1024 1024+0 records in 1024+0 records out real 0m40.474s user 0m0.002s sys 0m0.018s Here is vmstat... when is "1" in "b" column dd command is working. [root_at_sklad1 root]# vmstat 1 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 0 1641284 7408 204052 0 0 60 7 131 12 0 0 99 0 0 0 0 1641284 7408 204052 0 0 0 0 517 6 0 0 100 0 0 0 0 1641284 7408 204052 0 0 0 0 517 8 0 0 100 0 0 0 0 1641284 7416 204052 0 0 0 89 526 21 0 0 100 0 1 0 0 1640828 7424 203032 0 0 0 1075 541 136 0 1 99 0 1 0 0 1640828 7424 203036 0 0 0 0 520 30 0 0 100 0 1 0 0 1640828 7424 203056 0 0 0 0 519 90 0 0 100 0 1 0 0 1640828 7428 203084 0 0 0 0 521 126 0 0 100 0 1 0 0 1640828 7448 203108 0 0 0 180 524 110 0 0 100 0 1 0 0 1640828 7448 203132 0 0 0 0 523 104 0 0 100 0 1 0 0 1640828 7448 203164 0 0 0 0 516 116 0 0 100 0 1 0 0 1640828 7448 203188 0 0 0 0 517 178 0 0 100 0 1 0 0 1640828 7448 203220 0 0 0 0 523 128 0 0 100 0 1 0 0 1640828 7464 203252 0 0 0 248 522 138 0 0 100 0 1 0 0 1640828 7464 203276 0 0 0 0 521 94 0 0 100 0 1 0 0 1640828 7464 203300 0 0 0 0 518 90 0 0 100 0 1 0 0 1640828 7464 203340 0 0 0 0 523 146 0 0 100 0 1 0 0 1640828 7464 203364 0 0 0 0 523 94 0 0 100 0 1 0 0 1640828 7480 203388 0 0 0 216 523 114 0 0 100 0 1 0 0 1640828 7480 203420 0 0 0 33 530 152 0 0 100 0 1 0 0 1640828 7480 203452 0 0 0 0 516 126 0 0 100 0 1 0 0 1640828 7480 203484 0 0 0 0 522 122 0 0 100 0 1 0 0 1640828 7480 203516 0 0 0 0 519 126 0 0 100 0 1 0 0 1640828 7496 203540 0 0 0 152 526 120 0 0 100 0 1 0 0 1640828 7496 203564 0 0 0 0 527 106 0 0 100 0 1 0 0 1640828 7496 203596 0 0 0 0 527 128 0 0 100 0 1 0 0 1640828 7496 203620 0 0 0 0 524 92 0 0 100 0 1 0 0 1640828 7496 203644 0 0 0 0 520 90 0 0 100 0 1 0 0 1640828 7512 203676 0 0 0 176 527 150 0 0 100 0 1 0 0 1640828 7512 203708 0 0 0 0 522 126 0 0 100 0 1 0 0 1640828 7512 203732 0 0 0 0 523 94 0 0 100 0 1 0 0 1640828 7512 203764 0 0 0 0 519 124 0 0 100 0 1 0 0 1640828 7512 203788 0 0 0 0 520 92 0 0 100 0 1 0 0 1640828 7528 203812 0 0 0 184 532 110 0 0 100 0 1 0 0 1640828 7528 203852 0 0 0 0 523 166 0 0 100 0 1 0 0 1640828 7528 203884 0 0 0 0 521 124 0 0 100 0 1 0 0 1640828 7528 203916 0 0 0 0 524 118 0 0 100 0 1 0 0 1640828 7528 203948 0 0 0 0 522 110 0 0 100 0 1 0 0 1640828 7544 203972 0 0 0 192 524 107 0 0 100 0 1 0 0 1640828 7544 203996 0 0 0 0 518 98 0 0 100 0 1 0 0 1640828 7544 204032 0 0 0 0 521 132 0 0 100 0 1 0 0 1640828 7544 204032 0 0 0 0 525 110 0 0 100 0 1 0 0 1640828 7544 204036 0 0 0 0 526 30 0 0 100 0 1 0 0 1640828 7560 204040 0 0 0 156 530 46 0 0 100 0 1 0 0 1640824 7560 204048 0 0 0 0 519 26 0 0 100 0 0 0 0 1640828 7560 204052 0 0 0 53 530 36 0 0 100 0 0 0 0 1640828 7560 204052 0 0 0 0 517 6 0 0 100 0 0 0 0 1640828 7560 204052 0 0 0 0 519 10 0 0 100 -------------2.4.18-14------- uname -rva Linux sklad1 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux time dd if=/dev/zero of=/coda/test bs=1024 count=1024 1024+0 records in 1024+0 records out real 0m0.155s user 0m0.002s sys 0m0.004s Write was when "b" have "2" vmstat 1 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 0 1645440 5972 204520 0 0 612 59 543 91 1 3 97 0 0 0 0 1645440 5972 204520 0 0 0 0 520 10 0 0 100 0 0 0 0 1645440 5972 204520 0 0 0 0 519 7 0 0 100 0 0 0 0 1645440 5972 204520 0 0 0 0 518 11 0 0 100 0 2 0 0 1645608 5972 203496 0 0 0 1032 528 38 0 1 99 0 0 0 0 1645336 6000 204524 0 0 0 1201 553 2106 3 2 95 0 0 0 0 1645336 6000 204524 0 0 0 0 522 7 0 0 100 0 0 0 0 1645336 6000 204524 0 0 0 0 524 7 0 0 100 0 0 0 0 1645336 6000 204524 0 0 0 0 516 7 0 0 100 > On Thu, Jan 30, 2003 at 03:39:44PM +0100, Vojtech Moravek wrote: > > Yesteraday i wrote some problems with slow write operations. I made some > > tests and results is: > > > > When coda run on computers which have only one cpu. Everything is cool. > > When is CODA installed on twoCPUs computer I have problem with write > > operations.. more describes are bellow: > > It must be some timing issue. When I write a 1MB file in connected mode > to 2 servers (servers are PII-200, client is PIII-1000) > > jaharkes_at_ravel$ time dd if=/dev/zero of=foo bs=1024 count=1024 > 1024+0 records in > 1024+0 records out > > real 0m0.760s > user 0m0.000s > sys 0m0.010s > > > When I do the same operation in write-disconnected mode it completes > almost instantaneously. > > jaharkes_at_ravel$ cfs wd . > jaharkes_at_ravel$ time dd if=/dev/zero of=foo bs=1024 count=1024 > 1024+0 records in > 1024+0 records out > > real 0m0.042s > user 0m0.000s > sys 0m0.010s > > > We should probably figure out where the time is lost. Force a > write-disconnect and write the file. That should really take no time at > all. Then reconnect (cfs wr) and do the operation while running vmstat > 1 in a second terminal. That should show whether we're hogging the CPU, > or trashing the disk, or simply using too much memory and forcing the > machine to swap too much. > > Oh, and dual CPU should theoretically be better, because the application > and venus are not fighting each other over the same CPU. If it weren't > the fact that your worst cases are client & server on the same machine, > I would have suspected network related problems. The only thing I can > think of right now, is that RVM modifications use fsync to force changes > to disk, and I've noticed before that fsync on Linux is extremely slow > when there are a lot of dirty buffers waiting for writeout, and that > heavy writeout activity stalls read/page-in operation significantly. > > Jan > >Received on 2003-01-31 04:45:34