On 05/10/2011 12:42 PM, Robert Evans wrote: > > for a in 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31; do dd > if=/dev/zero of=test.dat seek=$a count=1 bs=4k; done > > dd if=/dev/zero of=test.dat bs=4k seek=33 > > This should immediately cause poor write performance and high CPU > consumption.
Yup, within a few seconds this re-produced the issue for me: root@dekabutsu: 09:10 PM :/data/test# for a in `seq 1 2 31`; do dd if=/dev/zero of=test.dat seek=$a count=1 bs=4k; done; dd if=/dev/zero of=test.dat bs=4k seek=33 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 2.8564e-05 s, 143 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 2.9356e-05 s, 140 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 2.0921e-05 s, 196 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 2.5454e-05 s, 161 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 0.011001 s, 372 kB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 3.0182e-05 s, 136 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 2.5434e-05 s, 161 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 2.4897e-05 s, 165 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 2.6415e-05 s, 155 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 3.0322e-05 s, 135 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 2.485e-05 s, 165 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 2.4859e-05 s, 165 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 3.2794e-05 s, 125 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 2.3824e-05 s, 172 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 2.4207e-05 s, 169 MB/s 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 2.5434e-05 s, 161 MB/s ^C2378717+0 records in 2378717+0 records out 9743224832 bytes (9.7 GB) copied, 99.7843 s, 97.6 MB/s (eventually control-c'd. Here is some top output: top - 21:11:53 up 20 days, 23:07, 10 users, load average: 1.98, 0.62, 0.21 Tasks: 494 total, 2 running, 492 sleeping, 0 stopped, 0 zombie Cpu(s): 0.4%us, 14.4%sy, 0.0%ni, 70.2%id, 14.7%wa, 0.1%hi, 0.1%si, 0.0%st Mem: 24734488k total, 24595768k used, 138720k free, 0k buffers Swap: 0k total, 0k used, 0k free, 20303096k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 601 root 20 0 0 0 0 R 99 0.0 0:29.93 jfsCommit 14015 root 20 0 13876 700 580 D 11 0.0 0:16.57 dd 13978 root 20 0 0 0 0 D 2 0.0 0:02.13 flush-8:48 486 root 20 0 0 0 0 S 1 0.0 3:04.74 kondemand/4 581 root 20 0 0 0 0 S 1 0.0 5:04.52 kswapd0 And here is a snapshot of gkrellm: http://box.houkouonchi.jp/jfs_gkrellm.png Maybe I have since realized that I get better performance if I use direct I/O when doing disk images (almost the only time I write huge files like that) and that is what has prevented me from seeing this problem. When I did: # for a in `seq 1 2 31`; do dd oflag=direct if=/dev/zero of=test.dat seek=$a count=1 bs=4k; done; dd oflag=direct if=/dev/zero of=test.dat bs=4k seek=33 The issue was a lot less prevalent (took longer to start) and only had short bursts of high CPU usage by jfscommit and it didn't just use 100% cpu almost hte whole time why I/O slowed down more and more (it would recover after jfscommit using 100% cpu for a few seconds: http://box.houkouonchi.jp/jfs_gkrellm_directio.png ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
